Bug 97865 - libtool needs to be updated for Darwin20.
Summary: libtool needs to be updated for Darwin20.
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 11.0
: P3 normal
Target Milestone: ---
Assignee: Iain Sandoe
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-16 20:49 UTC by Jürgen Reuter
Modified: 2021-10-01 23:11 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-11-17 00:00:00


Attachments
fix under test (2.16 KB, application/mbox)
2020-11-17 21:23 UTC, Iain Sandoe
Details
regenerated files (27.24 KB, application/x-bzip2)
2020-11-17 21:24 UTC, Iain Sandoe
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jürgen Reuter 2020-11-16 20:49:55 UTC
libtool and configure do not correctly cover macOS Big Sur as the Darwin version now reached 20 and the MACOSX_DEPLOYMENT_TARGET 11.x instead of 10.x.
All configure's need to be updated for the dynamic linking:
e.g. for libtool.m4
$ git diff
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index f2d1f398..be9d50f3 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1072,11 +1072,11 @@ _LT_EOF
       # to the OS version, if on x86, and 10.4, the deployment
       # target defaults to 10.4. Don't you love it?
       case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
-    10.0,*86*-darwin8*|10.0,*-darwin[[91]]*)
+    10.0,*86*-darwin8*|10.0,*-darwin[[912]]*)
       _lt_dar_allow_undefined='$wl-undefined ${wl}dynamic_lookup' ;;
     10.[[012]][[,.]]*)
       _lt_dar_allow_undefined='$wl-flat_namespace $wl-undefined ${wl}suppress' ;;
-    10.*)
+    10.*|11.*)
       _lt_dar_allow_undefined='$wl-undefined ${wl}dynamic_lookup' ;;
       esac
     ;;

