https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Jürgen Reuter from comment #16) > Yes, after the problem occurred, I did a completely clean new build of gmp, > mpfr, mpc, gcc (configured with ../configure --prefix=/usr/local/ > --with-gmp=/usr/local/ --with-mpfr=/usr/local/ --with-mpc=/usr/local/ > --enable-checking=release --enable-languages=c,c++,fortran,lto), > all the tools our software depends, and our software. OK, FWIW (thinking a bit more last night) if you examine the logs from building GCC, you will see the same linker complaint in the log for building libstdc++.dylib. Which kinda reinforces the expectation that this is not the source of the problem. However, I'm thinking to try and construct some small experiment to check that the newer ld64 doesn't do something active as well as complain. > It turns out that > external C++ libraries linked into our (Fortran) project via bind(C) I might be wrong, but suspect there was some change to the C binding around that time too - but I also recall seeing a recent patch go by to fix a problem in that area (but not sure if it's been applied yet). Will let Dominique comment on that. > are not > a problem if they have been built via libtool, such that a .dylib, a .a and > a .la file are present. The two projects that have problem either exist as > .dylib and .a produced by hand-written configure and makefiles (i.e. not > using autotools), or only as dynamic libraries produced via cmake and make. That's an interesting observation, what we need is to find the specific difference in the output exe. * Narrowing this down by knowing where and what causes the problem will become important at some point - so a debug build and lldb session could be a useful next step. * as a general rule, it's also useful to see if an -O0 build exhibits the problem - in case its an optimisation issue.
