Re: linking a C++ lib to an objc tool.

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

Re: linking a C++ lib to an objc tool.

"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

Re: linking a C++ lib to an objc tool.

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

Re: linking a C++ lib to an objc tool.

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

Re: linking a C++ lib to an objc tool.

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

Re: linking a C++ lib to an objc tool.

On Sun, Aug 27, 2017 at 3:44 PM, Ivan Vučica 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

Re: linking a C++ lib to an objc tool.

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.

Re: linking a C++ lib to an objc tool.

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

Re: linking a C++ lib to an objc tool.

On 27 Aug 2017, at 13:29, Jamie Ramone wrote: > > > > On Sun, Aug 27, 2017 at 5:05 AM, David Chisnall 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

Re: linking a C++ lib to an objc tool.

On Sun, Aug 27, 2017 at 5:05 AM, David Chisnall 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

Re: linking a C++ lib to an objc tool.

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,

Re: linking a C++ lib to an objc tool.

Well that was a colossal waste of time. Interestingly, I found I cud get rid of the other dependencies, SDL1 and Freetype, as they are no longer needed by the main binary. So the ONLY requirement is poppler-cpp, so shuffling it is pointless. Here's the contents of the make files (if it helps):

Re: linking a C++ lib to an objc tool.

On Sat, Aug 26, 2017 at 9:59 PM, Ivan Vučica wrote: > Order in which you specify things to be linked (object files and libraries) > may matter. Have you tried moving -lpoppler-cpp around? Hmm, I must admit I hadn't even thought about that. I'll give it a go and see what happens.

Re: linking a C++ lib to an objc tool.

Order in which you specify things to be linked (object files and libraries) may matter. Have you tried moving -lpoppler-cpp around? Has the code you're building ever been successfully linked? Is this code published? On Sat, Aug 26, 2017 at 11:25 PM Jamie Ramone wrote: >

Re: linking a C++ lib to an objc tool.

1) Are you referring to the external library I'm trying to link against? It's poppler-cpp Output: U abort@@GLIBC_2.2.5 002125b8 B __bss_start 002125b8 b completed.7585 ebe0 r CSWTCH.189 ebc0 r CSWTCH.191 U

Re: linking a C++ lib to an objc tool.

Could you point us out to: 1) the output of running `nm libYourLibrary.so` 2) the header declarations for the functions you are using 3) the error output of the linker? -- Daniel. Em 26 de ago de 2017 19:03, "Jamie Ramone" escreveu: > Hello world! I'm trying to build a

linking a C++ lib to an objc tool.

Hello world! I'm trying to build a project of mine in GNUstep which requires some functionality provided by an external library, which is in C++. I tried to build it with portions in Objc++ but faild. I said it couldn't find the symbols it needed (calls to the methods of c++ objects). So I rewrote