Re: [Gm2] Option order to gm2

[Gaius Mulley]

john o goyo <address@hidden> writes:

> Why is the option order critical to gm2?  I was under the assumption
> that the driver would collect all options first before continuing on.
>
> Example (on Solaris 10/sparc):
>
> johng [arcfour]10=> gm2 -o tstarcfour -g tstarcfour.mod
> johng [arcfour]11=> gm2 -g -o tstarcfour tstarcfour.mod
> Undefined                       first referenced
>  symbol                             in file
> typeinfo for int                    /var/tmp//cc5ILG6p.a(RTExceptions.o)
> __cxa_allocate_exception            /var/tmp//cc5ILG6p.a(RTExceptions.o)
> __cxa_end_catch                     /var/tmp//cc5ILG6p.a
> (cc8PLRWastart.o)
> __cxa_begin_catch                   /var/tmp//cc5ILG6p.a
> (cc8PLRWastart.o)
> __cxa_throw                         /var/tmp//cc5ILG6p.a(RTExceptions.o)
> __gxx_personality_v0                /var/tmp//cc5ILG6p.a
> (cc8PLRWastart.o)
> ld: fatal: Symbol referencing errors. No output written to tstarcfour
> collect2: ld returned 1 exit status
>
>
> john

Hi John,

they shouldn't be critical.. and your assumption is correct the driver
should collect arguments and forward them to cc1gm2.  However it does
manipulate paths and libraries - the bug is almost certainly in
gm2/gm2spec.c.  Thankfully it is reproducible on the x86_64 platform -
I will look into this.  Interestingly it appears that when adding '-v'
the failing case leaves out:

 -lm -lstdc++ -lgcc_eh


it looks like the argv manipulation is overwriting 3 arguments

thanks for the report,

regards,
Gaius