On 17 Nov 2009, at 16:49, David Chisnall wrote:
Is there a sensible reason why GNUstep Make adds -lobjc to the end
of the linker flags for tools and apps (which already link against -
base, which links against libobjc)? In a number of projects I'm
experiencing problems with this because the GNUmakefile specifies -L/
usr/lib as a linker flag and so these apps are linking against the
libobjc found there, overriding the one that GNUstep linked
against, and then causing link failures because the system libobjc
is missing some symbols...
Omitting -lobjc would fix this, but GNUstep Make doesn't seem to
provide an easy way of doing that (or, in fact, anything, but that's
a different complaint).
If we could discuss and agree on exactly how this should work, we
could easily change it. :-)
It would probably require a new 2.4 version of gnustep-make though,
since we may be breaking the way libraries and programs are linked.
To give you some background, first of all, some platforms are
different (for example Microsoft Windows) and on these platforms we
must always link against everything otherwise linking just doesn't work.
So, on these platforms we have a special case and always link libobjc
(and the other associated libs).
On platforms where we can get away without not linking, for example,
libobjc, at some stages, we had a change where only gnustep-base and
the final executable are linked against -libobjc --
https://savannah.gnu.org/bugs/?9920
This is the current behaviour; some people recently complained about
that change - they want -lobjc to be added everywhere, in particular,
to all libraries, to comply with Debian Policy
which forbids undefined symbols --
https://savannah.gnu.org/bugs/?24109.
If we were to implement 24109, we'd always link everything to -libobjc
to get rid of the undefined symbols.
Of course, you now are asking for a totally opposite change - ie, that
only libgnustep-base should be linked with -lobjc. ;-)
I guess the discussion is open - I welcome ideas or arguments about
what we should do with respect to linking. :-)
I don't have a particular opinion myself. If we can't find any
agreement, we can always add a ./configure flag to gnustep-make
and make it behave differently depending on how you configure it. I
assume that on GNU/Linux, if nothing else is specified,
we'd default to the behaviour that conforms to the Debian Policy -
other distributions have similar policies and we'd like to make it
really easy to package GNUstep, so it makes sense to use by default
whatever behaviour helps getting GNUstep software into Linux
distributions. You could still get a different behaviour by just
using a ./configure flag.
Thanks
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev