Baptiste, Bryan, we may want to move the port's libc++.so (and requisites) into a subdirectory so we don't lump it in a ports standard library path. See below for more, look for your name if pressed for time.
Rainer Hurling wrote earlier today: > Yes, this presumption is right. After 'pkg delete -f libc++-200683 > libcxxrt-20131225_1' I am able to use rawtherapee furthermore. So ports > like RawTherapee would also work, when devel/libc++ and devel/libcxxrt > would be deinstalled right after successfull installation of the port. Rainer, So there is not a dependency that should be recorded in the port. It still is with pkgNG as you show below. > My problem is more the other side around: Why do ports like e.g. > graphics/darktable pick up the headers from devel/libc++ instead of the > base ones? In darktable there is no devel/libc++ dependency specified. > Installing graphics/darktable, while devel/libc++ is already installed, > creates a dependency. Because they use other headers and libraries from the same paths. > This will jumble up the dependency list in ports/packages and should not > happen. Only ports with a declared dependency on devel/libc++ should use > this port. [Moved here from end of Rainer's message:] > #ldd /usr/local/bin/darktable | grep c++ > libc++.so.1 => /usr/local/lib/libc++.so.1 (0x4690e000) It does not create a dependency in the strict sense. The port only states it needs libc++.so.1 (and libcairomm-1.0.so.1 to pick a random sample, and many others), and it states a run-time linker path extension (RPATH) tag. Which actual library file is used by the run-time linker is _not_ recorded in the binary but resolved in the order specified in the "ld.so" manual page, and according to that search path, it just happens that /usr/local/lib/libc++.so.1 shadows /usr/lib/libc++.so.1. Now you found out in your run-time experiment that you are able to remove /usr/local/lib/libc++.so.1, and you will then find that the same ldd command as you show below would resolve from /usr/lib/libc++.so.1 instead of /usr/local/lib/libc++.so.1. And that is the reason why I have not recorded a run-time dependency in Rawtherapee's Makefile on systems that have libc++ in a default base install. Baptiste: We might want to move libc++.so to a subdirectory from /usr/local/lib so we might detect incompatibilities between base and port libc++.so sooner. Possible locations are: /usr/local/lib/c++/v1 to mirror the include file structure, or /usr/local/c++/v1/lib, and moving headers to /usr/lcoal/c++/v1/include, to share a common prefix for CPPFLAGS -I options and LDFLAGS -L options. >>> #pkg info -r libc++-200683 >>> libc++-200683: >>> rawtherapee-4.0.12_1 >>> darktable-1.2.3_3 Baptiste, Bryan, and that appears to be an artifact of pkg, and a (possibly deliberate "regression"). These dependees should not be listed. Please abstain from hasty commits to just the libc++, we'll need to coordinate our changes in proper cadence to avoid bringing lots of compatibility baggage in, and to avoid breaking the ports that require the libc++ in some way. The port explicitly specifies a BUILD_DEPENDS, so we should not have a run-time dependency. pkg_add does not report such a bogus dependency. I think we may want to either change pkg to not record BUILD_DEPENDS, or if that is not desired, revise the install layout of the libc++ port so that the port would normally reference /usr/lib/libc++.so if present, to avoid adding the run-time dependency. _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
