Which makes it impossible to build a static ASAN app. This hack lets static-libasan through: diff -u /usr/share/libtool/build-aux/ltmain.sh~ /usr/share/libtool/build-aux/ltmain.sh --- /usr/share/libtool/build-aux/ltmain.sh~ 2021-02-08 17:32:08.000000000 +0100 +++ /usr/share/libtool/build-aux/ltmain.sh 2021-09-07 17:58:08.414406931 +0200 @@ -7337,7 +7337,7 @@ -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \ -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \ -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \ - -specs=*|-fsanitize=*|-fuse-ld=*) + -specs=*|-fsanitize=*|-fuse-ld=*|-static-libasan) func_quote_for_eval "$arg" arg=$func_quote_for_eval_result func_append compile_command " $arg"
Debian seems to have this covered in 0055-pass-flags-unchanged.patch: Description: Pass more flags to the linker unchanged. Closes: #751161. Author: Vincent Lefevre <vincent@vinc17.net> Last-Updated: 2019-05-03 --- libtool-2.4.6-a/build-aux/ltmain.in 2019-05-03 11:11:05.000000000 +0200 +++ libtool-2.4.6-b/build-aux/ltmain.in 2019-05-03 11:18:59.209409497 +0200 @@ -5383,10 +5383,12 @@ # -stdlib=* select c++ std lib with clang # -fsanitize=* Clang/GCC memory and address sanitizer # -fuse-ld=* Linker select flags for GCC + # -static-* direct GCC to link specific libraries statically + # -fcilkplus Cilk Plus language extension features for C/C++ -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \ -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \ -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \ - -specs=*|-fsanitize=*|-fuse-ld=*) + -specs=*|-fsanitize=*|-fuse-ld=*|-static-*|-fcilkplus) func_quote_for_eval "$arg" arg=$func_quote_for_eval_result func_append compile_command " $arg"
have you sent this upstream yet ?
(In reply to SpanKY from comment #2) > have you sent this upstream yet ? No I haven't. Don't know if Debian has. Upstream appears dead though.
(In reply to Joakim Tjernlund from comment #3) > (In reply to SpanKY from comment #2) > > have you sent this upstream yet ? > > No I haven't. Don't know if Debian has. > Upstream appears dead though. Looked in the libtool mail archive and found Debians patch here: https://lists.gnu.org/archive/html/libtool-patches/2019-05/msg00000.html
(In reply to Joakim Tjernlund from comment #3) > Upstream appears dead though. that's not a reason to not send patches upstream. projects randomly wake up all the time and do sweeps before going dormant, and if we miss that window, it won't be until the next cycle. this has happened to us more than once. (In reply to Joakim Tjernlund from comment #4) > Looked in the libtool mail archive and found Debians patch here: > https://lists.gnu.org/archive/html/libtool-patches/2019-05/msg00000.html sounds good. please clean up & attach the patch like normal. posting them as bugzilla comments mangles them.
Created attachment 743424 [details, diff] 0055-pass-flags-unchanged.patch Debians libtool patch for static-libasan
Created attachment 743532 [details] v2: adapt to Gentoo ebuild practise Gentoo does not rebuild ltmain.sh so it must be patched too.
we do these things in libtool itself, and in elt-patches
(In reply to SpanKY from comment #8) > we do these things in libtool itself, and in elt-patches Not sure what you mean but without ltmain.sh you get: config.status: executing depfiles commands config.status: executing libtool commands >>> Source configured. >>> Compiling source in /var/tmp/portage/sys-devel/libtool-2.4.6-r6/work/libtool-2.4.6 ... make -j8 -l6 -s ./build-aux/inline-source './build-aux/ltmain.in' | sed -e s|@MACRO_VERSION\@|2.4.6|g -e s|@MACRO_REVISION\@|2.4.6|g -e s|@MACRO_SERIAL\@||g -e s|@PACKAGE\@|libtool|g -e s|@PACKAGE_BUGREPORT\@|bug-libtool@gnu.org|g -e s|@PACKAGE_URL\@|https://www.gnu.org/software/libtool/|g -e s|@PACKAGE_NAME\@|GNU Libtool|g -e s|@package_revision\@|2.4.6|g -e s|@PACKAGE_STRING\@|GNU Libtool 2.4.6|g -e s|@PACKAGE_TARNAME\@|libtool|g -e s|@PACKAGE_VERSION\@|2.4.6|g -e s|@VERSION\@|2.4.6|g > 'build-aux/ltmain.sh' /bin/bash ./config.status "libtool" config.status: executing libtool commands Making all in . make[2]: *** [Makefile:2416: doc/libtool.1] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [Makefile:1640: all-recursive] Error 1 make: *** [Makefile:1017: all] Error 2 and the other patches like libtool-2.4.6-link-fsanitize.patch also patches ltmain.sh Anyhow, I hope you can take it from here ?
(In reply to SpanKY from comment #8) > we do these things in libtool itself, and in elt-patches Did look into elt-patches and it does not look like elt-patches is updated anymore. Look at the sister patch libtool-2.4.6-link-fsanitize.patch, there is no corresponding patch in elt-patches.
(In reply to Joakim Tjernlund from comment #10) > (In reply to SpanKY from comment #8) > > we do these things in libtool itself, and in elt-patches > > Did look into elt-patches and it does not look like elt-patches is > updated anymore. > > Look at the sister patch libtool-2.4.6-link-fsanitize.patch, there is > no corresponding patch in elt-patches. Last updated in September? https://gitweb.gentoo.org/proj/elt-patches.git/
(In reply to Sam James from comment #11) > (In reply to Joakim Tjernlund from comment #10) > > (In reply to SpanKY from comment #8) > > > we do these things in libtool itself, and in elt-patches > > > > Did look into elt-patches and it does not look like elt-patches is > > updated anymore. > > > > Look at the sister patch libtool-2.4.6-link-fsanitize.patch, there is > > no corresponding patch in elt-patches. > > Last updated in September? https://gitweb.gentoo.org/proj/elt-patches.git/ wow, just 2 years after it got into libtool :) Anyhow, attaching a dry port of the same for static-asan. Not sure I got it right though.
Created attachment 748122 [details, diff] static-asan for elt-patches
(In reply to Joakim Tjernlund from comment #12) > wow, just 2 years after it got into libtool :) it's updated based on demand. if there hasn't been demand, it doesn't get updated. only reason this latest update went in is because we needed -fuse-ld handling recently.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/elt-patches.git/commit/?id=2b7112d147d2fe5d418ecdf2f8d150935761de79 commit 2b7112d147d2fe5d418ecdf2f8d150935761de79 Author: Joakim Tjernlund <Joakim.Tjernlund@infinera.com> AuthorDate: 2021-11-02 22:42:18 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2021-11-04 10:33:34 +0000 backport -static-* & -fcilkplus for 2.4.6 Bug: https://bugs.gentoo.org/812026 Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@infinera.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org> eltpatch.in | 2 +- patches/static-flags/2.4.6 | 38 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 39 insertions(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0be5d62afd58586c06a2d391a50a56021c30b2d6 commit 0be5d62afd58586c06a2d391a50a56021c30b2d6 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-04 23:10:09 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-04 23:18:29 +0000 app-portage/elt-patches: add 20211104 - Adds macOS Monterey / macOS 12 patch - backport -static-* & -fcilkplus for 2.4.6 Bug: https://bugs.gentoo.org/812026 Signed-off-by: Sam James <sam@gentoo.org> app-portage/elt-patches/Manifest | 1 + .../elt-patches/elt-patches-20211104.ebuild | 25 ++++++++++++++++++++++ 2 files changed, 26 insertions(+)
Needed to cut a release for Darwin so here we are.
libtool itself seems forgotten?
(In reply to Joakim Tjernlund from comment #18) bug is still open ...
(In reply to SpanKY from comment #19) > (In reply to Joakim Tjernlund from comment #18) > > bug is still open ... Seem like this bug will just stay open?
(In reply to Joakim Tjernlund from comment #20) > Seem like this bug will just stay open? comments like this aren't productive at all. I've said plenty of times before (and I'll say it again now), if you want to fix these things yourself, you're free to join us and be able to commit stuff. We want the help! But keep the snark out please :(
Open for 2 years, closing
(In reply to Joakim Tjernlund from comment #22) > Open for 2 years, closing Please don't do that.
