Compiling wxWidgets-3.1.3

[Carluccio1953]

I compiled wxWidgets-3.1.3 with mingw64 and the -m32 option. Everything is going well, but if I use the -j4 option, using 4 parallel processes, the error is inevitable.
My CPU has 4 "threads / cores".
It seems that there is no priority order, that is, the files are generated before the folders to contain them, and hence the error!
Without the -j4 option everything goes the right way, but the process is very long!
Regards
Carlo Sala

[PB]

What error?

It works just fine, all you need is to build the setup_h target first, as described in the docs.

E.g. instead of

Code: Select all

mingw32-make -j4 -f makefile.gcc

You need to do

Code: Select all

mingw32-make -f makefile.gcc setup_h
mingw32-make -j4 -f makefile.gcc 

[csniper]

I met another issue related to compiling.

Under Fedora 31, I got the error below while executing configure with --with-expat=buildin

config.status: executing depfiles commands
config.status: error: in `/home/osboxes.net/wxWidgets-3.1.3/src/expat/expat':
config.status: error: Something went wrong bootstrapping makefile fragments
for automatic dependency tracking. Try re-running configure with the
'--disable-dependency-tracking' option to at least be able to build
the package (albeit without support for automatic dependency tracking).
See `config.log' for more details
configure: error: ./configure failed for src/expat/expat

Someone met the similar error message and said it might related to automake. See https://gitlab.gnome.org/GNOME/libgdata/issues/24

However, the same automake of version 1.16.1 works fine on Ubuntu 19.10.

The build succeeded after I added --disable-dependency-tracking as suggested by the configure script

Any suggestions?

[ONEEYEMAN]

Hi,
Did you check "config.log" file as suggested? What was the error?

Did you install expat library (expat and expat-devel packages)?

Thank you.

[csniper]

I did not check if the expat or expat-devel was installed----I just installed a VM with all default config and did not install expat manually.

It's weird that I could not reproduce the issue now even with a fresh source code package. So, I think we can ignore the issue now.