Steve Fryatt wrote:

Links = -L$(GCCSDK_INSTALL_ENV)/lib -L$(GCCSDK_LIBS)/OSLib-Hard/ -lOSLib32 \
        -L$(GCCSDK_LIBS)/SFLib/ -lSFLib32 -L$(GCCSDK_LIBS)/FlexLib/
-lFlexLib32

and swapping this to

Links = -L$(GCCSDK_LIBS)/OSLib-Hard/ -lOSLib32 -L$(GCCSDK_INSTALL_ENV)/lib \
        -L$(GCCSDK_LIBS)/SFLib/ -lSFLib32 -L$(GCCSDK_LIBS)/FlexLib/
-lFlexLib32

(ie. reversing the first line) made the error go away.  I have to admit that
I don't really understand why -- can anyone explain?


I can't say for certain - I've seen things like this before, and 'ld' can be rather fickle sometimes. I'm guessing it found an object file
somewhere that was in one format, then based the rest of the linkage
on that.  'ld' uses a linear search when linking, unlike drlink, which
searches everything for a match (or rather a binary search, since
a complete one as it did long ago turned out to take a very long time),
and this can affect the way it finds stuff.

I'll look at creating a libscl suitable OSLib.  Or perhaps John wants
to, since he'll have a better idea what needs changing.

_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Reply via email to