Well, isn't this an interesting turn of events! So I tried your (Ivan's)
idea of looking at what the linker's doing when the binary is run. This is
the output:
19216:
19216: file=libpoppler-cpp.so.0 [0]; needed by
Source/obj/WindowServer [0]
19216: find library=libpoppler-cpp.so.0 [0]; searching
19216: search path=/home/jamie/Developer/
System/lib/tls/x86_64:/home/jamie/Developer/System/lib/
tls:/home/jamie/Developer/System/lib/x86_64:/home/jamie/
Developer/System/lib (LD_LIBRARY_PATH)
19216: trying file=/home/jamie/Developer/System/lib/tls/x86_64/
libpoppler-cpp.so.0
19216: trying file=/home/jamie/Developer/
System/lib/tls/libpoppler-cpp.so.0
19216: trying file=/home/jamie/Developer/
System/lib/x86_64/libpoppler-cpp.so.0
19216: trying file=/home/jamie/Developer/
System/lib/libpoppler-cpp.so.0
19216:
19216: file=libpoppler-cpp.so.0 [0]; generating link map
19216: dynamic: 0x00007f8f1c191d78 base: 0x00007f8f1bf80000
size: 0x00000000002125d8
19216: entry: 0x00007f8f1bf885e0 phdr: 0x00007f8f1bf80040
phnum: 7
19216:
19216:
19216: file=libgnustep-base.so.1.24 [0]; needed by
Source/obj/WindowServer [0]
19216: find library=libgnustep-base.so.1.24 [0]; searching
19216: search path=/home/jamie/Developer/System/lib
(LD_LIBRARY_PATH)
19216: trying file=/home/jamie/Developer/
System/lib/libgnustep-base.so.1.24
19216: search cache=/etc/ld.so.cache
19216: search path=/lib/x86_64-linux-gnu/
tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/
x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/
x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-
gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64:/
lib/tls:/lib/x86_64:/lib:/usr/lib/tls/x86_64:/usr/lib/tls:/
usr/lib/x86_64:/usr/lib (system search path) 19216:
trying file=/lib/x86_64-linux-gnu/tls/x86_64/libgnustep-base.so.1.24
19216: trying file=/lib/x86_64-linux-gnu/
tls/libgnustep-base.so.1.24
19216: trying file=/lib/x86_64-linux-gnu/
x86_64/libgnustep-base.so.1.24
19216: trying file=/lib/x86_64-linux-gnu/libgnustep-base.so.1.24
19216: trying file=/usr/lib/x86_64-linux-
gnu/tls/x86_64/libgnustep-base.so.1.24
19216: trying file=/usr/lib/x86_64-linux-
gnu/tls/libgnustep-base.so.1.24
19216: trying file=/usr/lib/x86_64-linux-
gnu/x86_64/libgnustep-base.so.1.24
19216: trying file=/usr/lib/x86_64-linux-
gnu/libgnustep-base.so.1.24
19216: trying file=/lib/tls/x86_64/libgnustep-base.so.1.24
19216: trying file=/lib/tls/libgnustep-base.so.1.24
19216: trying file=/lib/x86_64/libgnustep-base.so.1.24
19216: trying file=/lib/libgnustep-base.so.1.24
19216: trying file=/usr/lib/tls/x86_64/libgnustep-base.so.1.24
19216: trying file=/usr/lib/tls/libgnustep-base.so.1.24
19216: trying file=/usr/lib/x86_64/libgnustep-base.so.1.24
19216: trying file=/usr/lib/libgnustep-base.so.1.24
19216:
It's not finding libgnustep-base.so.1.24, but we knew that. Yet I had been
using GNUstep apps with no problem. So I checked doing openapp LevelEditor
and it worked fine, as I expected, and spewed out some 27 MB of diagnostic
messages to the console. Clearly it was finding libgnustep-base.so.1.24. So
why did the app work but not my binary. I tried running LevelEditor
directly. Then this happened:
LD_DEBUG=all ~/Developer/System/bin/LevelEditor
19318:
19318: file=libxmp.so.4 [0]; needed by
/home/jamie/Developer/System/bin/LevelEditor [0]
19318: find library=libxmp.so.4 [0]; searching
19318: search path=/home/jamie/Developer/
System/lib/tls/x86_64:/home/jamie/Developer/System/lib/
tls:/home/jamie/Developer/System/lib/x86_64:/home/jamie/
Developer/System/lib (LD_LIBRARY_PATH)
19318: trying file=/home/jamie/Developer/
System/lib/tls/x86_64/libxmp.so.4
19318: trying file=/home/jamie/Developer/
System/lib/tls/libxmp.so.4
19318: trying file=/home/jamie/Developer/
System/lib/x86_64/libxmp.so.4
19318: trying file=/home/jamie/Developer/System/lib/libxmp.so.4
19318:
19318: file=libxmp.so.4 [0]; generating link map
19318: dynamic: 0x00007f67633cbdc0 base: 0x00007f6763167000
size: 0x00000000002661e0
19318: entry: 0x00007f676316c2e0 phdr: 0x00007f6763167040
phnum: 7
19318:
19318:
19318: file=libsndfile.so.1 [0]; needed by
/home/jamie/Developer/System/bin/LevelEditor [0]
19318: find library=libsndfile.so.1 [0]; searching
19318: search path=/home/jamie/Developer/System/lib
(LD_LIBRARY_PATH)
19318: trying file=/home/jamie/Developer/
System/lib/libsndfile.so.1
19318:
19318: file=libsndfile.so.1 [0]; generating link map
19318: dynamic: 0x00007f6763163d70 base: 0x00007f6762eff000
size: 0x0000000000267f20
19318: entry: 0x00007f6762f057c0 phdr: 0x00007f6762eff040
phnum: 7
19318:
19318:
19318: file=libao.so.4 [0]; needed by
/home/jamie/Developer/System/bin/LevelEditor [0]
19318: find library=libao.so.4 [0]; searching
19318: search path=/home/jamie/Developer/System/lib
(LD_LIBRARY_PATH)
19318: trying file=/home/jamie/Developer/System/lib/libao.so.4
19318: search cache=/etc/ld.so.cache
19318: trying file=/usr/lib/x86_64-linux-gnu/libao.so.4
19318:
19318: file=libao.so.4 [0]; generating link map
19318: dynamic: 0x00007f6762efdda8 base: 0x00007f6762cf6000
size: 0x00000000002087a8
19318: entry: 0x00007f6762cf7e70 phdr: 0x00007f6762cf6040
phnum: 7
19318:
19318:
19318: file=libgnustep-gui.so.0.25 [0]; needed by
/home/jamie/Developer/System/bin/LevelEditor [0]
19318: find library=libgnustep-gui.so.0.25 [0]; searching
19318: search path=/home/jamie/Developer/System/lib
(LD_LIBRARY_PATH)
19318: trying file=/home/jamie/Developer/
System/lib/libgnustep-gui.so.0.25
19318: search cache=/etc/ld.so.cache
19318: search path=/lib/x86_64-linux-gnu/
tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/
x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/
x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-
gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64:/
lib/tls:/lib/x86_64:/lib:/usr/lib/tls/x86_64:/usr/lib/tls:/
usr/lib/x86_64:/usr/lib (system search path) 19318:
trying file=/lib/x86_64-linux-gnu/tls/x86_64/libgnustep-gui.so.0.25
19318: trying file=/lib/x86_64-linux-gnu/
tls/libgnustep-gui.so.0.25
19318: trying file=/lib/x86_64-linux-gnu/
x86_64/libgnustep-gui.so.0.25
19318: trying file=/lib/x86_64-linux-gnu/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/x86_64-linux-
gnu/tls/x86_64/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/x86_64-linux-
gnu/tls/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/x86_64-linux-
gnu/x86_64/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/x86_64-linux-
gnu/libgnustep-gui.so.0.25
19318: trying file=/lib/tls/x86_64/libgnustep-gui.so.0.25
19318: trying file=/lib/tls/libgnustep-gui.so.0.25
19318: trying file=/lib/x86_64/libgnustep-gui.so.0.25
19318: trying file=/lib/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/tls/x86_64/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/tls/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/x86_64/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/libgnustep-gui.so.0.25
19318:
/home/jamie/Developer/System/bin/LevelEditor: error while loading shared
libraries: libgnustep-gui.so.0.25: cannot open shared object file: No such
file or directory
So it's not finding gnustep libs (gui in this case) it on its own, but when
loaded via openapp it does. To confirm this I ran openapp with no
arguments. It would spit out a message about its usage and exit, but should
load gui and/or base. Sure enough, when I run that command I get the same
27 MB of diagnostic messages. So I tried running my program via opentool.
Now I'm getting a segfault, this means it's running. I'll sort out the
cause of the segfault but I'm puzzled as to why openapp and opentool seem
to have this "linker independence".
On Sun, Aug 27, 2017 at 7:26 PM, Jamie Ramone <[email protected]> wrote:
>
>
> On Sun, Aug 27, 2017 at 3:44 PM, Ivan Vučica <[email protected]> wrote:
>
>> Based on your makefile, I suspect you may have installed GNUstep's
>> libraries into ${HOME}/Developer/System/lib, and have not taught the
>> dynamic loader where to find the .so. Just because you've linked with the
>> .a/.so correctly does not mean dynamic loader knows where to find the .so
>> at runtime.
>>
>
> Well, yes. I don't like to mix it with system components lest installing
> other things stomp all over it. I don't trust Ubuntu. But it's weird 'cause
> it works just fine the way I have it set up with everything else that uses
> GNUstep (TextEditor, PicoPixel, Terminal, etc)
>
>
>> That is: Is the path to libgnustep-base.so* specified in /etc/ld.so.conf
>> (or in a file in /etc/ld.so.conf.d)? Which libgnustep-base.so.1.24 is
>> specified in the binary (use ldd on your binary)? I would not put something
>> in ${HOME} into /etc/ld.so.conf, but it can be useful for diagnostics. You
>> can also set LD_LIBRARY_PATH environment variable to expand the search path
>> of the dynamic loader. See https://linux.die.net/man/8/ld.so
>>
>
> I've had LD_LIBRARY_PATH set to /home/jamie/Developer/System/lib for a
> long time. GNUstep is installed into /home/jamie/Developer/System/ (i.e.
> /home/jamie/Developer/System/LocalApps,
> /home/jamie/Developer/System/LocalLibrary,
> /home/jamie/Developer/System/SystemApps,
> /home/jamie/Developer/System/SystemDeveloper,
> and /home/jamie/Developer/System/SystemLibrary). GNUstep is not and never
> was IN the linker's path. I just assumed this was taken care of by
> GNUstep.sh (called at session start), since everything just worked
>
>
>> Or, if what I suggest is not the case, try setting environment variable
>> LD_DEBUG to value 'all' (no quotes) and try running your binary to see what
>> the dynamic loader is doing.
>>
> Or, you can strace your binary and see which paths to
>> libgnustep-base.so.1.24 are being open()ed.
>>
>
> I'll try that, thanx.
>
>
>>
>> On Sun, Aug 27, 2017 at 6:49 PM Jamie Ramone <[email protected]> wrote:
>>
>>> OK, it seems to compile well if poppler if if comes before base
>>> (ADDITIONAL_TOOLS_LIBS) and before the objective c runtime lib
>>> (ADDITIONAL_OBJC_LIBS), but not before everything (using
>>> ADDITIONAL_LDFLAGS). But now, no matter the order, it can't start, claiming
>>> that it can't find libgnustep-base.so.1.24. What things can cause this kind
>>> or error?
>>>
>>> On Sun, Aug 27, 2017 at 9:42 AM, David Chisnall <[email protected]>
>>> wrote:
>>>
>>>> On 27 Aug 2017, at 13:29, Jamie Ramone <[email protected]> wrote:
>>>> >
>>>> >
>>>> >
>>>> > On Sun, Aug 27, 2017 at 5:05 AM, David Chisnall <[email protected]>
>>>> wrote:
>>>> > Most of the code that I’ve written recently using GNUstep has been
>>>> Objective-C++, so I can confirm that this work well (though I’m not using
>>>> gcc, where I believe Objective-C++ still has some rough corners). Looking
>>>> at your nm output, it appears as if the symbols are actually there (at
>>>> least, `_ZN7poppler5imageC2Ev` demangles to `poppler::image::image()`,
>>>> which is one of the missing symbols.
>>>> >
>>>> > Your nm output looks like it’s from a .a file though, not a .so.
>>>> When resolving symbols in static libraries, GNU linkers only look forwards
>>>> in the command line, so if you specify `ld a.a b.a` then undefined symbols
>>>> in `a.a` will be resolved to point to `b.a`, but undefined symbols in `b.a`
>>>> will not be resolved to point to `a.a`. You can solve this by either
>>>> providing the libraries twice (e.g. `ld a.a b.a a.a b.a`), or by using
>>>> --start-group and --end-group (e.g. `ld --start-group a.a b.a
>>>> --end-group`), which searches the archives in the group exhaustively until
>>>> it stops resolving all of the symbols. Or you can use lld, which doesn’t
>>>> have this braindead behaviour (which is both user hostile and increases the
>>>> algorithmic complexity of linking).
>>>> >
>>>> > No, I specifically typed in "nm
>>>> > ~/Developer/System/lib/libpoppler-cpp.so",
>>>> so it's not a static lib. Furthermore, I didn't use the -static flag
>>>> anywhere, and the libs included are done so using -lib_in_question, which
>>>> is only fore shared libs (static ones are just globed onto the collection
>>>> of object files during the link stage i.e. gcc a.o b.o c.o static_lib.a,
>>>> which I don't know how to do in GNUstep make).
>>>> >
>>>> > I’ve found in the past that GNUstep Make’s interfaces for adding
>>>> linker flags leaves a lot to be desired, because it doesn’t give much
>>>> control over where things go on the linker command line, but I believe that
>>>> using the relevant ADDITIONAL_*_LIBS variable will put the -lpoppler-cpp
>>>> flag at the end of the linker command line, which will make it work.
>>>> >
>>>> > Is there one for C++ libs? I checked the docs and it mentions GUI,
>>>> OBJC, and TOOLS. These indicate where, relative to the GNUstep libs in the
>>>> command line the added libs would go, but I'm not sure where I should put
>>>> it. I guess it's time to experiment with these...
>>>>
>>>> The linker doesn’t know or care what language the libraries are written
>>>> in. The GUI, OBJC, and TOOLS refer to the kind of thing you are building
>>>> (thing that uses AppKit, thing that doesn’t use Foundation or AppKit, thing
>>>> that uses only Foundatiion), not the kind of thing that you are linking it
>>>> with.
>>>>
>>>> David
>>>>
>>>>
>>> _______________________________________________
>>> Gnustep-dev mailing list
>>> [email protected]
>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>>>
>>
>
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
