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
