bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUStep-gui bug in linking order


From: v4hn
Subject: Re: GNUStep-gui bug in linking order
Date: Mon, 23 Sep 2013 01:08:47 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Sep 09, 2013 at 11:23:43PM +0200, Fred Kiefer wrote:
> On 09.09.2013 03:26, v4hn wrote:
> > On Sat, Sep 07, 2013 at 06:49:46PM +0200, Fred Kiefer wrote:
> >> On 07.09.2013 14:23, v4hn wrote:
> >>> reproduce: 1. corrupt your system library, e.g. via`echo > 
> >>> /usr/lib/libgnustep-gui.so` 2. try to build gnustep-gui via 
> >>> `./configure; make`
> [...]
> 
> I finally got around to test this like you suggested and the
> compilation still worked for me. And the produced tools seem to work OK.
> 
> Which release of GNUstep gui are you using? Maybe the problem got
> fixed in between?

Heya over there,

sorry for taking even longer, I'm pretty busy.

I originally hit this bug because I built gnustep-gui 0.23.1 with
giflib 4.1.6, then upgraded giflib to 4.2.1(removing QuantizeBuffer)
and tried to rebuild gnustep-gui (with broken system lib).
This is pretty frustrating because you can't fix a system with a broken system
in this case.

I honestly got no idea why you can't reproduce the problem.
With gnustep-gui 0.23.1 (latest available from your ftp) the problem boils down
to this exact command failing first(after `echo > /usr/lib/libgnuste-gui.so`):

/usr/bin/ld --eh-frame-hdr -m elf_x86_64 -export-dynamic -dynamic-linker 
/lib64/ld-linux-x86-64.so.2 -o obj/set_show_service -s -s 
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../lib64/crt1.o 
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../lib64/crti.o 
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/crtbegin.o -L/usr/lib -L/usr/lib 
-L../Source/./obj -L../Model/./obj -L/root/GNUstep/Library/Libraries -L/usr/lib 
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1 
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../lib64 -L/lib/../lib64 
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../.. -O1 -O1 
--as-needed ./obj/set_show_service.obj/set_show_service.m.o -O1 -O1 --as-needed 
-licui18n -licuuc -licudata -lpng16 -lgnustep-gui -lgnustep-base -lobjc -lm 
-lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc 
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/crtend.o 
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../lib64/crtn.o
/usr/lib/libgnustep-gui.so: file not recognized: File truncated
collect2: error: ld returned 1 exit status

If you really want to investigate why your mileage *does* vary,
you might want to compare how your compile command for 
Tools/obj/set_show_service
is different. The problem is clearly the additional "-L/usr/lib -L/usr/lib" in 
front
of the library path flags and I fixed that in my patch.


I just tried to build your svn trunk but that fails for a different reason:

~/repos/gnustep/core/gui $ ./configure --prefix=/usr
[...]
~/repos/gnustep/core/gui $ make
 Compiling file NSAlert.m ...
In file included from /usr/include/Foundation/NSObjCRuntime.h:45:0,
                 from /usr/include/Foundation/NSObject.h:30,
                 from /usr/include/Foundation/NSDebug.h:38,
                 from NSAlert.m:39:
../Headers/AppKit/NSSavePanel.h:85:1: error: expected declaration specifiers or 
'...' before ')' token
 DEFINE_BLOCK_TYPE(GSSavePanelCompletionHandler, void, NSInteger);
 ^
make[4]: *** [obj/libgnustep-gui.obj/NSAlert.m.o] Error 1
make[3]: *** [internal-library-all_] Error 2


v4hn

Attachment: pgpeZVHuhj1oQ.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]