Text-2.0 causes non-portable binaries by default on windows
hasufell opened this issue · comments
It uses simdutf by default. That causes GHC to link against its internal libstdc++ on windows, which may not be installed at all or exposed as lib search path.
I'm not certain, but this sounds related to #461.
Yes, this is indeed a hazard of enabling simdutf by default and was one of my concerns about enabling it in the GHC distribution. The thought was that users wanting to redistribute executables would do one of the following:
- include
libstdc++in their distribution if they depend upontext - statically link against the C++ standard library; sadly, this is surprisingly tricky to arrange in a platform agnostic manner
- ensure they they explicitly disable the
simdutfflag in their install plan
For the record, we have in fact disabled simdutf in all of the GHC distributions shipping with text-2 thusfar. In light of issues like this, it is hard for me to imagine being able to change that.
The one possible strategy I can think of would be to link text statically against the C++ standard library. However, as noted above, this is quite nontrivial as it is quite platform-dependent. IIRC Apple platforms don't even provide a static object to link against. Moreover, even on Linux it can be risky since exception handling often relies on dladdr. However, this may not matter in the case of a library like simdutf which is (AFAICT) entirely noexcept.
For the record, we have in fact disabled
simdutfin all of the GHC distributions shipping withtext-2thusfar.
If that's the case then why ghcup build was affected?
If that's the case then why
ghcupbuild was affected?
Presumably because the constraints of @hasufell's project precluded use of his compiler's (GHC 8.10.7) pre-existing text and text.cabal enables the simdutf flag by default. He told me via IRC that for the moment he has explicitly disabled the simdutf flag in his project.
Correct. I reinstall the text boot library. This isn't very uncommon.
Sigh, that's all pretty disappointing. I was under illusion that build-depends: system-cxx-std-lib is all a package needs to declare for GHC to take care of the rest.
Probably we have to disable simdutf by default on Windows. A CI job, running in an empty environment, similar to haskell/bytestring#500, would be helpful to reproduce the issue.
Right, with GHC 8.10 we do not pass build-depends: system-cxx-std-lib, but rather extra-libraries: stdc++, which is problematic.
@hasufell What would happen if you try GHC 9.4 and text +simdutf? Does the problem persist?
What would happen if you try GHC 9.4 and text +simdutf? Does the problem persist?
I think nothing. That's a limitation of cabal-install and ghc-pkg package databases: The latter doesn't record flags, and cabal-install doesn't really have a way to force recompilation of exactly the same version as in global package db (if you want to change flags).
E.g.
aeson% cabal build -w ghc-9.4.3 --constraint='text +simdutf' --dry
...
Build profile: -w ghc-9.4.3 -O1
In order, the following would be built (use -v for more details):
...
and then cabal-plan topo shows text in blue
meaning it is coming from global db.
I think nothing. That's a limitation of cabal-install and ghc-pkg package databases:
That is an interesting point; this is something that we should probably try to address. Encoding flag settings in the package database wouldn't be hard although it's not entirely clear to me whether they belong there. They aren't defined in the CABAL specification but given that they are now enshrined in the package description format, I suppose it would be sensible to include them in the package registration format as well. We should open a haskell/cabal ticket about this.
We should open a haskell/cabal ticket about this.
I have opened haskell/cabal#8702 to track this.