bugGNUstep - Bugs: bug #25536, LDFLAGS=-L/usr/local not at first...

Group
 
 

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

Submitter:  Sebastian Reitenbach <buzzdee>
Submitted:  Mon 09 Feb 2009 08:40:40 PM UTC
   
 
Category:  Makefiles Severity:  3 - Normal
Item Group:  Bug Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 10 Oct 2009 03:13:58 PM UTC, 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

Nicola Pero <nico>
Group Member
Wed 25 Feb 2009 02:36:41 PM UTC, comment #2: 

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.

Sebastian Reitenbach <buzzdee>
Group Member
Wed 25 Feb 2009 01:12:15 PM UTC, comment #1: 

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

Nicola Pero <nico>
Group Member
Mon 09 Feb 2009 08:40:40 PM UTC, original submission:  

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

Sebastian Reitenbach <buzzdee>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nico (Posted a comment)
  • -email is unavailable- added by buzzdee (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-10-10 nico Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code