lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] pc-linux-gnu: wxPdfDoc configure fails


From: Vadim Zeitlin
Subject: Re: [lmi] pc-linux-gnu: wxPdfDoc configure fails
Date: Thu, 8 Oct 2020 22:48:06 +0200

On Thu, 8 Oct 2020 20:30:26 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> On 2020-10-08 15:42, Vadim Zeitlin wrote:
GC> > On Thu, 8 Oct 2020 15:15:11 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:
GC> [...]
GC> > GC> and 'config.log' says:
GC> > GC> 
GC> > GC> configure:11670: checking for wx-config
GC> > GC> configure:11689: found 
/opt/lmi/local/gcc_x86_64-pc-linux-gnu/bin/wx-config
GC> > GC> configure:11702: result: 
/opt/lmi/local/gcc_x86_64-pc-linux-gnu/bin/wx-config
GC> > GC> configure:11717: checking for wxWidgets version >= 2.8.0
GC> > GC> configure:11838: result: no
GC> > GC> 
GC> > GC> However, when I run the 'wx-config' reported above at the command line
GC> > GC> myself, it says I have 3.1:
GC> > GC> 
GC> > GC> $/opt/lmi/local/gcc_x86_64-pc-linux-gnu/bin/wx-config --release
GC> > GC> 3.1
GC> > GC> 
GC> > GC> Any ideas?
GC> > 
GC> >  Not really. Configure code examines the output of "$WX_CONFIG --version"
GC> > and judging from the error message it didn't get anything at all from it
GC> > (otherwise it would have said "no (version x.y.z is not new enough)").
GC> > However I don't see why wouldn't the command it uses, i.e.
GC> > 
GC> > /opt/lmi/local/gcc_x86_64-pc-linux-gnu/bin/wx-config --version 2>/dev/null
GC> > 
GC> > work. Could you please run it interactively just to check what happens? If
GC> 
GC> /opt/lmi/src/lmi[0]$/opt/lmi/local/gcc_x86_64-pc-linux-gnu/bin/wx-config 
--version 2>/dev/null
GC> 3.1.4
GC> 
GC> I assume that's close enough even though it's not exactly "3.1.5":

 Yes, of course, I've just forgotten that the current version is 3.1.4 and
not 3.1.5 yet.

GC> Copying the "++" command and executing it manually reproduces failure:
GC> 
GC> /opt/lmi/src/lmi[0]$/opt/lmi/local/gcc_x86_64-pc-linux-gnu/bin/wx-config 
--exec-prefix=/opt/lmi/local/gcc_x86_64-pc-linux-gnu --prefix=/opt/lmi/local 
--host=x86_64-pc-linux-gnu --version
GC> 
GC>           Warning: No config found to match: 
/opt/lmi/local/gcc_x86_64-pc-linux-gnu/bin/wx-config 
--exec-prefix=/opt/lmi/local/gcc_x86_64-pc-linux-gnu --prefix=/opt/lmi/local 
--host=x86_64-pc-linux-gnu --version
GC>                    in /opt/lmi/local/gcc_x86_64-pc-linux-gnu/lib/wx/config

 OK, I'm pretty sure this is a bug in wx-config --host handling, maybe the
same one as https://trac.wxwidgets.org/ticket/12698 or maybe a different
one. I've tried to touch it as little as possible since ~20 years, but I'll
muster the courage to look at it and fix this soon. But the question is,
why do use --host at all in the native build? I'm almost certain that if
you didn't specify it, things should work.

GC> >  Of course, an alternative could be to wait for a few more days until I
GC> > finish my submodularization changes, as they should work both for cross-
GC> > and normal compilation, but if you need it right now, I can only think of
GC> > the above, sorry.
GC> 
GC> I don't want to distract you from that higher priority. I'm just hoping that
GC> a quick glance will reveal to you some simple mistake I've made. Otherwise
GC> I'll try brute force, which can be educational and does often work.

 The problem is that fixing it at lmi level will almost certainly require
changes to the files I'm modifying too (e.g. install_wx.sh), so we might
have conflicts due to this. I should be able to resolve them, of course,
but I don't want you to lose time with resolving them if I submit my
changes before you make yours...

VZ

Attachment: pgpQTEyEMcKAX.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]