On Sat, Mar 26, 2016 at 1:39 PM, Alan W. Irwin <[email protected]>
wrote:
> On 2016-03-26 02:04-0700 Greg Jung 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
>>
>
>
> 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.
> 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.
>>
>> ok I was mis-interpreting that to mean, you wanted to mix binaries
compiled with
mingw-w64 with those compiled in msys (under /usr/bin, not /mingw64/bin).
I wanted to
discourage any attempt at mixing the products of the two systems.
> However, suppose the user is
>>> using the "Unixy" aspects of MinGW-w64/MSYS2 such as bash.exe
>>>
>> For most usage, bash and its accompanying utilities (also perl, python)
is the only posix used,
the mingw products are then run according to windows' rules.
> (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)?
>>
>> The short answer is, I think, no because its not built into MSVC.dll
which is what mingw runs off of.
If you make posix-y stuff (which have no mingw in them) then it looks like
it may be a kludge
for dlopen behavior (an explicit call to bring in a shared library), but
not a vital aspect.
>
> 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 all of the dependencies need to be in the user path, which will include
the directory from which the
executable is run. As are the windows rules. Bash will only dance with
pathnames and such.
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?
>
> I can't follow your grammar to a recognizable condition that has bothered
me, but one tidbit
I can add is that the .dll's which are for msys have similar names but
include "msys-"
prefixed to them (as for cygwin) so that /usr/bin/XXX.dll would not be
picked up by mistake,
if XXX were otherwise absent. So I can see an msys-xml2-2.dll in /usr/bin
which I am sure would only be
called in when I ran an msys executable and not by any mingw- products.
------------------------------------------------------------------------------
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
