[CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

[Ray Donnelly]

On Mon, Dec 14, 2015 at 2:42 AM, Alan W. Irwin
<irwin at beluga.phys.uvic.ca> wrote:
> On 2015-12-14 01:06-0000 Ray Donnelly wrote:
>
>> Hi,
>>
>> I ran into a problem on MSYS2 recently building llvm+clang for
>> mingw-w64 using CMake 3.4.1 (we carry a few local patches, they're
>> fairly minor, except the qt5-static one, and I don't think they are
>> likely related to this:
>> https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-cmake)
>>
>> MSYS2 has two shells .. actually it's 3 or 4, but for simplicity we'll
>> ignore the 32-bit ones and pretend there's only 2 64-bit shells, one
>> launched with msys2_shell.bat and one launched with mingw64_shell.bat.
>> Under msys2_shell.bat, the "/mingw64/bin" folder doesn't appear at all
>> in PATH, while under mingw64_shell.bat, it appears at the very front,
>> before "/usr/bin" (which contains the msys2 software).
>>
>> When running CMake to configure the build for libclang, it tries to
>> see if if can find libdl with "find_library (DL_LIBRARY_PATH dl)".
>> Unfortunately it finds the msys-2.0.dll-linked libdl.a in /usr/lib
>> because NO_SYSTEM_ENVIRONMENT_PATH isn't set, which isn't then in
>> /mingw64/bin/g++.exe's linker search path (and even if it was, we
>> don't want to link msys-2.0.dll software into native software!).
>
>
> Hi Ray:
>
> I only have indirect experience with MinGW-w64/MSYS2 (i.e., reading detailed
> build reports from a tester of PLplot on that platform), but my
> understanding is
> to build software for that platform you would normally
> always use mingw64_shell.bat (or mingw32_shell.bat for the 32-bit
> case).  And if /mingw64/bin is first on the PATH for that shell my
> understanding is that if libdl is in the correct location in /mingw64,
> then it should normally and automatically be found by CMake for
> /mingw64/bin/g++.exe when NO_SYSTEM_ENVIRONMENT_PATH is not set.

Hi Alan,

I'm one of the founders of MSYS2 (not that that means I know what I'm
talking about mind you!) .. You are right, that normally for building
mingw-w64 x86_64 software on MSYS2 you'd use mingw64_shell.bat, but
when building MSYS2 packages via makepkg-mingw, you'd run
msys2_shell.bat instead since that builds both the 32-bit and 64-bit
variants setting the correct environment up beforehand each time.

The issue I've got here is that on MSYS2 we've decided that we don't
want to provide libdl for mingw-w64 but do provide it for msys2, so
there'll never be a /mingw{64,32}/lib/libdl.a or
/mingw{64,32}/lib/libdl.dll.a, but there is a /usr/lib/libdl.a. When
building mingw-w64 software, the front of PATH will be
"/mingw64/bin:/usr/bin" or "/mingw32/bin:/usr/bin" and that causes
CMake to find /usr/lib/libdl.a due to NO_SYSTEM_ENVIRONMENT_PATH.

I think the best I can do is to edit each of our CMake using PKGBUILD
scripts to set PATH to a clean value just before invoking CMake. This
is something I didn't really want to have to do.

To my mind, this rummaging around the user's system path feature seems
too prone to randomness and a large source of build variance. Some of
this comes from my liking for reproducible builds where environmental
differences are kept out of the equation.

>
> However, it appears that is not the find result you are getting and
> you have responded by trying to find a way to set
> NO_SYSTEM_ENVIRONMENT_PATH globally.  But I think it would be better
> instead to explore the case where the NO_SYSTEM_ENVIRONMENT_PATH
> command is not used to figure out how to get that scenario to
> correctly find libdl.
>
> Therefore, I suggest you make a simple test
> project which uses "find_library (DL_LIBRARY_PATH dl)" (without
> NO_SYSTEM_ENVIRONMENT_PATH) to find dl, and fiddle with your PATH (and
> also CMake version just in case it turns out you are fighting against
> some recently introduced find_library regression) to see what the
> results are.  And if nothing works for any cmake version with
> /mingw64/bin at the very front of your PATH, then you can always fall
> back to setting the -DCMAKE_LIBRARY_PATH:PATH cmake option to force
> finding the correct version of libdl.
>
> Note in your tests above you might also want to try both the "Unix
> Makefiles" and "MSYS Makefiles" generators.  Our PLplot experience is
> that choice does make a difference for one find module (wxwidgets) on
> MinGW-w64/MSYS2, and I suppose it is possible it might also make a
> difference to the results from a single find_library command as well.
>

"MSYS Makefiles" should be the correct choice on MSYS2 if you are
compiling with native compilers. If you are using cross compilers then
"Unix makefiles" should be the correct choice. There is a bug in
wxwidget's wx-config not being sympathetic towards the idiosyncrasies
of MSYS2 that I will push a fix for soon-ish (the prefix variable
needs to be modified through cygpath -m if MSYSTEM is MINGW32 or
MINGW64). However, due to person-power issues, the package will not be
rebuilt for a while, but hopefully you can build your own to test?

--
Thanks,

Ray.

> Alan
>
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________