[CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

[Alan W. Irwin]

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.

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.

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
__________________________