etc. This then turns into configure. Without this gcc, gfortran and the dynamic libraries get built wiht -flat_namespace instead of dynamic_lookup.
Comment 1 Eric Gallager 2020-11-16 21:12:33 UTC
This should probably handled by upstream libtool
Comment 2 Jürgen Reuter 2020-11-16 21:56:09 UTC
(In reply to Eric Gallager from comment #1)
> This should probably handled by upstream libtool

Indeed I reported this to libtool as well, and I was not the first apparently. How do you include this? In our code there is a libtool.m4, and then all configures are generated via autoreconf from there. This seems more complicated for the build system of gcc/g++/gfortran.
Comment 3 Iain Sandoe 2020-11-17 09:58:01 UTC
I didn't have x86 Big Sur until the weekend - still working through things.

1/

The change you have keeps the default as $wl-undefined ${wl}dynamic_lookup, which is no longer ideal - Darwin [at least in GCC] should only use that as a conscious decision (when we know it's required) otherwise it just suppresses errors on missing symbols until runtime.

2/

We probably also need to import the latest config.sub etc.

3/

Some of this stuff we patch locally, some we import - need to check which is which; and make a suitable patch.

FWIW:

these are the changes I made on my Arm64 branch:

https://github.com/iains/gcc-darwin-arm64/commit/b71edb3c04914762e9f06da5f676009eff6e003f

https://github.com/iains/gcc-darwin-arm64/commit/d6d94ab4c08f8ace4ea76773060604656de2f846
Comment 4 Jürgen Reuter 2020-11-17 10:12:39 UTC
(In reply to Iain Sandoe from comment #3)
> I didn't have x86 Big Sur until the weekend - still working through things.
> 
> 1/
> 
> The change you have keeps the default as $wl-undefined ${wl}dynamic_lookup,
> which is no longer ideal - Darwin [at least in GCC] should only use that as
> a conscious decision (when we know it's required) otherwise it just
> suppresses errors on missing symbols until runtime.
> 


I was trying it out on a regular Intel chip, not yet the new architecture. It seems for libgfortran and gfirtran it is still needed.
Comment 5 Iain Sandoe 2020-11-17 10:32:16 UTC
I bootstrapped several times (without using MACOSX_DEPLOYMENT_TARGET) and have been looking into other issues.

Note that the libgfortran directory throws up a lot of warnings when 'autoreconf'ed' so maybe there's some things to be looked at there anyway.
Comment 6 Jürgen Reuter 2020-11-17 10:36:55 UTC
(In reply to Iain Sandoe from comment #5)
> I bootstrapped several times (without using MACOSX_DEPLOYMENT_TARGET) and
> have been looking into other issues.
> 
> Note that the libgfortran directory throws up a lot of warnings when
> 'autoreconf'ed' so maybe there's some things to be looked at there anyway.

Ok, sorry, my reply was not so clear (even to me): I also never used MACOSX_DEPLOYMENT_TARGET myself. The main point in my fix is that libtool defaults to 10.0 for the TARGET, and then the second option matches, not the first one because now there is not darwin1x.x anymore, but darwin20. In any case, it looks like that Fortran code that either uses bind(C) to C++ libraries or legacy Fortran code based on common blocks produces ubiquitous SIGABRT when compiled with -Wl,-flat_namespace and without -Wl,-dynamic_lookup.
Comment 7 Iain Sandoe 2020-11-17 10:49:01 UTC
(In reply to Jürgen Reuter from comment #6)
> (In reply to Iain Sandoe from comment #5)
> > I bootstrapped several times (without using MACOSX_DEPLOYMENT_TARGET) and
> > have been looking into other issues.
> > 
> > Note that the libgfortran directory throws up a lot of warnings when
> > 'autoreconf'ed' so maybe there's some things to be looked at there anyway.
> 
> Ok, sorry, my reply was not so clear (even to me): I also never used
> MACOSX_DEPLOYMENT_TARGET myself. The main point in my fix is that libtool
> defaults to 10.0 for the TARGET, and then the second option matches, not the
> first one because now there is not darwin1x.x anymore, but darwin20. In any
> case, it looks like that Fortran code that either uses bind(C) to C++
> libraries or legacy Fortran code based on common blocks produces ubiquitous
> SIGABRT when compiled with -Wl,-flat_namespace and without
> -Wl,-dynamic_lookup.

OK. I'll take a look at this (and the config.sub) and ask which things we patch and which we import - who is responsible for maintaining Darwin in lib tool?

(I worked with Ben Elliston to test the newer config.sub across a range of Darwin machines, so fairly sure that's OK [but testing still needed of course]).
Comment 8 Iain Sandoe 2020-11-17 13:05:59 UTC
(In reply to Jürgen Reuter from comment #4)
> (In reply to Iain Sandoe from comment #3)
> > I didn't have x86 Big Sur until the weekend - still working through things.

> > 1/
> > 
> > The change you have keeps the default as $wl-undefined ${wl}dynamic_lookup,
> > which is no longer ideal - Darwin [at least in GCC] should only use that as
> > a conscious decision (when we know it's required) otherwise it just
> > suppresses errors on missing symbols until runtime.
> 
> I was trying it out on a regular Intel chip, not yet the new architecture.
> It seems for libgfortran and gfirtran it is still needed.

It's OK to need it (there are legitimate design reasons to do so) - however where that need exists, the -Wl,-undefined,dynamic_lookup should be applied to the specific configuration (with eyes open as to why, of course).

Placing it in the libtool.m4 (and regenerating the configurations) applies it globally to everything in the GCC tree which isn't right.
Comment 9 Jürgen Reuter 2020-11-17 14:04:54 UTC
(In reply to Iain Sandoe from comment #8)
> (In reply to Jürgen Reuter from comment #4)

> 
> It's OK to need it (there are legitimate design reasons to do so) - however
> where that need exists, the -Wl,-undefined,dynamic_lookup should be applied
> to the specific configuration (with eyes open as to why, of course).
> 
> Placing it in the libtool.m4 (and regenerating the configurations) applies
> it globally to everything in the GCC tree which isn't right.

Yes, I understand. Our code finally links dynamically:

	/usr/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/local/lib/libgfortran.5.dylib (compatibility version 6.0.0, current version 6.0.0)
	/usr/local/lib/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)/usr/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.29.0)

So, I guess at least one of those libraries has to be built with the -dynamic_lookup in order to work properly. I would guess it is libgfortran, but
maybe not only.
Comment 10 Iain Sandoe 2020-11-17 21:23:43 UTC
Created attachment 49580 [details]
fix under test

The patch (no doubt needs some polishing and a ChangeLog of course) makes the changes to remove the global setting of undefined, dynamic_lookup for Darwin.  It adds this in specifically, where needed, in libcc1 and libitm.

NOTE: this contains no regenerated files, I'll add those as a separate attachment.

Because the regenerated files are across the whole of the source tree, etc. this needs wide testing - initial results are encouraging tho.
Comment 11 Iain Sandoe 2020-11-17 21:24:55 UTC
Created attachment 49581 [details]
regenerated files

the second patch is all the regenerated files .. much larger :)
Comment 12 joseph@codesourcery.com 2020-11-17 22:02:34 UTC
config.sub and config.guess are imported, unmodified, from upstream 
config.git.

libtool has lots of local changes, hopefully all of them submitted 
upstream but maybe not and maybe some not committed upstream (libtool has 
very few commits in recent years, but lots since the 2009 version used in 
GCC).  As well as checking all the local changes (relative to libtool 
commit 2c9c38d8a12eb0a2ce7fe9c3862523026c3d5622, apparently) and applying 
them to a new version as needed, updating libtool would also require 
reverting libtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c to deal 
with a mismatch of --with-sysroot interpretations.
Comment 13 Iain Sandoe 2020-11-17 22:09:17 UTC
(In reply to joseph@codesourcery.com from comment #12)
> config.sub and config.guess are imported, unmodified, from upstream 
> config.git.

thanks I will try to do that and test it over the next days (I've been using a newish version on arm64-darwin20 for a few months so don't anticipate problems - but who knows).

> libtool has lots of local changes, hopefully all of them submitted 
> upstream but maybe not and maybe some not committed upstream (libtool has 
> very few commits in recent years, but lots since the 2009 version used in 
> GCC).  As well as checking all the local changes (relative to libtool 
> commit 2c9c38d8a12eb0a2ce7fe9c3862523026c3d5622, apparently) and applying 
> them to a new version as needed, updating libtool would also require 
> reverting libtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c to deal 
> with a mismatch of --with-sysroot interpretations.

The patch I have here is a additional local change (and specific to Darwin), unfortunately, I don't have resources to address the scope of work you describe.
Comment 14 Jürgen Reuter 2020-11-18 08:39:25 UTC
If there is a git branch or so, I could also test it on my system with our code whether this works as expected.
Comment 15 Iain Sandoe 2020-11-18 19:31:01 UTC
(In reply to Jürgen Reuter from comment #14)
> If there is a git branch or so, I could also test it on my system with our
> code whether this works as expected.

Here you go - this is config.{sub, guess}, libtool and a small patch to enable libsanitizer for darwin20 (which I'll likely push soon).

https://github.com/iains/gcc-git/tree/master-wip-config-darwin20
Comment 16 Jürgen Reuter 2020-11-19 11:00:52 UTC
(In reply to Iain Sandoe from comment #15)
> (In reply to Jürgen Reuter from comment #14)
> > If there is a git branch or so, I could also test it on my system with our
> > code whether this works as expected.
> 
> Here you go - this is config.{sub, guess}, libtool and a small patch to
> enable libsanitizer for darwin20 (which I'll likely push soon).
> 
> https://github.com/iains/gcc-git/tree/master-wip-config-darwin20

I tested your branch. Several observations: 
(1) make worked, (I used gmp, mpfr and mpc without patches for them, there 
     libtool is also outdated, but I'm not sure whether it has any influence)
(2) make check did not work because of the first error below.
(3) make install did produce an error, strangely enough, as make worked without    
     problem.
(4) I checked that on my system there is an older version of libasan installed.
     I thought this comes with every gcc installation, but apparently it 
     doesn't. Or do I have to build with a special sanitizer flag? 
(5) Your branch does NOT solve the problems in our codes, I do see the same 
    failures in our test suite like with the gcc trunk/master. 

The test-suite for the gcc itself did not work because
of this:
sys/types.h /usr/local/packages/iains_gcc_git/fixincludes/tests/base/sys/types.h differ: char 243, line 12
*** sys/types.h	2020-11-19 08:29:08.000000000 +0100
--- /usr/local/packages/iains_gcc_git/fixincludes/tests/base/sys/types.h	2020-11-18 22:28:10.000000000 +0100
***************
*** 9,19 ****
  
  
- #if defined( AIX_PHYSADR_T_CHECK )
- typedef struct __physadr_s {
- #endif  /* AIX_PHYSADR_T_CHECK */
- 
- 
  #if defined( GNU_TYPES_CHECK )
  #if !defined(_GCC_PTRDIFF_T)
  #define _GCC_PTRDIFF_T
--- 9,14 ----

There were fixinclude test FAILURES
make[2]: *** [check] Error 1
make[1]: *** [check-fixincludes] Error 2
make: *** [do-check] Error 2


Also `make install` did not work properly due to the following error (which is strange, as make worked without problems). 



 -L/usr/local//lib -lmpc -lmpfr -lgmp   -L./../zlib -lz 
clang: error: argument unused during compilation: '-no-pie' [-Werror,-Wunused-command-line-argument]
make[2]: [cc1plus] Error 1 (ignored)
g++ -std=c++11 -no-pie   -g -O2 -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H  -o f951 \
		fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o fortran/class.o fortran/constructor.o fortran/cpp.o fortran/data.o fortran/decl.o fortran/dump-parse-tree.o fortran/error.o fortran/expr.o fortran/interface.o fortran/intrinsic.o fortran/io.o fortran/iresolve.o fortran/match.o fortran/matchexp.o fortran/misc.o fortran/module.o fortran/openmp.o fortran/options.o fortran/parse.o fortran/primary.o fortran/resolve.o fortran/scanner.o fortran/simplify.o fortran/st.o fortran/symbol.o fortran/target-memory.o darwin-f.o fortran/convert.o fortran/dependency.o fortran/f95-lang.o fortran/trans.o fortran/trans-array.o fortran/trans-common.o fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o fortran/trans-stmt.o fortran/trans-types.o fortran/frontend-passes.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -L./../zlib -lz libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv  ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  attribs.o \
		 -L/usr/local//lib -L/usr/local//lib -lmpc -lmpfr -lgmp   -L./../zlib -lz 
clang: error: argument unused during compilation: '-no-pie' [-Werror,-Wunused-command-line-argument]
make[2]: [f951] Error 1 (ignored)
g++ -std=c++11 -no-pie   -g -O2 -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H  -o lto1 \
		lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o lto/lto-common.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a  -L/usr/local//lib -L/usr/local//lib -lmpc -lmpfr -lgmp   -L./../zlib -lz  libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv  ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
clang: error: argument unused during compilation: '-no-pie' [-Werror,-Wunused-command-line-argument]
make[2]: [lto1] Error 1 (ignored)
g++ -std=c++11 -no-pie   -g -O2 -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H  -o lto-dump \
		lto/lto-lang.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o lto/lto-dump.o lto/lto-common.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a  -L/usr/local//lib -L/usr/local//lib -lmpc -lmpfr -lgmp   -L./../zlib -lz  libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv  ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
clang: error: argument unused during compilation: '-no-pie' [-Werror,-Wunused-command-line-argument]
make[2]: [lto-dump] Error 1 (ignored)
Comment 17 Jürgen Reuter 2020-11-19 11:37:39 UTC
Iain, as I wrote below your changes seem not sufficient, I will recheck when I build your branch with gmp/mpfr/mpc built with dynamic_lookup, but it seems that there are some things where you missed the dynamic_lookup.
Comment 18 Iain Sandoe 2020-11-19 12:53:18 UTC
(In reply to Jürgen Reuter from comment #17)
> Iain, as I wrote below your changes seem not sufficient, I will recheck when
> I build your branch with gmp/mpfr/mpc built with dynamic_lookup, but it
> seems that there are some things where you missed the dynamic_lookup.

OK - we need to figure out what's different in the setups (I don't get the same result)

-----

* I found that there was one incorrect case in libgfortran (where there is a direct reference to **environ from the dylib, which is not allowed) - this was being hidden by the 'global dynamic_lookup' -- the master-wip-config-darwin20 branch has a patch now for that too.

My test setup

clean install of macOS11.0.1
master-wip-config-darwin20
command line install of XC12.2RC
GMP/MPFR/PMC/ISL are built in-tree (the sources are symlinked into the root dir)

/src-local/gcc-master/configure --prefix=/opt/iains/x86_64-apple-darwin20/gcc-11-0-0 --target=x86_64-apple-darwin20 --host=x86_64-apple-darwin20 --build=x86_64-apple-darwin20 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk --enable-languages=all CC=x86_64-apple-darwin19-gcc CXX=x86_64-apple-darwin19-g++

^^^ My bootstrap compiler is x86_64-apple-darwin19 gcc-7.5 (with Ada because of enable-languages=all)

I have build logs, install logs and test logs, none of these are showing any error.


                === gfortran tests ===


Running target unix

                === gfortran Summary ===

# of expected passes            55631
# of expected failures          232
# of unsupported tests          82
/scratch/11-0-sur/gcc-master/gcc/gfortran  version 11.0.0 20201118 (experimental) [master-wip-config-darwin20 revision r11-5152-gb57eea8b1d7d] (GCC) 

====

The effort of testing a top-level configuration change across multiple platforms is quite significant - so I'd rather not hack a minimal change and then have to go back and fix it properly later - so let's get to the bottom of what's happening and find the correct solution.
Comment 19 Iain Sandoe 2020-11-19 12:57:45 UTC
(In reply to Jürgen Reuter from comment #16)
> (In reply to Iain Sandoe from comment #15)
> > (In reply to Jürgen Reuter from comment #14)


> clang: error: argument unused during compilation: '-no-pie'
> [-Werror,-Wunused-command-line-argument]
> make[2]: [lto-dump] Error 1 (ignored)

I saw this issue on i686-darwin9 when trying the branch, it seems that the configuration is using the built compiler for this test - but then using the build system c++ for the install ... it's not obvious that my changes could cause this - I am investigating (it's not a problem if the bootstrap / build system c++ support no-pie, which is the case for the gcc-7.5 bootstrap).
Comment 20 Iain Sandoe 2020-11-19 13:01:39 UTC
(In reply to Jürgen Reuter from comment #16)
> (In reply to Iain Sandoe from comment #15)
> > (In reply to Jürgen Reuter from comment #14)

   
> - #if defined( AIX_PHYSADR_T_CHECK )
> - typedef struct __physadr_s {
> - #endif  /* AIX_PHYSADR_T_CHECK */
> - 
> - 

this is a recently-applied patch from the modules series, perhaps I don't have that yet in my testing.
Comment 21 Iain Sandoe 2020-11-19 13:10:52 UTC
(In reply to Jürgen Reuter from comment #16)
> (In reply to Iain Sandoe from comment #15)
> > (In reply to Jürgen Reuter from comment #14)

> (4) I checked that on my system there is an older version of libasan
> installed.
>      I thought this comes with every gcc installation, but apparently it 
>      doesn't. Or do I have to build with a special sanitizer flag? 

The branch contains a patch to enable libsanitizer for darwin20 (libsanitizer *is* built with dynamic_lookup, because it uses undefined weak symbols).

So long as the initial configure says that libsanitizer is being built (or rather it doesn't say it's disabled) then it should be present.

** Perhaps the problem are coming primarily from the failed install because of the no-pie issue.  I am going to investigate this next.

With the last patch on the branch, it would be academic for libgfortran to be built with "undefined, dynamic_lookup" since there are *no* undefined symbols.

since DYLD_LIBRARY_PATH no longer works for Darwin, a failed install will no doubt produce a failed test.

Will post more when I figure out what's happening with the no-pie issue.  In the meantime - you could try a bootstrap with CC/CXX set to a darwin19 gcc 7 or newer (if it's possible).
Comment 22 Iain Sandoe 2020-11-19 16:12:25 UTC
(In reply to Iain Sandoe from comment #19)
> (In reply to Jürgen Reuter from comment #16)
> > (In reply to Iain Sandoe from comment #15)
> > > (In reply to Jürgen Reuter from comment #14)
> 
> 
> > clang: error: argument unused during compilation: '-no-pie'
> > [-Werror,-Wunused-command-line-argument]
> > make[2]: [lto-dump] Error 1 (ignored)
> 
> I saw this issue on i686-darwin9 when trying the branch, it seems that the
> configuration is using the built compiler for this test - but then using the
> build system c++ for the install ... it's not obvious that my changes could
> cause this - I am investigating (it's not a problem if the bootstrap / build
> system c++ support no-pie, which is the case for the gcc-7.5 bootstrap).

I see this error with r11-5147 and no patches applied (so it's pre-existing - somewhere between r11-5028 and r11-5147).

e.g. i686-darwin9:

make install gives .. 
g++: error: unrecognized command line option '-no-pie'
make[2]: *** [gnat1] Error 1
make[1]: *** [install-gcc] Error 2
make: *** [install] Error 2

x86_64-darwin20 (no configure changes) 

clang: error: argument unused during compilation: '-no-pie' [-Werror,-Wunused-command-line-argument]
make[2]: *** [cc1plus] Error 1
make[1]: *** [install-gcc] Error 2
make: *** [install] Error 2
Comment 23 Jürgen Reuter 2020-11-19 19:50:34 UTC
(In reply to Iain Sandoe from comment #18)
> (In reply to Jürgen Reuter from comment #17)
> -----
> 
> * I found that there was one incorrect case in libgfortran (where there is a
> direct reference to **environ from the dylib, which is not allowed) - this
> was being hidden by the 'global dynamic_lookup' -- the
> master-wip-config-darwin20 branch has a patch now for that too.
> 
> My test setup
> 
> clean install of macOS11.0.1
> master-wip-config-darwin20
> command line install of XC12.2RC
> GMP/MPFR/PMC/ISL are built in-tree (the sources are symlinked into the root
> dir)
> 
> /src-local/gcc-master/configure
> --prefix=/opt/iains/x86_64-apple-darwin20/gcc-11-0-0
> --target=x86_64-apple-darwin20 --host=x86_64-apple-darwin20
> --build=x86_64-apple-darwin20
> --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
> --enable-languages=all CC=x86_64-apple-darwin19-gcc
> CXX=x86_64-apple-darwin19-g++
> 

> ====
> 
> The effort of testing a top-level configuration change across multiple
> platforms is quite significant - so I'd rather not hack a minimal change and
> then have to go back and fix it properly later - so let's get to the bottom
> of what's happening and find the correct solution.

So with that patch it works. Probably it worked even before your last fix, as I think I cloned the first your repo just with the link above, but was on master, not on the master-wip-config-darwin20, my fault. I compiled/bootstrapped now with Apple clang version 12.0.0 (clang-1200.0.32.27), and just did make -i install, skipping over the error, which I think is not relevant for me. I used my patches for the gmp, mpfr, mpc, though I think it's not relevant for them. In any case I notified their developers about the issue. Hope we get a stable and convincing solution into 11.0.1. Will you then backport this for upcoming 10.3 and 9.4 as well? (for 8 it's probably too late).
Comment 24 Iain Sandoe 2020-11-19 23:46:06 UTC
(In reply to Iain Sandoe from comment #22)
> (In reply to Iain Sandoe from comment #19)
> > (In reply to Jürgen Reuter from comment #16)
> > > (In reply to Iain Sandoe from comment #15)
> > > > (In reply to Jürgen Reuter from comment #14)
> > 
> > 
> > > clang: error: argument unused during compilation: '-no-pie'
> > > [-Werror,-Wunused-command-line-argument]
> > > make[2]: [lto-dump] Error 1 (ignored)
> > 
> > I saw this issue on i686-darwin9 when trying the branch, it seems that the
> > configuration is using the built compiler for this test - but then using the
> > build system c++ for the install ... it's not obvious that my changes could
> > cause this - I am investigating (it's not a problem if the bootstrap / build
> > system c++ support no-pie, which is the case for the gcc-7.5 bootstrap).
> 
> I see this error with r11-5147 and no patches applied (so it's pre-existing
> - somewhere between r11-5028 and r11-5147).
> 
> e.g. i686-darwin9:
> 
> make install gives .. 
> g++: error: unrecognized command line option '-no-pie'
> make[2]: *** [gnat1] Error 1
> make[1]: *** [install-gcc] Error 2
> make: *** [install] Error 2
> 
> x86_64-darwin20 (no configure changes) 
> 
> clang: error: argument unused during compilation: '-no-pie'
> [-Werror,-Wunused-command-line-argument]
> make[2]: *** [cc1plus] Error 1
> make[1]: *** [install-gcc] Error 2
> make: *** [install] Error 2

looks like this was caused by
 https://gcc.gnu.org/pipermail/gcc-cvs/2020-November/337375.html

and is fixed by
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559605.html

(but more testing needed)
Comment 25 Iain Sandoe 2020-11-25 20:49:30 UTC
posted patch 
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559963.html

(Hopefully, we'll be able to back port to the open branches too)
Comment 26 Jürgen Reuter 2020-12-03 09:49:39 UTC
Any news? I did not test the patch you posted in your last comment, but only the one from your git repo. Under the assumption that this is identical to the patch here, it works. So apparently libfortran and the fortran frontend are not affected? When do you expect to merge this?
Comment 27 Iain Sandoe 2020-12-03 09:53:52 UTC
tomorrow if there are no further comments (the patch needs minor typographical changes).

I'm also testing back-ports for the open branches, and will publish  Darwin-specific branches at least for gcc-7.5 (and eventually gcc-6.5 and 5.5 since people are still build the 5 branch for Java) - it all takes time ;)
Comment 28 CVS Commits 2020-12-05 13:25:36 UTC
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:1352bc88a0525743c952197fb2db6e4f8c091cde

commit r11-5758-g1352bc88a0525743c952197fb2db6e4f8c091cde
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Wed Nov 18 10:06:03 2020 +0000

    Darwin : Update libtool and dependencies for Darwin20 [PR97865]
    
    The change in major version (and the increment from Darwin19 to 20)
    caused libtool tests to fail which resulted in incorrect build settings
    for shared libraries.
    
    We take this opportunity to sort out the shared undefined symbols state
    rather than propagating the current unsound behaviour into a new rev.
    
    This change means that we default to the case that missing symbols are
    considered an error, and if one wants to allow this intentionally, the
    confiuration for that case should be set appropriately.
    
    Three existing cases need undefined dynamic lookup:
     libitm, where there is already a configuration mechanism to add the
             flags.
     libcc1, where we add simple configuration to add the flags for Darwin.
     libsanitizer, where we can add to the existing extra flags.
    
    libcc1/ChangeLog:
    
            PR target/97865
            * Makefile.am: Add dynamic_lookup to LD flags for Darwin.
            * configure.ac: Test for Darwin host and set a flag.
            * Makefile.in: Regenerate.
            * configure: Regenerate.
    
    libitm/ChangeLog:
    
            PR target/97865
            * configure.tgt: Add dynamic_lookup to XLDFLAGS for Darwin.
            * configure: Regenerate.
    
    libsanitizer/ChangeLog:
    
            PR target/97865
            * configure.tgt: Add dynamic_lookup to EXTRA_CXXFLAGS for
            Darwin.
            * configure: Regenerate.
    
    ChangeLog:
    
            PR target/97865
            * libtool.m4: Update handling of Darwin platform link flags
            for Darwin20.
    
    gcc/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libatomic/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libbacktrace/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libffi/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libgfortran/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libgomp/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libhsail-rt/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libobjc/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libphobos/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libquadmath/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libssp/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libstdc++-v3/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libvtv/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    zlib/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
Comment 29 Jürgen Reuter 2020-12-06 18:41:01 UTC
(In reply to CVS Commits from comment #28)
> The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:
> 
> https://gcc.gnu.org/g:1352bc88a0525743c952197fb2db6e4f8c091cde
> 
> commit r11-5758-g1352bc88a0525743c952197fb2db6e4f8c091cde
> Author: Iain Sandoe <iain@sandoe.co.uk>
> Date:   Wed Nov 18 10:06:03 2020 +0000
> 

Thanks for the commit. I can confirm that with these changes (and analogous ones in our libtool/configure setup) our code built upon shared libraries works again.
Comment 30 CVS Commits 2021-01-03 09:28:45 UTC
The releases/gcc-10 branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:c85bc938ccf75ea45c00e430f715544ff396e5b5

commit r10-9196-gc85bc938ccf75ea45c00e430f715544ff396e5b5
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Wed Nov 18 10:06:03 2020 +0000

    Darwin : Update libtool and dependencies for Darwin20 [PR97865]
    
    The change in major version (and the increment from Darwin19 to 20)
    caused libtool tests to fail which resulted in incorrect build settings
    for shared libraries.
    
    We take this opportunity to sort out the shared undefined symbols state
    rather than propagating the current unsound behaviour into a new rev.
    
    This change means that we default to the case that missing symbols are
    considered an error, and if one wants to allow this intentionally, the
    confiuration for that case should be set appropriately.
    
    Three existing cases need undefined dynamic lookup:
     libitm, where there is already a configuration mechanism to add the
             flags.
     libcc1, where we add simple configuration to add the flags for Darwin.
     libsanitizer, where we can add to the existing extra flags.
    
            Backported from 1352bc88a0525743c952197fb2db6e4f8c091cde and 5dc998933e7aa737f4a45a8a2885d42d5288d51a
    
    libcc1/ChangeLog:
    
            PR target/97865
            * Makefile.am: Add dynamic_lookup to LD flags for Darwin.
            * configure.ac: Test for Darwin host and set a flag.
            * Makefile.in: Regenerate.
            * configure: Regenerate.
    
    libitm/ChangeLog:
    
            PR target/97865
            * configure.tgt: Add dynamic_lookup to XLDFLAGS for Darwin.
            * configure: Regenerate.
    
    libsanitizer/ChangeLog:
    
            PR target/97865
            * configure.tgt: Add dynamic_lookup to EXTRA_CXXFLAGS for
            Darwin.
            * configure: Regenerate.
    
    ChangeLog:
    
            PR target/97865
            * libtool.m4: Update handling of Darwin platform link flags
            for Darwin20.
    
    gcc/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libatomic/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libbacktrace/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libffi/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libgfortran/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libgomp/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
            * Makefile.in: Update copyright years.
    
    libhsail-rt/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libobjc/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libphobos/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libquadmath/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libssp/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libstdc++-v3/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libvtv/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    zlib/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    Co-Authored-By: Jakub Jelinek  <jakub@redhat.com>
Comment 31 CVS Commits 2021-05-01 13:08:31 UTC
The releases/gcc-9 branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:3d29d0d630caac54dbcc6c3fb961258a011a30fc

commit r9-9497-g3d29d0d630caac54dbcc6c3fb961258a011a30fc
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Wed Nov 18 10:06:03 2020 +0000

    Darwin : Update libtool and dependencies for Darwin20 [PR97865]
    
    The change in major version (and the increment from Darwin19 to 20)
    caused libtool tests to fail which resulted in incorrect build settings
    for shared libraries.
    
    We take this opportunity to sort out the shared undefined symbols state
    rather than propagating the current unsound behaviour into a new rev.
    
    This change means that we default to the case that missing symbols are
    considered an error, and if one wants to allow this intentionally, the
    confiuration for that case should be set appropriately.
    
    Three existing cases need undefined dynamic lookup:
     libitm, where there is already a configuration mechanism to add the
             flags.
     libcc1, where we add simple configuration to add the flags for Darwin.
     libsanitizer, where we can add to the existing extra flags.
    
            Backported from 1352bc88a0525743c952197fb2db6e4f8c091cde and 5dc998933e7aa737f4a45a8a2885d42d5288d51a
    
    libcc1/ChangeLog:
    
            PR target/97865
            * Makefile.am: Add dynamic_lookup to LD flags for Darwin.
            * configure.ac: Test for Darwin host and set a flag.
            * Makefile.in: Regenerate.
            * configure: Regenerate.
    
    libitm/ChangeLog:
    
            PR target/97865
            * configure.tgt: Add dynamic_lookup to XLDFLAGS for Darwin.
            * configure: Regenerate.
    
    libsanitizer/ChangeLog:
    
            PR target/97865
            * configure.tgt: Add dynamic_lookup to EXTRA_CXXFLAGS for
            Darwin.
            * configure: Regenerate.
    
    ChangeLog:
    
            PR target/97865
            * libtool.m4: Update handling of Darwin platform link flags
            for Darwin20.
    
    gcc/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libatomic/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libbacktrace/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libffi/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libgfortran/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libgomp/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libhsail-rt/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libobjc/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libphobos/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libquadmath/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libssp/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libstdc++-v3/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    libvtv/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    zlib/ChangeLog:
    
            PR target/97865
            * configure: Regenerate.
    
    Co-Authored-By: Jakub Jelinek  <jakub@redhat.com>
Comment 32 Iain Sandoe 2021-10-01 23:11:25 UTC
Fixed on open branches, could be back ported to vendor branches.