Bug 214405 - base/gcc (r424540) for TARGET_ARCH=powerpc64: g++ does not find the standard c++ headers (file placement vs. lookup mismatch)
Summary: base/gcc (r424540) for TARGET_ARCH=powerpc64: g++ does not find the standard ...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: powerpc Any
: --- Affects Only Me
Assignee: powerpc
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-10 18:46 UTC by Mark Millard
Modified: 2018-05-27 02:41 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Millard 2016-11-10 18:46:59 UTC
[This is after dealing with mpfr 3.1.4 vs. 3.1.5, adding gcc and g++ commands to my environment, and updating pkg.plist for TARGET_ARCH=powerpc64 . Also after various on-powerpc64 fixes to various gcc (and g++) file path vs. lookup mismatches via adding a few symbolic links. This is use on the powerpc64 context, not the cross build.]

This was noticed via trying to build benchmarks/bonnie++ (via portmaster):

> --- bon_csv2html.o ---
> c++ -pipe -g -fno-strict-aliasing  -DNDEBUG -Wall -W -Wshadow -Wpointer-arith -Wwrite-strings -pedantic -ffor-scope -Wcast-align -Wsign-compare -Wpointer-arith -Wwrite-strings -Wformat-security -Wswit
> ch-enum -Winit-self    -pipe -g -fno-strict-aliasing  -c bon_csv2html.cpp -o bon_csv2html.o
. . .
> --- bon_csv2html.o ---
> bon_csv2html.cpp:2:19: fatal error: cstdlib: No such file or directory
> compilation terminated.
> *** [bon_csv2html.o] Error code 1
> 
> make[2]: stopped in /usr/obj/portswork/usr/ports/benchmarks/bonnie++/work/bonnie++-1.97.2
> --- bonnie++.o ---
> bonnie++.cpp:31:18: fatal error: algo.h: No such file or directory
> compilation terminated.

In the file system there are:

> # find / -name "cstdlib" -print | more                                                                                                                                                                 
> /usr/include/c++/v1/tr1/cstdlib
> /usr/include/c++/v1/cstdlib
> /usr/src/contrib/libc++/include/cstdlib
> /usr/src/contrib/libstdc++/include/tr1/cstdlib

Using a simpler program:

> # c++ main.cc
> main.cc:1:19: fatal error: cstdlib: No such file or directory
> compilation terminated.

"truss -f c++ main.cc" reports for cstdlib references:

> # truss -f c++ main.cc 2>&1 | grep cstdlib
> 95852: read(3,"#include <cstdlib>\n\n// Avoid n"...,1309) = 1309 (0x51d)
> 95852: lstat("/usr/lib/gcc/powerpc64-portbld-freebsd12.0/5.4.0/include/cstdlib",0xffffffffffffba20) ERR#2 'No such file or directory'
> 95852: stat("/usr/lib/gcc/powerpc64-portbld-freebsd12.0/5.4.0/include/cstdlib.gch",0xffffffffffffcbd8) ERR#2 'No such file or directory'
> 95852: openat(AT_FDCWD,"/usr/lib/gcc/powerpc64-portbld-freebsd12.0/5.4.0/include/cstdlib",O_RDONLY|O_NOCTTY,00) ERR#2 'No such file or directory'
> 95852: lstat("/usr/lib/gcc/powerpc64-portbld-freebsd12.0/5.4.0/include-fixed/cstdlib",0xffffffffffffba20) ERR#2 'No such file or directory'
> 95852: stat("/usr/lib/gcc/powerpc64-portbld-freebsd12.0/5.4.0/include-fixed/cstdlib.gch",0xffffffffffffcbd8) ERR#2 'No such file or directory'
> 95852: openat(AT_FDCWD,"/usr/lib/gcc/powerpc64-portbld-freebsd12.0/5.4.0/include-fixed/cstdlib",O_RDONLY|O_NOCTTY,00) ERR#2 'No such file or directory'
> 95852: lstat("/usr/include/cstdlib",0xffffffffffffba20) ERR#2 'No such file or directory'
> 95852: stat("/usr/lib/gcc/powerpc64-portbld-freebsd12.0/5.4.0/../../../../powerpc64-portbld-freebsd12.0/include/cstdlib.gch",0xffffffffffffcbd8) ERR#2 'No such file or directory'
> 95852: openat(AT_FDCWD,"/usr/lib/gcc/powerpc64-portbld-freebsd12.0/5.4.0/../../../../powerpc64-portbld-freebsd12.0/include/cstdlib",O_RDONLY|O_NOCTTY,00) ERR#2 'No such file or directory'
> 95852: read(4,"#include <cstdlib>\n\n// Avoid n"...,32768) = 1309 (0x51d)
> main.cc:1:19: fatal error: cstdlib: No such file or directory

So in finding no cstdlib c++ (g++) looks for each of:

> /usr/lib/gcc/powerpc64-portbld-freebsd12.0/5.4.0/include/cstdlib
> /usr/lib/gcc/powerpc64-portbld-freebsd12.0/5.4.0/include/cstdlib.gch
> /usr/lib/gcc/powerpc64-portbld-freebsd12.0/5.4.0/include-fixed/cstdlib
> /usr/lib/gcc/powerpc64-portbld-freebsd12.0/5.4.0/include-fixed/cstdlib.gch
> /usr/include/cstdlib
> /usr/powerpc64-portbld-freebsd12.0/include/cstdlib.gch
> /usr/powerpc64-portbld-freebsd12.0/include/cstdlib

none of which match the file system. No trivially small number of symbolic links in the file system can cover making all the involved paths for various headers work (each "include" already exists and has files): each header must be done separately as things are.
Comment 1 Mark Millard 2016-11-10 23:10:01 UTC
(In reply to Mark Millard from comment #0)

I have not placed symbolic links (or hard links) for the stand C++ headers (and their supporting headers) and so have no workaround in place for this issue.

So my testing of base/gcc (and base/binutils) stopped with this for now.

I will note that the little bit of attempted use of base/gcc had issues that I'd not fully tracked down. For example gettext-runtime's build classified libasprintf as not to be built when cc and c++ pointed to the base/gcc compilers. (That in turn lead to gettext-runtime failing to finish its install.)

[Switching cc and c++ back to clang and clang++ did not have this problem. Note that I've been one of the folks experimenting with finding powerpc64 and powerpc clang/clang++ targeting problem details for submittal to llvm and so use them despite their not being ready for general use for those targets yet. This switch is not an option for most folks.]
Comment 2 Steve Wills freebsd_committer 2018-02-13 17:08:14 UTC
I think this is resolved by the changes in bug 224217. Please confirm.
Comment 3 Mark Millard 2018-02-17 06:12:19 UTC
(In reply to Steve Wills from comment #2)

This will have to wait for experiments on a powerpc64
after having installed what base/binutils and base/gcc
built, probably needing to uninstall the likes of
devel/binutils and devel/powerpc64-gcc first.

(A worry here would be picking up C++
standard headers from the wrong place but
files being found from ports installations.)
Comment 4 Mark Millard 2018-05-27 02:41:27 UTC
(In reply to Mark Millard from comment #3)

I did not get to this before losing access to
the powerpc family members for what will likely
be weeks/months(?). Sorry. [My FreeBSD time has
been very limited in recent months compared
prior recent years.]