[bug #25536] LDFLAGS=-L/usr/local not at first place honoured

[Nicola Pero]

Follow-up Comment #1, bug #25536 (project gnustep):

Well it seems that you have two conflicting libobjc libraries :-(

... and the wrong one is in /usr/local/lib so it gets picked up.

That sounds like a problem in the ports system.  You have to be
careful also because gnustep-make will be using some threading
flags that might depend on how libobjc was compiled.  Eg,
in your compile command line, there's a -pthread flag.  That
presumably is the right flag for whatever libobjc gnustep-make
was configured to support; it might be the wrong one for 
another libobjc :-/

So the only recommendation is really to fix the
ports so that they install a consistent Objective-C
environment ;-)

On your own machine, you could try hacking things ... you have 
lots of options

 1. just overwrite the non-working libobjc.so with the working
one.  Assuming the threading flags are the same, this might 
just work.

 2. compile and install gnustep's own libobjc.  You find it
in dev-libs/libobjc.  It will probably overwrite your ports
libobjc in /usr/local/lib when you install it, but I assume
that's exactly what you want.  Unfortunately, you need to make
sure the threading flags are the same.

 3. force -L/usr/lib to be used - hoping again that the 
threading flags are the same.  Create the file

/usr/local/share/GNUstep/Makefiles/Additional/UsrLibHack.make

containing the single line

ADDITIONAL_LDFLAGS += -L/usr/lib

that makefile fragment will be loaded at the very beginning
of processing GNUmakefiles, and will add -L/usr/lib to all
the linker lines.  I think this is exactly what you wanted to do.

Thanks

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?25536>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/