wxWidgets / wxWidgets

Cross-Platform C++ GUI Library
https://www.wxwidgets.org/
6.14k stars 1.76k forks source link

In-place wx-config doesn't work on openSUSE #23737

Open swt2c opened 1 year ago

swt2c commented 1 year ago

Description

The in-place wx-config sets (at least) the include path incorrectly on openSUSE Leap. See below for the mismatch between lib and lib64.

ec2-user@ip-172-31-76-39:~/wxWidgets/bld> ./wx-config --cflags
-I/home/ec2-user/wxWidgets/bld/lib64/wx/include/gtk3-unicode-3.3 -I/home/ec2-user/wxWidgets/include -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread
ec2-user@ip-172-31-76-39:~/wxWidgets/bld> ls -l /home/ec2-user/wxWidgets/bld/lib64/wx/include/gtk3-unicode-3.3
ls: cannot access '/home/ec2-user/wxWidgets/bld/lib64/wx/include/gtk3-unicode-3.3': No such file or directory
ec2-user@ip-172-31-76-39:~/wxWidgets/bld> ls -l /home/ec2-user/wxWidgets/bld/lib/wx/include/gtk3-unicode-3.3
total 0
drwxr-xr-x 2 ec2-user users 21 Jul 26 20:12 wx

It's not immediately clear the best way to fix this. Should (can?) the in-place wx-config override the libdir? Or should wx use lib64 as the directory name if that's what the libdir is configured as?

To reproduce this:

  1. Install openSUSE Leap 15.5 (I used AWS EC2 AMI provided by openSUSE)
  2. Install packages gcc-c++ gtk3-devel make git
  3. Log out and log back in (NOTE: this is required as installing make installs a package called site-config which sets environment variables)
  4. Clone wxWidgets
  5. cd wxWidgets && mkdir bld && cd bld && ./configure

Platform and version information

config.log

vadz commented 1 year ago

Sorry, no time to install OpenSuSE and debug this right now, so I wonder if you already know where does libdir value come from? For me it's defined just as ${exec_prefix}/lib with exec_prefix being just prefix by default, but overridden to the build directory by wx-config-inplace. How does it end up being .../lib64 instead?

I also see this code in configure where we decide to use lib64 on any 64-bit Linux system without /usr/lib/x86_64-linux-gnu (can you confirm that openSUSE indeed doesn't have it?):

https://github.com/wxWidgets/wxWidgets/blob/703d815ef8c1eb58cd655a74ebcb65ae4dccd26d/configure.in#L1933-L1938

and I wonder if it (still) makes sense to do this, i.e. if lib64 is really still used, as I think it might have been a transient thing during 32-to-64 bit transition and by now everybody is back to just using lib. Or maybe not?

swt2c commented 1 year ago

Okay, so the lib64 value is not coming from wx, but from an autoconf "site configuration" file (they set CONFIG_SITE environment variable) that gets sourced when you run autoconf. I've attached it because I'm not sure where to link to it.

x86_64-unknown-linux-gnu.txt

swt2c commented 1 year ago

This is enough to reproduce the problem (it's basically what happens in that site configuration file): ../configure --libdir='${exec_prefix}/lib64'

In fact, given that, we can probably at least work around this in wxPython's build by just running: ./configure --libdir='${exec_prefix}/lib'

vadz commented 1 year ago

But it looks like we really ought to be using lib64 if they specifically set libdir like this, shouldn't we? Or it doesn't really matter for the directory we create under the build one?

swt2c commented 1 year ago

But it looks like we really ought to be using lib64 if they specifically set libdir like this, shouldn't we? Or it doesn't really matter for the directory we create under the build one?

That would probably be ideal, yeah. Do you have any idea where in configure that directory gets created? :-) The only mkdir I could find was in a Windows section, so that couldn't be it.

vadz commented 1 year ago

It's implicitly created by AC_CONFIG_FILES() and AC_CONFIG_COMMANDS() in configure.ac, so all libs there should be replaced. The problem is that I'm not exactly sure what to replace them with: I don't know if $libdir is defined there (and if it is, we can't use it directly, we need to use just its last component, i.e. ${libdir##*/}).

swt2c commented 1 year ago

Thanks for that pointer. I guess the other possibility is for wx-config-inplace.in to change things back to lib, if that's possible.

However, I'm thinking this may not really be a very high priority issue. After all, this issue seems like it should have existed for 10+ years but no openSUSE users have reported it before (other than via wxPython).

ShizuhaAki commented 1 year ago

Reproduced in Tumbleweed. Please remove the Leap in the title.

vadz commented 1 year ago

It really shouldn't be difficult to fix this, if anybody can test the solution proposed above there or at least tell me what $libdir value is, it would be nice.

taler21 commented 11 months ago

How and where should one check the value of $libdir?

For me it's defined just as ${exec_prefix}/lib with exec_prefix being just prefix by default, but overridden to the build directory by wx-config-inplace. How does it end up being .../lib64 instead?

In config.status in the build directory I find S["libdir"]="${exec_prefix}/lib64" and S["exec_prefix"]="${prefix}" with prefix being the build directory.

I also see this code in configure where we decide to use lib64 on any 64-bit Linux system without /usr/lib/x86_64-linux-gnu (can you confirm that openSUSE indeed doesn't have it?):

I can confirm that openSUSE doesn't have a directory /usr/lib/x86_64-linux-gnu/. I checked this on openSUSE Leap 42.3, openSUSE Leap 15.5 and openSUSE Tumbleweed.