No, it's a problem if the package you want to use happens to depend on libgcc or libstdc++ and was built with a different ABI or compiler version than what Julia was built with.
It's not that hard to write spec files and submit them to opensuse. The build service even makes new binaries for you automatically, and you can point WinRPM at your own personal project to use binaries before you've even submitted them to the official project. Msys2 is still all built by hand AFAIK, and I've had PR's sit for months there with zero acknowledgement whatsoever that their packaging is buggy or outdated in many cases. On Tuesday, May 31, 2016 at 6:39:46 PM UTC-7, Charles Barto wrote: > > while I understand the possible ABI compatibility issues unless I'm > mistaken that should only effect julia programs if the package you are > directly depending on has a different ABI between msys2 and WinRPM (in > which case you should pick one (probably WinRPM) or prod the upstream repo > to update the library in question. Beyond that the only issue I can think > of is if you somehow managed to get a library that links statically against > microsoft's libc, However I know mingw always links with the (really, > really, old) MSVCRT.DLL, and there's no problem linking dynamically with > multiple Microsoft libcs. > > I agree that WinRPM is better where available, but this could be useful in > some cases (there are lots more packages in msys than there are in WinRPM). > > On Monday, May 30, 2016 at 1:31:50 AM UTC-4, Tony Kelman wrote: >> >> There are many variations in how you can build mingw-w64 gcc. C++ >> libraries break ABI on nearly every GCC version change, so you need to be >> careful to be consistent. There's also which exception handling model you >> use, which threading model you use, and other various configuration flags >> of how you build GCC, and even -D defines that you can set at compile time >> when building different libraries. The "abstraction library" that you're >> referring to is the posix layer itself used for msys2's bash and gmake - >> it's cygwin with minor patches. The mingw64 package set doesn't link >> against the posix layer, but if you try to load libraries even all compiled >> using nominally "mingw64" compilers, you can get in trouble if the subtle >> ABI configurations of the compilers used to build the various libraries >> don't match. >> >> The most reliable way to interoperate with MSYS2-packaged libraries would >> be to build and package Julia itself using MSYS2's toolchain. This should >> be possible but I don't think anyone has gotten very far with it recently, >> except by accident from not reading the caveats in README.windows.md. >> You'd then need to avoid libraries cross-compiled from Cygwin (which is >> what the Julia buildbots use) or most Linux distributions (which is what >> WinRPM uses, from opensuse) - which are almost all set up to be ABI >> compatible with one another, but won't necessarily match MSYS2. >> >> It should also be possible to read the pacman repository metadata >> directly and be more selective about what you download - WinRPM doesn't >> need a full installation of rpm for example. I think Yichao Yu had some >> initial bindings for libalpm but I haven't tested whether it works for >> MSYS2 packages. Last I checked I don't think MSYS2 is building libalpm as a >> shared library, which you'd need for Julia bindings. >> >> >> On Sunday, May 29, 2016 at 9:01:44 PM UTC-7, Charles Barto wrote: >>> >>> I wrote it to get the postgres libraries (libpq and friends). What are >>> the ABI differences? I know msys2 itself uses an abstraction library but >>> the ming64 packages shouldn't have any ABI problems (although some packages >>> may be a different version than those in winRPM) >>> >>> On Saturday, May 28, 2016 at 8:20:40 AM UTC-4, Tony Kelman wrote: >>>> >>>> What package is in msys2 but not winrpm? This seems like a huge >>>> download to avoid writing a spec file and submitting it to the opensuse >>>> build service. Julia is also not using exactly the same ABI as msys2's >>>> toolchain so this isn't going to be reliable for C++ dependencies, or on >>>> 32 >>>> bit. >>>> >>>> >>>> On Friday, May 27, 2016 at 11:51:13 PM UTC-7, Charles Barto wrote: >>>>> >>>>> Hello, I've recently needed to use some packages that were not >>>>> available in the WinRPM repositories but were in MSys2's mingw64 repo. I >>>>> naturally set out to build a package provider for MSys2, after some work >>>>> figuring out >>>>> >>>>> The github repository is located at >>>>> https://github.com/barcharcraz/MSys2.jl and I'd love for a few people >>>>> to try it before I submit a pull request for METADATA. >>>>> >>>>> The build file will download and extract all of msys2 to a local >>>>> directory, and then update. It's a pretty large download (in the hundreds >>>>> of megabytes) so >>>>> try not to build the package on a slow connection. >>>>> >>>>> After downloading the distribution package the build script updates >>>>> the repositories, installs the latest version of pacman, then upgrades >>>>> all >>>>> packages twice. >>>>> I need to do two calls to upgrade because when msys2 updates its >>>>> runtime you need to restart the shell. >>>>> >>>>> >>>>>
