[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
pgpeZVHuhj1oQ.pgp
Description: PGP signature