[CMake] NO_SYSTEM_ENVIRONMENT_PATH globally?

[Ray Donnelly]

On Mon, Dec 14, 2015 at 12:43 PM, Ray Donnelly <mingw.android at gmail.com> wrote:
> 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.

Replying to myself; first sign of something --good .. but I've thought
immediately of a case where I can't modify PATH like I suggested. We
have some packages (e.g. hlsl2glslfork) that use bison and flex, and
those packages use msys2 flex and bison. For those to work, I can't
remove /usr/bin from PATH for all PKGBUILDs that invoke CMake as I had
planned, so how should I proceed here? (I wouldn't be surprised if
clang/llvm also call bison and flex).

>
> 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
>> __________________________