On 4 Dec 2017, at 17:49, Lobron, David <[email protected]> wrote: > > I just wanted to let people know that this was fixed when I upgrade my > gnustep-make from 2.6.x to 2.7.0, which has support for the > --with-library-combo=ng-gnu-gnu option. That stopped the -fgnu-runtime flag > from being issued, and C++ exceptions now work in my ObjC++ code.
Thanks. I hadn’t realised this flag was required (I assumed it would auto-detect the runtime and provide the correct flags), but I have now updated the FreeBSD port of gnustep-make to provide this flag and it now appears to be providing the correct flags for everything. > I did encounter one other issue: the linker complained that it could not find > libobjcxx.so.4.6, needed by libobjc.so, even though those are in the same > directory, and there is a "libobjcxx.so" symlink that points to > libobjcxx.so.4.6. The directory is being specified in the -L options, and > it's clearly being found, because libobjc.so is found there: > > $ ls -l libobj* > lrwxrwxrwx 1 dlobron staff 14 Dec 1 16:08 libobjc.so -> libobjc.so.4.6 > -rw-r--r-- 1 dlobron staff 246455 Dec 1 16:08 libobjc.so.4.6 > lrwxrwxrwx 1 dlobron staff 16 Dec 1 16:08 libobjcxx.so -> > libobjcxx.so.4.6 > -rw-r--r-- 1 dlobron staff 19112 Dec 1 16:08 libobjcxx.so.4.6 > > I worked around this by adding "-l :libobjcxx.so" to my link options, which > fixed the problem. However, I'm curious as to why the linker doesn't find > libobjcxx.so on its own, without the explicit -l prompt. I've copied the > link command and error below, in case any compiler/linker expert has > knowledge of this. This is odd, but may be caused by an rpath being set when building libobjc.so. The best fix for this is for us to just stop building libobjcxx and depend on libstdc++ on platforms that don’t build their C++ stack in a sane way. David _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
