Re: [lmi] Difficulty building with "dll" attributes and new wx

[Vadim Zeitlin]

On Tue, 21 Jul 2020 15:05:10 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2020-07-21 13:22, Vadim Zeitlin wrote:
GC> [...]
GC> >  After wasting literally 2 hours on trying to understand what was going on
GC> > here, I've finally realized that it was just a matter of forgetting a
GC> > single character in an innocuous change half a year ago. I've finally 
fixed
GC> > this in
GC> > 
GC> > 
https://github.com/wxWidgets/wxWidgets/commit/b762d2fb0f5cb5333e77df1ab3be52f6ce752cce
GC> Thanks--I would never have been able to find that in only two hours.

 I might have actually taken more than this to fix it, I just was doing
other things in parallel while rebuilding things. It's not really an
excuse, but I was completely led astray by the misleading messages like

/usr/bin/i686-w64-mingw32-ld: DWARF error: could not find variable 
specification at offset 579bd

that I was seeing (before all the thousands of link errors), so for a long
time I was convinced it was a gcc 10.1 problem and tried to reproduce it in
a simple test case. Then I finally tried building with gcc 9.3 and, after
getting the same errors there, realized that it was probably not a compiler
bug... Better late than never, I guess.

GC> My first thought was "wouldn't shellcheck have flagged that?", but
GC> apparently not:
GC> 
GC> $cat xyzzy.sh 
GC> #!/bin/sh
GC> if test "SHARED" = 1; then echo "This is not flagged"; fi
GC> if [ "SHARED" = 1 ]; then echo "This, however, is flagged"; fi

 This looks like a bug in shellcheck, I don't see any possible reason for
"test" and "[" to behave differently.

 FWIW, it's much more common to use "test" in configure because "[" and "]"
are the default quotes for m4, and configure is actually written in m4 and
not shell, i.e. it's a shell script which is first preprocessed by m4. So
using "[" would require doubling it, which would be confusing because "[["
exists in the shell too with a subtly different meaning, or changing the
default quotes, which would be even more confusing. So changing configure
to use "if [ ... ]" is not really feasible.

GC> But that's probably academic. My second and perhaps less academic
GC> thought was "might shellcheck usefully flag something else in these
GC> scripts?", and...well, it emits a lot of output, almost all of which
GC> looks benign, but I wonder whether this one is unintended:

 I honestly have no idea, but you need to remember that configure is
generated by autoconf and is really, really not supposed to be read by
human beings (I'm convinced Lovecraft was a visionary and had actually
foreseen autoconf output ahead of his time), please don't lose your sanity
by looking at it. And editing it is useless anyhow, as it's regenerated
with every change to configure.in.

 It might make more sense to try running shellcheck on configure.in itself,
but I wouldn't be surprised if it got confused by all m4-ness there.

 So unfortunately I'm afraid that not being dumb and making mistakes in
configure.in is still the best strategy available. The sad thing is that I
don't think writing CMake scripts, which are the new de facto standard, is
any better. There must be something intrinsically Lovecraftian in the build
systems...

 Regards,
VZ

pgpfplskcT1_G.pgp
Description: PGP signature