Re: [lmi] PATCH: disable the of system libraries when building wx

[Vadim Zeitlin]

On Thu, 23 Jul 2020 10:58:00 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2020-07-21 01:06, Vadim Zeitlin wrote:
GC> > 
GC> >  I just lost quite some time on debugging a weird build problem which
GC> > turned out to be due to wx configure picking up the system libtiff version
GC> > when cross-compiling for MSW from Linux. Of course, it really shouldn't
GC> > have done this in the first place, and I hope to fix this in wx itself
GC> > later, but for now I'd like to propose the following simple patch
GC> 
GC> This is certainly okay for now at least. I could imagine that someday
GC> we might want to use a system library such as libz, but for now we don't.

 The day we want to use system libz, we'd just have to add --with-zlib=sys
to the configure options.

GC> I've read your note on '--disable-sys-libs' here:
GC>   
https://www.wxwidgets.org/blog/2014/07/easier-way-to-avoid-dependencies-on/
GC> and still have one question: does that option in effect force all of
GC> wx's possible builtin libraries to be built, meaning that it's
GC> shorthand for
GC>   '--with-libX=builtin' for all X in possible builtin libraries
GC> , or does it just prevent the use of system libraries?

 I think here it may be helpful to explain the behaviour in terms of the
implementation: specifying --disable-sys-libs simply changes the default of
all libraries that are enabled by default from "yes" to "builtin". Knowing
that "yes" means "try using system library, fall back on the bundled one if
the system library is not available", we can deduce the answers to all the
questions here.

 So, to answer the one above, --disable-sys-libs prevents the use of system
libraries by default. You can still explicitly request to use a system
version of any specific library. Typically you wouldn't do it, however,
because the purpose of --disable-sys-libs is to not have any dependencies
on the local system libraries in order to make the application
self-contained, so I can't think of any realistic scenario in which you'd
want to do this.

GC> Does each of wx's possible builtin libraries have three build-flag states:
GC>  - build the builtin, and use it whenever called for
GC>  - don't build the builtin; use a system library if available
GC>  - don't build the builtin, and prevent use of any system equivalent
GC> or only the first two?

 There are actually 4 states:

0. "--with-lib=no": This is the same as --without-lib and, for completeness,
   is also the default for a couple of libraries. It disables the use of
   the library entirely, corresponding functionality won't be available.

1. "--with-lib=builtin": Unconditionally builds the bundled version of the
   library.

2. "--with-lib=sys": Unconditionally tries to use the system version. If
   you wonder how does "unconditionally trying" work, it means that
   configure fails with an error if the system library is not available.

3. "--with-lib=yes": Same as just "--with-lib" and is also the default for
   most of the libraries. This one tries to use the system version if
   available and falls back on the bundled one.

GC> IOW, I'm not absolutely certain about this, but I think that
GC>   --with-zlib=builtin
GC> means "build libz as part of wx's install process, whether or not libz
GC> is actually to be used by the client application (lmi, e.g.); and set
GC> 'wx-config' to provide that builtin (overriding any system library)

 No, all these libraries are only used by wx internally, the application is
free to use its own versions of them if desired. This can result in
problems and for a couple of libraries, including libz and libpng, wx makes
a special effort to build its own versions of them that wouldn't conflict
with the version used by the application. But even for those for which this
isn't done, wx-config still never outputs any flags allowing to use them.

GC> If that's all true, then, as a corollary, I suppose '--disable-sys-libs'
GC> will cause us to build libraries that we'd never want.

 Technically, this is true: there could be a system library that would have
been found by configure previously and now would be built instead. However
I think that building libraries we never want is still better than
inadvertently using system libraries that we never want.

 If we're really, really certain not to use some library, the simplest
solution remains to disable it completely. Please note that I don't have
any objections against doing this, I'd just like to still be able to build
lmi using a standard wx build too, which is why I disable wxUSE_APPLE_IEEE
and wxUSE_GIF checks in wx_checks.cpp in my own branch.

GC> That would be inefficient, though the extra time would probably be
GC> negligible; but it would also mean that an error building some unwanted
GC> library could break the build, right?

 Yes. I think the probability of this happening is rather small, but
probably not exactly zero.

GC> OTOH, am I mistaken in thinking that '--disable-sys-libs' means
GC> "build every possible library"? Could it mean "build (and use) any
GC> library offered as a builtin, but only if specifically requested by
GC> '--with-libX=builtin'; but set 'wx-config' to prevent linking to a
GC> system version of any such library"? (I suppose you could do that
GC> with negligible overhead by doing something like `touch libX` to
GC> force a link error.)

 I hope the explanations above answer this, but, just to confirm, it means
"build every non-disabled (by default or explicitly) library ourselves".

GC> Here's a simpler question:
GC> 
GC> > ---------------------------------- >8 
--------------------------------------
GC> > commit 82c1165c562e3f08831809d9f70df984af8b958c
GC> > Author: Vadim Zeitlin <vadim AT tt-solutions DOT com>
GC> > Date:   2020-07-21 02:21:20 +0200
GC> > 
GC> >     Disable use of all system libraries when building wxWidgets
GC> > 
GC> >     We don't want to use any system libraries, not only Expat, linpng and
GC> >     zlib ones.
GC> > 
GC> > diff --git a/install_wx.sh b/install_wx.sh
GC> 
GC> This commit isn't in your github repository AFAICT, but it seems
GC> to be identical to e164e4282a4b2, which is part of PR #145. I think
GC> I'll just pull that 'ci-workflow' branch. That includes this
GC> '--disable-sys-libs' change, and gives the full result that you
GC> really want, right?

 Yes, but I need to revert or modify the last commit, which I've added
there for resting of USE_SO_ATTRIBUTES=1 problem only. I also need to
rebase it on the latest master in order for you to be able to merge it by
fast-forwarding, as I suppose you still don't want to create any merge
commits.

 I've done it now and rearranged the commits, so that the one discussed
above is now the first one: even if we don't use real merges (which allow
grouping the related commits together in a branch), I'd still prefer to at
least have the related commits be grouped together.

 The new commit SHA-1 is 4d51cc6d6e8f68628ce6fb1affc8b1028938f0cf and you
can already fast-forward to it ("git merge 4d51cc6") already. For the rest
of the PR 145, I wouldn't mind if you merged it now neither, of course, but
I must warn you that I will have more changes to it in the future (which I
thought to discuss in the thread about it, but, briefly, at the very least
I want to add MSW 64 builds to it too, and ideally I'd like to also add the
Linux build and run all the tests during these builds automatically). Ideal
would be for me to "own" this file, i.e. be able to commit changes to it
myself, as I currently can do with configure.ac and Makefile.am.

 Would this be acceptable?
VZ

pgpp6xEOyYvtq.pgp
Description: PGP signature