Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
On Wed, Nov 13, 2013 at 12:52:16PM -0500, Ryan Stone wrote: > On Wed, Nov 13, 2013 at 11:31 AM, Marcus von Appen wrote: > > This brings up another point into which I am running with the previously > > discussed blender issue. > > > > Let's assume port A_defcompiler does not specify a compiler and c++ lib, it > > will default to libc++ and clang++ on 10.x or newer, correct? > > If now a port B_gnuish depends on port A_defcompiler, but at the same > > defines > > GCC + libstdc++, the resulting binary might link against libc++ and > > libstdc++ > > at the same time. This in turn makes the port unusable. The same applies > > to the other way around. > > > > Right now we do not have mechanism to detect and handle those flaws. > > Maintainers > > might be even less aware of those issues. Does anyone know a proper way to > > deal > > with this at the moment on 10.x+ or is this something that was missed until > > now? > > How different is this from the previous situation? As I understand it > previously A_defcompiler would be linked against the system libstdc++ > and B_gnuish would be linked against the gccXX port libstdc++. In my > experience libstdc++ does not have good ABI stability between versions > so shouldn't you have the same potential for problems? I haven't seen a problem with mixing the system's libstdc++ with a version from lang/gcc46. I can assure you that the problem is very really with libc++ vs libstdc++ within the ports collection. To getting working news/pan and math/octave, I had to recompile graphics/graphite2, graphics/libGL, graphics/libGLU, and x11-toolkits/fltk with "USE_GCC=any" to avoid the conflict. Fortunately, I have only another 360 installed ports to check for the conflict. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
On Wed, Nov 13, 2013 at 11:31 AM, Marcus von Appen wrote: > This brings up another point into which I am running with the previously > discussed blender issue. > > Let's assume port A_defcompiler does not specify a compiler and c++ lib, it > will default to libc++ and clang++ on 10.x or newer, correct? > If now a port B_gnuish depends on port A_defcompiler, but at the same > defines > GCC + libstdc++, the resulting binary might link against libc++ and > libstdc++ > at the same time. This in turn makes the port unusable. The same applies > to the other way around. > > Right now we do not have mechanism to detect and handle those flaws. > Maintainers > might be even less aware of those issues. Does anyone know a proper way to > deal > with this at the moment on 10.x+ or is this something that was missed until > now? How different is this from the previous situation? As I understand it previously A_defcompiler would be linked against the system libstdc++ and B_gnuish would be linked against the gccXX port libstdc++. In my experience libstdc++ does not have good ABI stability between versions so shouldn't you have the same potential for problems? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
https://wiki.freebsd.org/NewC++Stack says things about linking against both libc++ and libstdc++ , do they still apply? Best regards Andreas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
Steve Kargl : [...] Sigh. Adding USE_GCC isn't the solution. % pan Segmentation fault (core dumped) % ldd /usr/local/bin/pan | grep ++ libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c52bf000) libc++.so.1 => /usr/lib/libc++.so.1 (0x3c81ea000) This can't be good. And, unfortunately, testing math/octave shows no better :( % octave Segmentation fault (core dumped) % ldd /usr/local/bin/octave-3.6.4 | grep ++ libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) This brings up another point into which I am running with the previously discussed blender issue. Let's assume port A_defcompiler does not specify a compiler and c++ lib, it will default to libc++ and clang++ on 10.x or newer, correct? If now a port B_gnuish depends on port A_defcompiler, but at the same defines GCC + libstdc++, the resulting binary might link against libc++ and libstdc++ at the same time. This in turn makes the port unusable. The same applies to the other way around. Right now we do not have mechanism to detect and handle those flaws. Maintainers might be even less aware of those issues. Does anyone know a proper way to deal with this at the moment on 10.x+ or is this something that was missed until now? Cheers Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
