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/
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
