[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Crash occurs when catching std::exception in Objective-C++ code comp
Re: Crash occurs when catching std::exception in Objective-C++ code compiled with clang on Linux and using libobjc2
Mon, 4 Dec 2017 18:30:26 +0000
On 4 Dec 2017, at 17:49, Lobron, David <address@hidden> 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 ->
> -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.