gnupic: Re: [gnupic] GPasm maint
Subject:
Re: [gnupic] GPasm maint
From:
Borut Razem ####@####.####
Date:
4 Jul 2008 18:30:59 -0000
Message-Id: <486E6C55.40604@siol.net>
Just FYI:
gputils are meant to be compiled using the GNU autoconf/automake tools
and gcc compiler. I don't know if the OS/2 ports exists, but if they do,
then I would say that this is a preferred way to compile gputils.
But on the other hand it is always interesting to compile the
application with different compilers, since each of them shows different
potential problems, for example "Comparison result always 0" warning
with Watcom C/C++...
Borut
David wrote:
> On Fri, 04 Jul 2008 18:04:55 +0200
> Rob Hamerling ####@####.#### wrote:
>
>
>> Hi David,
>>
>> ...
>> About building GPASM: I got a couple of warnings. This might be
>> related to the compiler I use, or related the macro defines like
>> HAVE_MALLOC_H, etc) in my makefile. Most warnings do not worry me
>> (like missing prototype for unlink). There is one that may be
>> important:
>>
>>> parse.c(422): Warning! W129: #endif matches #if in different source
>>> file 'parse.y'
>>>
>> I think there must be an '#endif' missing in parse.y
>>
> There aren't any #if's in parse.y, and I can't find anything mismatched
> in any of the included files. Did you edit stdhdr.h? You mentioned
> problems with HAVE_MALLOC_H, and there's a double #if/#endif around a
> reference to HAVE_MALLOC_H in stdhdr.h. Is it possible you got confused
> there?
>
>
>> Probably an issue with optimisation of LibGPUtils:
>>
>>> gpcoffgen.c(434): Warning! W124: Comparison result always 0
>>> gpcoffgen.c(447): Warning! W124: Comparison result always 0
>>> gpprocessor.c(649): Warning! W124: Comparison result always 0
>>> gpprocessor.c(668): Warning! W124: Comparison result always 0
>>>
> On this I have no idea, but the code does look a little suspicious w/
> the values it's comparing.
>
>
>> An error I 'circumvented' by excluding vsnprintf from the library
>>
>>> vsnprintf.c(42): Error! E1055: Unable to open 'config.h'
>>>
>> I cannot find 'config.h', nor do I see any possible macro definition
>> to prevent it being included.
>>
> config.h is supposed to be auto-generated from config.h.in when you
> run ./configure.
>
> The #v() issue isn't *exactly* what's reported in bug #1250441, but
> it falls under the same heading. Notice how I said "...the #v syntax for
> gpasm currently only works for actual "symbols" and *not* defines."
> ERROR and MESSG directives are treated almost the same way as #defines,
> so gpasm just can't handle your usage quite right. I've been hacking
> away at parsing problems like this one, but I've gotten bogged down
> pretty badly in parsing hell. Not sure how it'll turn out.
>
> David
>
