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
