Re: [sr #110846] cross-compilation is not entered when build_alias and host_alias are the same

On 2023-12-07 21:28, Zack Weinberg wrote: Follow-up Comment #1, sr#110846 (group autoconf): We regret the delay in responding to this bug report. I believe this is the same as #110348. The proposal there would make it so you could force a configure script into cross-compilation mode, even when

[sr #110612] Re-exec of $as_myself chooses wrong configure script from PATH

Follow-up Comment #3, sr#110612 (group autoconf): [comment #1 comment #1:] > If you or anyone else has ideas for how to tell "configure" from "sh configure", I am all ears. If it's Bash, "$_" (at the start of the script) should tell you. This is true for other shells (e.g., it works with Solari

[sr #110612] Re-exec of $as_myself chooses wrong configure script from PATH

Follow-up Comment #2, sr#110612 (group autoconf): No problem. If I create, $ cat configure #!/bin/sh echo $0 in my home directory, then at least in bash and dash, the $PATH entry gets prepended to $0 when it is needed to resolve "configure": $ PATH=/home/mjo configure /home/mjo/configure $ PA

[sr #110846] cross-compilation is not entered when build_alias and host_alias are the same

Follow-up Comment #1, sr#110846 (group autoconf): We regret the delay in responding to this bug report. I believe this is the same as #110348. The proposal there would make it so you could force a configure script into cross-compilation mode, even when the build and host triples are the same and

[sr #110348] Simplify rules for when configure enters cross-compiling mode

Follow-up Comment #1, sr#110348 (group autoconf): 2.71 wound up being a hotfix release for 2.70, and 2.72 is too close to release to put in a change this risky. [bullwinkle] 2.73 for sure! ___ Reply to this item at:

[sr #110746] GNU Autoconf 2.71: F77 name-mangling fails when compiling with mpicxx

Follow-up Comment #1, sr#110746 (group autoconf): We regret the delay in responding to this bug report. The problem you describe _may_ have been fixed since 2.71. Would you be able to test autoconf 2.72d and report whe

[sr #110660] AC_LANG_INT_SAVE (used by AC_CHECK_SIZEOF) includes stdlib.h without checking whether it actually exists

Follow-up Comment #4, sr#110660 (group autoconf): >From this minimal configure.ac AC_INIT([test], [1.0]) AC_PROG_CC AC_CHECK_SIZEOF([size_t]) AC_CONFIG_HEADERS([config.h]) AC_OUTPUT autoconf 2.71 generates a configure script which successfully detects the size of size_t when given a compiler t

[sr #110612] Re-exec of $as_myself chooses wrong configure script from PATH

Follow-up Comment #1, sr#110612 (group autoconf): We regret the delay in responding to this bug report. In principle, this is something we should try to fix, but I do not see a good way to do it. The problem is that there's no way (that I know of) to tell, when $0 is just "configure", whether th

[sr #110573] AR_CONFIG_AUX_DIR(S) does not recognize shell vars nor absolute paths

Follow-up Comment #2, sr#110573 (group autoconf): We regret the delay in responding to this report. Your suggested changes do not make sense to me. There should be no behavioral difference between m4_bmatch([$1], [^/.*], [...]) and m4_bmatch([$1], [^/], [...]) because m4_bmatch does not

[sr #110549] File expected to be at /usr/bin/file, isn't on ChromeOS

Follow-up Comment #2, sr#110549 (group autoconf): Closing; this needs to be addressed in Libtool. ___ Reply to this item at: ___ Message sent via Sa

[sr #110537] AC_SEARCH_LIBS does not honor --with-sysroot=

Follow-up Comment #4, sr#110537 (group autoconf): Autoconf doesn't have generic support for --with-sysroot. Like all --with and --enable options, if you pass it to a configure script that doesn't define what it does using AC_ARG_WITH, it's just ignored. In order to add a generic --with-sysroot o

[sr #110971] busybox mkdir is misdetected

Follow-up Comment #0, sr#110971 (group autoconf): [comment #4 comment #4:] > It seems to me it will be more robust to filter out the troublesome error message Not really, as BusyBox plausibly might change that diagnostic's wording and then the filtering will stop working. Conversely, if the outpu

[sr #110971] busybox mkdir is misdetected

Follow-up Comment #0, sr#110971 (group autoconf): It seems to me it will be more robust to filter out the troublesome error message and leave the match patterns alone, but I could be persuaded otherwise. ___ Reply to this item at: