On Mon, Dec 14, 2015 at 12:43 PM, Ray Donnelly <mingw.andr...@gmail.com> wrote: > On Mon, Dec 14, 2015 at 2:42 AM, Alan W. Irwin > <ir...@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 >> __________________________ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake