libc++ port's undesired side effects (was: graphics/rawtherapee: r342622 crashes on HEAD)

[Matthias Andree]

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.