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
