As long as the test is performed by compiling a native Windows application which is what all these conftest.exe files are, then LD_LIBRARY_PATH will take no part in it due to the native nature of Windows shared libraries. All bash does at that point is executes the native application. This behavior is different if PLplot were built for msys2 which would then support this but would require the msys2 runtime to run it after it was built.
Alan, Are there specific libraries that you run across that are used as part of PLplot that are typically also found within the Windows system32 directory and would cause a naming collision? I'd like to be sure that this is a case in which PLplot would have such a collision with a system library and if so, if there are any other alternatives to preventing that collision. Also, I don't know the state of it but there is a package already (https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-plplot) though it doesn't seem to be in the repository so may be under testing. I'm not sure if that provides any insight that would help you. On Sat, Mar 26, 2016 at 4:39 PM, Alan W. Irwin <[email protected]> wrote: > On 2016-03-26 02:04-0700 Greg Jung wrote: > >> On Fri, Mar 25, 2016 at 3:59 PM, Alan W. Irwin <[email protected]> >> wrote: >> >>> >>> So let's assume a native version of PLplot is built on the >>> MinGW-w64/MSYS2 platform against the mingw64/mingw-w64-x86_64 packages >>> using the correct 64-bit native runtime. However, suppose the user is >>> using the "Unixy" aspects of MinGW-w64/MSYS2 such as bash.exe >>> (installed using the msys/bash package). For this case would >>> LD_LIBRARY_PATH be available so that bash.exe user could ensure the use >>> of the mingw64/mingw-w64-x86_64 dll's (when both the Windows system >>> and mingw64/mingw-w64-x86_64 provide a dll with the same name)? >> >> >> >>> Alan >> >> >> >> So let's assume a native version of PLplot is built on the >>> >>> MinGW-w64/MSYS2 platform against the mingw64/mingw-w64-x86_64 packages >> >> >> >> Nope not gonna happen! You break out the MSYS window (MSYSTEM=MSYS) and >> the mingw-w64 trees are there only as a curiosity, for this platform. > > > Hi Greg, > > You are obviously the guy here with the most joint knowledge of PLplot > and the MinGW-w64/MSYS2 platform, but, nevertheless, I don't think > your comment is relevant to the realistic native build scenario I > described. To clarify, that scenario is a native 64-bit build of > PLplot on the MinGW-w64/MSYS2 platform where the 64-bit native runtime > is used, and the PLplot core library > must be linked against its two principal dependencies which are > libqhull (supplied by mingw64/mingw-w64-x86_64-qhull-git) and shapelib > (supplied by mingw64/mingw-w64-x86_64-shapelib) while the PLplot > device drivers may be linked against a number of additional free > software libraries depending on device driver (e.g., our ps and svg > device drivers have no extra such dependencies while our qt device > driver depends on Qt4 supplied by mingw64/mingw-w64-x86_64-qt4, our > cairo device driver depends on mingw64/mingw-w64-x86_64 packages for > pango/cairo whose names I have forgotten, etc.) > > So I believe the scenario I describe above is the one a PLplot user > would normally use to build a 64-bit native version of PLplot on the > MinGW-w64/MSYS2 platform. Thus, I would still appreciate an answer to > my original question concerning that build scenario. That is, if > bash.exe from the msys/bash package is last on your PATH (so that the > mingw64/mingw-w64-x86_64 applications and libraries are found and used > by cmake rather than the msys ones (if both kinds exist)), AND from > bash you are building, installing, and testing that native PLplot (as > we do with our comprehensive build, install, and test bash script) > does the LD_LIBRARY_PATH environment variable (as set by bash.exe) > work when doing the run-time testing part of that script for the > native PLplot that is also built and installed by that script? > > > 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 > __________________________ ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 _______________________________________________ Msys2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msys2-users
