false positive, but a workaround...

Ed Sutter 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 mailing list