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

[Pany-2]

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

                 Summary: LDFLAGS=-L/usr/local not at first place honoured
                 Project: GNUstep
            Submitted by: buzzdee
            Submitted on: Mon 09 Feb 2009 08:40:40 PM GMT
                Category: Makefiles
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Hi Nicola,

the trick you told me on FOSDEM unfortunately did not worked out.
I used gnustep-make-2.0.8, installed via ports system, using the filesystem
layout provided there. The layout can be found here:
http://www.openbsd.org/cgi-bin/cvsweb/ports/x11/gnustep/make/files/openbsd?rev=1.2;content-type=text%2Fplain
It is using GNUSTEP_DEFAULT_PREFIX, which is set to /usr/local, and then
defining SYSTEM, LOCAL and NETWORK to the same locations. The plan was to
install base.

the problem again in short:
from ports, there is gobjc library from gcc-4.2 installed, but not the
gcc-4.2, and the library file is in:
/usr/local/lib/libobjc.so.2.0
I use the gcc-3.3 from the system, and the libobjc library, that I want to
use is therefore also the one coming with the system:
/usr/lib/libobjc.so.4.0

sourcing GNUstep.sh, and then running:
./configure
gmake messages=yes
...
cc  -Wl,-E       -fgnu-runtime -o obj/make_strings \
                ./obj/make_strings.m.o ./obj/SourceEntry.m.o
./obj/StringsEntry.m.o ./obj/StringsFile.m.o \
                  -L../../Source/./obj    -L/root/GNUstep/Library/Libraries
-L/usr/local/lib  -L/usr/local/lib -L/usr/local/lib   -lgnustep-base  
-pthread -lobjc   -lgmp -L/usr/local/lib -lgnutls -L/usr/local/lib -lgcrypt
-L/usr/local/lib -lgpg-error -L/usr/local/lib -lintl -L/usr/local/lib -liconv
-liconv -lxslt -L/usr/local/lib -lxml2 -lz -L/usr/local/lib -liconv -lm
-liconv -lffi -lbfd -liberty  -lz -lm

then no /usr/lib is included, and it is linked against the wrong libobjc
library.

running the same commands like this:
LDFLAGS=-L/usr/lib ./configure
LDFLAGS=-L/usr/lib gmake messages=yes
...
cc  -Wl,-E       -fgnu-runtime -o obj/make_strings \
                ./obj/make_strings.m.o ./obj/SourceEntry.m.o
./obj/StringsEntry.m.o ./obj/StringsFile.m.o \
                  -L../../Source/./obj    -L/root/GNUstep/Library/Libraries
-L/usr/local/lib  -L/usr/local/lib -L/usr/local/lib   -lgnustep-base  
-pthread -lobjc   -lgmp -L/usr/local/lib -lgnutls -L/usr/local/lib -lgcrypt
-L/usr/local/lib -lgpg-error -L/usr/local/lib -lintl -L/usr/local/lib -liconv
-liconv -lxslt -L/usr/local/lib -lxml2 -lz -L/usr/local/lib -liconv -lm
-liconv -lffi -lbfd -liberty  -lz -lm

then when linking, /usr/lib is included, but after /usr/local/lib, therefore
base is also linked against the wrong libobjc library.

In both cases, ldd ./Source/obj/libgnustep-base.so.1.18 produces the
following output:
...
        08e73000 28e7a000 rlib 0    1   0      /usr/local/lib/libobjc.so.2.0
...

sebastian




    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Pany-2]

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
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Pany-2]

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

I guess I'll have to go with suggestion #3,

I had a LDFLAG=-L/usr/lib
set to the ./configure and make calls

and was expecting this takes precedence on all the other, so will show up
before /usr/local/lib
but when gcc was linking linking, /usr/local/lib was still before /usr/lib



I hope then ADDITIONAL_LDFLAGS += -L/usr/lib
will then added before -L/usr/local/lib

my problem is, the additional objc lib only creates problem when compiling
the port, when later someone installs the package, and has the wrong lib
installed, then it doesn't matter, because the right one gets picked up.

I'll let you know.

    _______________________________________________________

Reply to this item at:

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

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



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Pany-2]

Update of bug #25536 (project gnustep):

             Open/Closed:                    Open => Closed                

    _______________________________________________________

Follow-up Comment #3:

Closing to tidy up the list of bugs - it was a particular situation with
conflicting libobjc libraries where a hack would be required - not necessarily
a bug in gnustep-make.

Please reopen if there is more input / we can define something I need to fix
in gnustep-make.

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
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep