LDFLAGS support broken

[Greg Troxel]

In trying to get back to a working build, I moved from the last known
version to the tip of master, plus the patch I sent earlier.

This fails because dev/python-proposed cannot find libpython.so, because
it was not compiled with -R/usr/pkg/lib. That was in LDFLAGS in the
environment. It seems that is supposed to be extracted and stored into
config, but it isn't, and I haven't figured out how that's supposed to
work yet.

(There's a separate bug with python3.9-config --ldflags on my system in
that it is missing the -R argument, but regardless the
environment-supplied LDFLAGS is not being respected.)

This commit (plus the patch I sent of course) worked:

commit 0be19f58f5c0709ced52669ebccd069c8f79e533
Author: Rob Browning <r...@defaultvalue.org>
Date: Sat May 21 17:18:03 2022 -0500

[Greg Troxel]

[LDFLAGS ignored]

I went back over logs and found that configure emitted:

ignoring bogus LDFLAGS="-L/usr/pkg/lib -Wl,-R/usr/pkg/lib"

This is apparently because of

validating LDFLAGS=-L/usr/pkg/lib -Wl,-R/usr/pkg/lib
cc: error: configure-W19J3L/ngc10855.o: No such file or directory

I don't quite follow how ngc$$ is created, but it seems to be the result
of the compilation in the previous stanza that checks CFLAGS. However
I've haven't supplied any.

I then put CFLAGS in the environment, but it wasn't even tried, even
though printenv before invoking configure shows it. I modified
config.inc to add debugging but that had no effect, so maybe configure
is built and checked in anyway?


I think that doing the build with empty CFLAGS -- and thus validating
the no CFLAGS is an ok situation as well as producing the .o, may be
best.




[
Also, not related to my problem, but there seems to be CFLAGS and
CXXFLAGS output, but CXXFLAGS is not processed. And CPPFLAGS is sort of
processed but differently. Normally there is a separate of CPPFLAGS for
preprocessor and CFLAGS for actual C building. I don't know why there
is CXXFLAGS as bup is not as far as I know documented to need CXX
(although code that isn't invoked isn't per se a bug.)
]

[Rob Browning]

The value should now be captured in config/config.cmd alongside the
others.

Thanks to Greg Troxel for reporting the omission.

Signed-off-by: Rob Browning <r...@defaultvalue.org>
Tested-by: Rob Browning <r...@defaultvalue.org>
---

Proposed.

