libcxx invades undocumented on Mac OS X 10.6.8, Snow Leopard, the file system and leaves unregstered files

[ballapete (Peter "Pete" Dyballa)]

port -v install libcxx
--->  Fetching archive for libcxx
Attempting to fetch http://packages.macports.org/libcxx/libcxx-5.0.1_5%2Bemulated_tls%2Buniversal.darwin_10.i386-x86_64.tbz2
Attempting to fetch http://packages.macports.org/libcxx/libcxx-5.0.1_5%2Bemulated_tls%2Buniversal.darwin_10.i386-x86_64.tbz2.rmd160
--->  Installing libcxx @5.0.1_5+emulated_tls+universal
--->  Activating libcxx @5.0.1_5+emulated_tls+universal
x ./
x ./+COMMENT
x ./+CONTENTS
x ./+DESC
x ./+PORTFILE
x ./+STATE
x ./opt/
x ./opt/local/
x ./opt/local/var/
x ./opt/local/var/system_roots/
x ./opt/local/var/system_roots/libcxx-5.0.1-5.tgz
--->  Cleaning libcxx
--->  Removing work directory for libcxx
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.

pete 57 /\  ls -l /usr/lib/lib{,std}c++*
-rwxr-xr-x  1 root  admin   2304336  3 Aug  2022 /usr/lib/libc++.1.dylib
lrwxr-xr-x  1 root  admin        14  3 Aug  2022 /usr/lib/libc++.dylib -> libc++.1.dylib
-rwxr-xr-x  1 root  admin    469888  3 Aug  2022 /usr/lib/libc++abi.dylib
-rw-r--r--  1 root  wheel  15401916 24 Okt  2010 /usr/lib/libstdc++-static.a
-rwxr-xr-x  1 root  wheel   2439888 18 Mai  2009 /usr/lib/libstdc++.6.0.9.dylib
lrwxr-xr-x  1 root  wheel        21 23 Feb 11:07 /usr/lib/libstdc++.6.dylib -> libstdc++.6.0.9.dylib
========================================================
pete 58 /\  ls -l /opt/local/var/system_roots/libcxx-5.0.1-5.tgz
-rw-r--r--  1 root  admin  714906  3 Aug  2022 /opt/local/var/system_roots/libcxx-5.0.1-5.tgz
pete 59 /\  tar vtf /opt/local/var/system_roots/libcxx-5.0.1-5.tgz
drwxr-xr-x  0 root   admin       0  3 Aug  2022 ./
drwxr-xr-x  0 root   admin       0  3 Aug  2022 ./usr/
drwxr-xr-x  0 root   admin       0  3 Aug  2022 ./usr/include/
drwxr-xr-x  0 root   admin       0  3 Aug  2022 ./usr/lib/
-rwxr-xr-x  0 root   admin 2304336  3 Aug  2022 ./usr/lib/libc++.1.dylib
lrwxr-xr-x  0 root   admin       0  3 Aug  2022 ./usr/lib/libc++.dylib -> libc++.1.dylib
-rwxr-xr-x  0 root   admin  469888  3 Aug  2022 ./usr/lib/libc++abi.dylib
-rwxr-xr-x  0 root   admin    2032  3 Aug  2022 ./usr/include/__cxxabi_config.h
-rwxr-xr-x  0 root   admin    6949  3 Aug  2022 ./usr/include/cxxabi.h

[jmroot (Joshua Root)]

Yes, as mentioned in the port description, it installs into /usr/lib on 10.6 because there is no system libc++ there. IIRC there were slightly complicated reasons why it creates the files during activation.

[jmroot (Joshua Root)]

Ticket #42385 is the reason.

[ballapete (Peter "Pete" Dyballa)]

When are these files needed by which executable? It's now a decade later and those old Clang or Clang++ compilers are out of use. And it's a buggy port: the files listed are *not* uninstalled.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ballapete:

When are these files needed by which executable?

libc++ is needed by executables whose code was written in C++.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ballapete:

It's now a decade later and those old Clang or Clang++ compilers are out of use.

What clang are you talking about? #42385 didn't mention clang and is not specific to any port.

And it's a buggy port: the files listed are *not* uninstalled.

I agree with this. The port used to install its files normally, so that they would be uninstalled normally, but #42385 demonstrated a case where that would cause a problem, so it was changed to install its files in a nonstandard way and not uninstall its files at all. Ideally the port should be changed so that it uninstalls its files when doing so would not be a problem.

[jmroot (Joshua Root)]

Replying to ryandesign:

Ideally the port should be changed so that it uninstalls its files when doing so would not be a problem.

Sure. When doing so would not be a problem is basically when it's still on < 10.7 when the deactivate target is run.

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign:

Replying to ballapete:

libc++ is needed by executables whose code was written in C++.

Ins't this file installed in /opt/local/libexec/<compiler>/...? And the compiler cannot find its constituents?