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.
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
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.
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