config/configure.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/config/configure.inc b/config/configure.inc
index 9d105ac7..0834263b 100644
--- a/config/configure.inc
+++ b/config/configure.inc
@@ -968,6 +968,7 @@ AC_OUTPUT () {
AC_SUB 'GENERATED_FILES' "$*"
AC_SUB 'CFLAGS' "$AC_CFLAGS"
AC_SUB 'FCFLAGS' "$AC_FCFLAGS"
+ AC_SUB 'CPPFLAGS' "$AC_CPPFLAGS"
AC_SUB 'CXXFLAGS' "$AC_CXXFLAGS"
AC_SUB 'LDFLAGS' "$AC_LDFLAGS"
AC_SUB 'srcdir' "$AC_SRCDIR"
@@ -990,7 +991,7 @@ AC_OUTPUT () {
Q=\'
cat - > config.cmd << EOF
#! /bin/sh
-${CXX:+CXX=${Q}${CXX}${Q}} ${CXXFLAGS:+CXXFLAGS=${Q}${CXXFLAGS}${Q}} ${FC:+FC=${Q}${FC}${Q}} ${FCFLAGS:+FCFLAGS=${Q}${FCFLAGS}${Q}} ${CC:+CC=${Q}${CC}${Q}} ${CFLAGS:+CFLAGS=${Q}${CFLAGS}${Q}} $ac_progname $ac_configure_command
+${CXX:+CXX=${Q}${CXX}${Q}} ${CPPFLAGS:+CPPFLAGS=${Q}${CPPFLAGS}${Q}} ${CXXFLAGS:+CXXFLAGS=${Q}${CXXFLAGS}${Q}} ${FC:+FC=${Q}${FC}${Q}} ${FCFLAGS:+FCFLAGS=${Q}${FCFLAGS}${Q}} ${CC:+CC=${Q}${CC}${Q}} ${CFLAGS:+CFLAGS=${Q}${CFLAGS}${Q}} $ac_progname $ac_configure_command
EOF
chmod +x config.cmd

--
2.30.2

[Rob Browning]

Signed-off-by: Rob Browning <r...@defaultvalue.org>
---

Proposed.

config/configure.inc | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/config/configure.inc b/config/configure.inc
index 0834263b..ed3b5c4b 100644
--- a/config/configure.inc
+++ b/config/configure.inc
@@ -492,7 +492,7 @@ EOF

if [ "$CFLAGS" ]; then
test "$CFLAGS" && echo "validating CFLAGS=${CFLAGS}"
- if $AC_CC $CFLAGS -o "$__ac_tmpdir/ngc$$.o" "$__ac_tmpdir/ngc$$.c" ; then
+ if $AC_CC $CFLAGS -o "$__ac_tmpdir/ngc$$" "$__ac_tmpdir/ngc$$.c" ; then
AC_CFLAGS=${CFLAGS:-"-g"}
test "$CFLAGS" && echo "CFLAGS=\"${CFLAGS}\" are okay"
elif [ "$CFLAGS" ]; then
@@ -502,8 +502,9 @@ EOF
AC_CFLAGS=-g
fi
if [ "$LDFLAGS" ]; then
- test "$LDFLAGS" && echo "validating LDFLAGS=${LDFLAGS}"
- if $AC_CC $LDFLAGS -o "$__ac_tmpdir/ngc$$" "$__ac_tmpdir/ngc$$.o"; then
+ echo "validating LDFLAGS=${LDFLAGS}"
+ $AC_CC $AC_CFLAGS -c -o "$__ac_tmpdir/ngc$$.o" "$__ac_tmpdir/ngc$$.c"
+ if $AC_CC $AC_CFLAGS $LDFLAGS -o "$__ac_tmpdir/ngc$$" "$__ac_tmpdir/ngc$$.o"; then
AC_LDFLAGS=${LDFLAGS:-"-g"}
test "$LDFLAGS" && TLOG "LDFLAGS=\"${LDFLAGS}\" are okay"
elif [ "$LDFLAGS" ]; then
--
2.30.2

[Rob Browning]

Greg Troxel <g...@lexort.com> writes:

> Also, not related to my problem, but there seems to be CFLAGS and
> CXXFLAGS output, but CXXFLAGS is not processed. And CPPFLAGS is sort of
> processed but differently. Normally there is a separate of CPPFLAGS for
> preprocessor and CFLAGS for actual C building. I don't know why there
> is CXXFLAGS as bup is not as far as I know documented to need CXX
> (although code that isn't invoked isn't per se a bug.)

I don't think we intend to use CXXFLAGS (now, or anytime soon/ever), but
it'd be reasonable for ./configure to handle it alongside CPPFLAGS, etc.

--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

[Greg Troxel]

Rob Browning <r...@defaultvalue.org> writes:

> I don't think we intend to use CXXFLAGS (now, or anytime soon/ever), but
> it'd be reasonable for ./configure to handle it alongside CPPFLAGS, etc.

I'd say if we don't build C++ there should be no CXXFLAGS in any bup
support code, because it confuses the issue and makes it harder for
readers to understand.

[Rob Browning]

Rob Browning <r...@defaultvalue.org> writes:

> The value should now be captured in config/config.cmd alongside the
> others.
>
> Thanks to Greg Troxel for reporting the omission.
>
> Signed-off-by: Rob Browning <r...@defaultvalue.org>
> Tested-by: Rob Browning <r...@defaultvalue.org>

Pushed.

[Rob Browning]