"of course it does" <== Hm. I would say that, given your system dynamic
loader seems to refuse to ... uh ... "dlopen()"[1] the file, the existence
of /home/jamie/Developer/System/lib/libgnustep-base.so.1.24 is far from
given -- that is, I don't think the expression "of course" is appropriate
in this situation.
Yes, by 'Can you open it?' I meant 'can you read it any other process,
under the same conditions as the WindowServer process experiences when
started' (conditions such as what is the running user of the process, for
example).
Either way, it's now totally unclear to me why the dynamic loader would
find the file, then skip it. Maybe someone else has a better idea. If the
file is there, and it's readable, it smells of a possible dynamic loader
bug. Or perhaps the distribution you're using has an obscure security
feature preventing dlopen()-equivalent from the homedir. Both situations
would be very strange to me, and I doubt that's what is happening. *shrug*
I doubt you did this, but does the WindowServer binary have setuid / setgid
bits set on it? LD_LIBRARY_PATH does not work in that case.
While this should not be relevant in a sane environment and if your
binary's file does not have setuid/setgid bits, can you check if you can
still reproduce the problem if you *don't *install GNUstep into your
homedir?
Either way, I do not think this is a GNUstep issue? It seems like a deeper
issue with your system's dynamic loader.
[1]: Let's call it dlopen() for simplicity.
On Sun, Sep 3, 2017 at 12:54 PM Jamie Ramone <sancom...@gmail.com> wrote:
> Yes, of course it does. Open...how? You mean being able to view it's
> contents in mcedit? Yes.
>
> On Sun, Sep 3, 2017 at 7:36 AM, Ivan Vučica <i...@vucica.net> wrote:
>
>> Let's go back :)
>>
>> Does /home/jamie/Developer/System/lib/libgnustep-base.so.1.24 exist? Can
>> you open it?
>>
>> On Sun, Sep 3, 2017, 11:30 Jamie Ramone <sancom...@gmail.com> wrote:
>>
>>> 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 <sancom...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sun, Aug 27, 2017 at 3:44 PM, Ivan Vučica <i...@vucica.net> 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 <sancom...@gmail.com>
>>>>> 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 <thera...@sucs.org>
>>>>>> wrote:
>>>>>>
>>>>>>> On 27 Aug 2017, at 13:29, Jamie Ramone <sancom...@gmail.com> wrote:
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > On Sun, Aug 27, 2017 at 5:05 AM, David Chisnall <thera...@sucs.org>
>>>>>>> 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
>>>>>> Gnustep-dev@gnu.org
>>>>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>>>>>>
>>>>>
>>>>
>>>
>
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
