GNAT Build: xg++ compile step error

[wiremoons]

Hi

When building GNAT (Ada) I get the error: ld: warning: directory not found for option '-L/Users/simon/ada/lib/gcc/11/gcc/aarch64-apple-darwin21/12/adalib/' when the final xg++ step is run.

The directory it is unable to find in the reported error does not exist yet, as that is the destination directory that will only exist once make install is run following the build, as it is part of the --prefix=$HOME/ada path for the build.

If an empty directory is created with: mkdir -p /Users/simon/ada/lib/gcc/11/gcc/aarch64-apple-darwin21/12/adalib/ and make is re-run following the error, then the compile finishes without any issues.

Is it an error in the generated Makefile using the target path instead of the build path perhaps?

Full output of the failing part is below:

... prior build output removed

GNATLINK 12.0.1 20220401 (wiremoons)
Copyright (C) 1995-2022, Free Software Foundation, Inc.
xgcc -c -gnatA -gnatWb -gnatiw -B../../ -I- -I../rts -I. -I/Users/simon/scratch/ada/builds/gcc-darwin-arm64/gcc/ada -gnatws /Users/simon/scratch/ada/builds/gcc-darwin-arm64/build/gcc/ada/tools/b~gnatclean.adb

/Users/simon/scratch/ada/builds/gcc-darwin-arm64/build/gcc/xg++ b~gnatclean.o ../version.o ../link.o ../targext.o ../../ggc-none.o ../rts/ada.o ../rts/a-charac.o ../rts/a-chlat1.o ../rts/interfac.o ../rts/system.o ../rts/s-addope.o ../rts/s-atoope.o ../rts/s-imgint.o ../rts/s-io.o ../rts/s-parame.o ../rts/s-crtl.o ../rts/i-cstrea.o ../rts/s-stoele.o ../rts/s-stache.o ../rts/s-strhas.o ../rts/s-htable.o ../rts/s-string.o ../rts/s-traent.o ../rts/s-unstyp.o ../rts/s-wchcon.o ../rts/s-wchjis.o ../rts/s-wchcnv.o ../rts/s-carun8.o ../rts/s-conca2.o ../rts/s-traceb.o ../rts/s-excdeb.o ../rts/s-wchstw.o ../rts/a-elchha.o ../rts/a-exctra.o ../rts/s-addima.o ../rts/s-exctab.o ../rts/s-except.o ../rts/s-excmac.o ../rts/s-memory.o ../rts/s-secsta.o ../rts/s-soliin.o ../rts/s-soflin.o ../rts/s-stalib.o ../rts/s-trasym.o ../rts/a-except.o ../rts/a-assert.o ../rts/a-comlin.o ../rts/a-ioexce.o ../rts/a-string.o ../rts/a-stuten.o ../rts/a-suewst.o ../rts/a-suezst.o ../rts/gnat.o ../rts/g-htable.o ../rts/g-io.o ../rts/g-string.o ../rts/i-c.o ../rts/s-atopri.o ../rts/s-atocou.o ../rts/s-aotase.o ../rts/s-casuti.o ../rts/g-casuti.o ../rts/s-fatflt.o ../rts/s-fatlfl.o ../rts/s-fatllf.o ../rts/s-os_lib.o ../rts/g-os_lib.o ../rts/s-valuti.o ../rts/s-valllu.o ../rts/a-tags.o ../rts/a-sttebu.o ../rts/a-stbuut.o ../rts/s-putima.o ../rts/a-stream.o ../rts/s-ficobl.o ../rts/s-finroo.o ../rts/a-finali.o ../rts/s-fileio.o ../rts/s-stopoo.o ../rts/s-finmas.o ../rts/s-spsufi.o ../rts/s-stposu.o ../rts/s-statxd.o ../rts/s-stratt.o ../rts/s-valuns.o ../rts/s-valint.o ../rts/a-textio.o ../rts/g-byorma.o ../rts/g-dynhta.o ../rts/s-assert.o ../rts/s-bitops.o ../rts/a-strmap.o ../rts/a-stmaco.o ../rts/a-chahan.o ../rts/a-strsea.o ../rts/a-strfix.o ../rts/a-strunb.o ../rts/g-dirope.o ../rts/s-pooglo.o ../rts/s-regexp.o ../rts/g-regexp.o ../rts/g-comlin.o ./debug.o ./types.o ./alloc.o ./gnatvsn.o ./hostparm.o ./opt.o ./csets.o ./output.o ./rident.o ./seinfo.o ./stand.o ./stylesw.o ./table.o ./elists.o ./uintp.o ./urealp.o ./widechar.o ./namet.o ./butil.o ./casing.o ./err_vars.o ./fmap.o ./sdefault.o ./targparm.o ./osint.o ./fname.o ./osint-m.o ./sinfo.o ./snames.o ./ali.o ./einfo.o ./scans.o ./einfo-entities.o ./nlists.o ./aspects.o ./atree.o ./einfo-utils.o ./sinfo-nodes.o ./sinput.o ./sinfo-utils.o ./stringt.o ./erroutc.o ./styleg.o ./errutil.o ./make_util.o ./switch.o ./clean.o ./gnatclean.o ../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a ../rts/libgnat.a -liconv ../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a -no-pie -o ../../gnatclean -L../rts/ -L./ -L/Users/simon/scratch/ada/builds/gcc-darwin-arm64/gcc/ada/ -L/Users/simon/ada/lib/gcc/11/gcc/aarch64-apple-darwin21/12/adalib/ /Users/simon/scratch/ada/builds/gcc-darwin-arm64/build/gcc/ada/rts/libgnat.a -B../../ -B../../../aarch64-apple-darwin21/libstdc++-v3/src/.libs -B../../../aarch64-apple-darwin21/libstdc++-v3/libsupc++/.libs -L../../../aarch64-apple-darwin21/libstdc++-v3/src/.libs -L../../../aarch64-apple-darwin21/libstdc++-v3/libsupc++/.libs -static-libstdc++ -static-libstdc++ -static-libgcc
ld: warning: directory not found for option '-L/Users/simon/ada/lib/gcc/11/gcc/aarch64-apple-darwin21/12/adalib/'

