false positive, but a workaround...
ed.sutter at alcatel-lucent.com
Wed Jun 24 13:10:56 UTC 2015
Well, it took almost 5 hours to build the tools last night. Obviously I
need to upgrade the machine I have
this stuff running on at home!
Anyway, this AM I was able to walk through what I thought I had done in
work yesterday, and unfortunately due
to the fact that I am working in two different locations on two
different machines (very very inefficient, but I'm
stuck in this mode at the moment); I fooled myself yesterday thinking I
had stubbed out the __ctype_ptr__
declarations from docmd.c... Unfortunately, I didn't :-(, so what I
thought built clean didn't.
Anyway, I want to get you over this hump quickly 'cause this isn't what
I'd like you to be working on. I really
want you to concentrate on beaglebone-specific stuff. That's the
important stuff. Today I brought my beaglebone
board to the office, and I've got it working clean now using a local set
of ctype.h and ctypetbl.c files as I had in
umon1.19. For now this is temporary, but it may turn out to be the most
efficient way to get around this.
So, attached to this are three files:
ctypetbl.c: put this under main/glib
ctype.h: put this under main/common
mydiffs: small list of diffs based on the tree after installing your
initial set of 24 patches.
most of these changes you probably have, the
important one is in main/make/common.make so that ctypetbl.c is built.
If you can incorporate these changes into a tree that starts with the
master and has your initial 24 patches applied,
you should be good to go. I know I should be using git to email you
patches, but I'm still trying to figure out how to
do that and I don't want you to be delayed by that.
Does this make sense to you?
More information about the umon-devel