[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: linking a C++ lib to an objc tool.
|
From: |
Matt Rice |
|
Subject: |
Re: linking a C++ lib to an objc tool. |
|
Date: |
Sun, 3 Sep 2017 12:19:32 -0700 |
Another question is, which libraries is it finding at link time,
it could be that e.g. the file exists but is of the wrong architecture
(in which case i forget what happens)
but adding LDFLAGS=-Wl,--verbose should print out which library is
being linked against
(It may be easiest to just make messages=yes then copy/paste add
-Wl,--verbose to the link command, I at least don't remember the
correct gnustep-make variable to use)
also note that openapp sources a GNUstep.sh
On Sun, Sep 3, 2017 at 11:20 AM, Ivan Vučica <address@hidden> wrote:
> "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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Aug 27, 2017 at 3:44 PM, Ivan Vučica <address@hidden> 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 <address@hidden>
>>>>>> 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 <address@hidden>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 27 Aug 2017, at 13:29, Jamie Ramone <address@hidden> wrote:
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On Sun, Aug 27, 2017 at 5:05 AM, David Chisnall
>>>>>>>> > <address@hidden> 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
>>>>>>> address@hidden
>>>>>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>>>>>
>>>>>
>>>>
>>
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>