The build Makefile was created with:

../configure --prefix=$HOME/ada\
             --libdir=$HOME/ada/lib/gcc/11\
             --disable-nls\
             --disable-multilib\
             --enable-checking=release\
             --with-gcc-major-version-only\
             --enable-languages=c,c++,ada\
             --with-pkgversion='wiremoons FSF GNAT Ada 12.0.1_1'\
             --build=aarch64-apple-darwin21\
             --with-system-zlib\
             --with-native-system-header-dir=/usr/include\
             --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk

Other supporting details of the system being used to build are below - but let me know if you need any further information.

% sw_vers 
ProductName:	macOS
ProductVersion:	12.3.1
BuildVersion:	21E258

% clang --version
Apple clang version 13.1.6 (clang-1316.0.21.2)
Target: arm64-apple-darwin21.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

% system_profiler SPHardwareDataType        
Hardware:

      Model Name: MacBook Pro
      Model Identifier: MacBookPro18,1
      Chip: Apple M1 Pro
      Total Number of Cores: 10 (8 performance and 2 efficiency)
      Memory: 16 GB
      System Firmware Version: 7459.101.3
      OS Loader Version: 7459.101.3

# existing GNAT being used for the Ada build:
% gnat --version 
GNAT 12.0.1 20220312 (experimental)
Copyright (C) 1996-2022, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[simonjwright]

Why specify --libdir=$HOME/ada/lib/gcc/11 rather than leaving the build to its own devices (as far as this is concerned, anyway!)

[iains]

sorry I have not had chance to look at this so far...

• it is not specific to the aarch64 port or to a custom libdir ....

e.g. x86_64-darwin18:

ld: warning: directory not found for option '-L/opt/iains/x86_64-apple-darwin18/gcc-12-0-1/lib/gcc/x86_64-apple-darwin18/12.0.1/adalib/'

.. thus it should be filed in the GCC bugzilla so that the Adacore folks can take a look at it.

NOTE: that GCC does, during the build process, inject the final installation directories in a number of places - this is not usually an issue (but I'd be first to say it would be nice to reduce build warning output).

[simonjwright]

I get the error: ld: warning: directory not found

Not an error!

Because of the amazing amount of noise, I’ve tended to regard anything that doesn’t stop the build as uninteresting unless something about the complete build justifies further investigation.

Anyway, I still don’t get why --libdir?

[iains]

I get the error: ld: warning: directory not found

Not an error!

Well, at the risk of defending an undesirable situation (that we get non-fatal build warnings, which we do)...

... during the build, the compiler constructs command lines with the final installation paths + the temporary ones for the build directories. Therefore, because the install directories are absent (at that stage) the linker warns about it.

The actual error would be if a dependent library could not be found - and that, of course, would stop the build.

If we wanted to avoid this, I suppose we'd have to have different sets of paths for the build and installed compilers - and that's kind of tricky because some of those paths are part of the build. It is much easier to append -B and -L for the build directories.

Because of the amazing amount of noise, I’ve tended to regard anything that doesn’t stop the build as uninteresting unless something about the complete build justifies further investigation.

I think we all do that [or, at least, investigate once and then blank out the relevant cases] ... I did make a build of ranlib that does not report the 'no symbols in' for empty objects since in a GCC build (and LLVM, for that matter) .. that is just noise.

Anyway, I still don’t get why --libdir?

Well, I can't speak for the OP - but distributions do choose their own layout to enable management of installing multiple GCC versions. .. as it happens Ada's libs are always stored in a versioned directory .. but the other compiler runtime libraries are not (thus you need to do something if you want to have multiple GCC versions in the same PATH).

[iains]

anyway - this particular issue is not specific to the arm64 port, so if folks want to pursue it further - it would be better to file a GCC bugzilla PR (any fix for this would need to be made to GCC master and then pulled across to the arm64 branches).

[wiremoons]

Thanks for looking at the issue @iains. If it is an upstream concern, then happy to close here. I wasn't sure of the cause - so thank for the explanations in the messages exchanged above.

The reason for --libdir was as you explained - that I had multiple installs/builds, and wanted to ensure the different builds used their own GCC compiled versions.

[iains]

I am going to close this here - please note the upstream Bugzilla report if you opened one, for reference.