ios_base4Init symbol not found
Closed this issue · 10 comments
When trying to build pandoc-cli 3.1.2, I fail to build unicode-collation-0.1.3.6, with the following error:
Failed to build unicode-collation-0.1.3.6.
Build log ( /Users/jim/.cabal/logs/ghc-8.10.7/ncd-clltn-0.1.3.6-8c127111.log
):
Configuring library for unicode-collation-0.1.3.6..
Preprocessing library for unicode-collation-0.1.3.6..
Building library for unicode-collation-0.1.3.6..
[ 1 of 10] Compiling Text.Collate.Lang
[ 2 of 10] Compiling Text.Collate.Trie
[ 3 of 10] Compiling Text.Collate.UnicodeData
[ 4 of 10] Compiling Text.Collate.CanonicalCombiningClass
<command line>: dlopen(/Users/jim/.cabal/store/ghc-8.10.7/lib/libHStxt-2.1.1-3ae4d348-ghc8.10.7.dylib, 5): Symbol not found: __ZNSt8ios_base4InitD1Ev
Referenced from: /Users/jim/.cabal/store/ghc-8.10.7/lib/libHStxt-2.1.1-3ae4d348-ghc8.10.7.dylib
Expected in: flat namespace
in /Users/jim/.cabal/store/ghc-8.10.7/lib/libHStxt-2.1.1-3ae4d348-ghc8.10.7.dylib
This is on Mac OS 10.15.7, using a macports build chain.
$ cc --version
clang version 11.1.0
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-11/bin
$ clang --version
clang version 11.1.0
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-11/bin
$ gcc --version
gcc (MacPorts gcc10 10.4.0_5+stdlib_flag) 10.4.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ which -a gcc
/opt/local/bin/gcc
/usr/bin/gcc
I've never seen that and I don't have any ideas. It's hard to diagnose this without knowing more about the whole macports build. The module at which it is failing is one that does TemplateHaskell; so at that point a Haskell interpreter is being engaged to evaluate the TH expressions.
OK, if it's not able to find a dynamic library, it may be because macports installs these in /opt/local; maybe you need to do something like
export DYLD_LIBRARY_PATH=/opt/local/lib
Diagnosing these things is such a pain because there are so many hundreds of variables. Obviously something changed in the past few months to produce this, but it may not be in a module you control, it could be something upstream in cabal, or some upgrade via MacPorts. Hard to even figure out what environment the failing build process is seeing, or how to update it... ugh. Anyway, that export declaration is not fixing the build. I'll update here if I make any progress.
Now after doing a cabal clean; cabal install --only-dependencies it's failing in a way that says pandoc-types is involved. I didn't see that before. is this just because unicode-collation is a dependency of pandoc-types?
Failed to build unicode-collation-0.1.3.6.
Build log ( /Users/jim/.cabal/logs/ghc-8.10.7/ncd-clltn-0.1.3.6-8c127111.log
):
Configuring library for unicode-collation-0.1.3.6..
Preprocessing library for unicode-collation-0.1.3.6..
Building library for unicode-collation-0.1.3.6..
[ 1 of 10] Compiling Text.Collate.Lang
[ 2 of 10] Compiling Text.Collate.Trie
[ 3 of 10] Compiling Text.Collate.UnicodeData
[ 4 of 10] Compiling Text.Collate.CanonicalCombiningClass
<command line>: dlopen(/Users/jim/.cabal/store/ghc-8.10.7/lib/libHStxt-2.1.1-3ae4d348-ghc8.10.7.dylib, 5): Symbol not found: __ZNSt8ios_base4InitD1Ev
Referenced from: /Users/jim/.cabal/store/ghc-8.10.7/lib/libHStxt-2.1.1-3ae4d348-ghc8.10.7.dylib
Expected in: flat namespace
in /Users/jim/.cabal/store/ghc-8.10.7/lib/libHStxt-2.1.1-3ae4d348-ghc8.10.7.dylib
Failed to build pandoc-types-1.23.1.
Build log ( /Users/jim/.cabal/logs/ghc-8.10.7/pndc-typs-1.23.1-307dc7e9.log ):
Configuring library for pandoc-types-1.23.1..
Preprocessing library for pandoc-types-1.23.1..
Building library for pandoc-types-1.23.1..
[1 of 7] Compiling Paths_pandoc_types ( dist/build/autogen/Paths_pandoc_types.hs, dist/build/Paths_pandoc_types.o, dist/build/Paths_pandoc_types.dyn_o )
[2 of 7] Compiling Text.Pandoc.Definition ( src/Text/Pandoc/Definition.hs, dist/build/Text/Pandoc/Definition.o, dist/build/Text/Pandoc/Definition.dyn_o )
<command line>: dlopen(/Users/jim/.cabal/store/ghc-8.10.7/lib/libHStxt-2.1.1-3ae4d348-ghc8.10.7.dylib, 5): Symbol not found: __ZNSt8ios_base4InitD1Ev
Referenced from: /Users/jim/.cabal/store/ghc-8.10.7/lib/libHStxt-2.1.1-3ae4d348-ghc8.10.7.dylib
Expected in: flat namespace
in /Users/jim/.cabal/store/ghc-8.10.7/lib/libHStxt-2.1.1-3ae4d348-ghc8.10.7.dylib
cabal: Failed to build unicode-collation-0.1.3.6 (which is required by
exe:pandoc from pandoc-cli-3.1.12). See the build log above for details.
Failed to build pandoc-types-1.23.1 (which is required by exe:pandoc from
pandoc-cli-3.1.12). See the build log above for details.
This is because both pandoc-types and unicode-collation use Template Haskell. The problem isn't anything specific in either module; it's just that ghc is trying to fire up a Haskell interpreter here and (for some reason) looking for and not finding some dynamic libraries.
I'd report this to macports. It is not a bug in any of my packages; it's something to do with their build.
Upgrading ghc and cabal smacked me into another issue, the attempt to build pandoc was getting stick at an earlier point (trying to build basement I think) because it was invoking gcc with --target=x86_64-apple-darwin. I think something wanted to or thought it was building using clang instead. I couldn't immediately figure out how to get clang to have priority over gcc (using export CC=... didn't work, and cc on my path already points to clang). So I resorted to the hack of putting a symlink high in my path named gcc but pointing to clang. Then build pandoc using:
cabal clean
cabal update
cabal install --only-dependencies
sudo port -f deactivate libiconv
cd pandoc-cli
cabal configure --prefix=/usr/local --flags="embed_data_files lua server" # lua53 no longer available
cabal build
cd ..
cp -vi ./dist-newstyle/build/x86_64-osx/ghc-*/pandoc-*/x/pandoc/build/pandoc/pandoc ./pandoc.bin
strip pandoc.bin
And that works. The step of deactivating MacPort's version of libiconv is one I learned several versions back with pandoc. I don't know if it's still necessary. Maybe someday I'll figure out how to get cabal to use the c/c++ compiler I tell it to, and won't have to resort to the hack of symlinking gcc to clang. But for now, this got me a working build of pandoc.
You could always use the build we provide for each version!
Thanks yes, and (in addition to the enormous value you put into developing these tools) the availability of the binaries for each version is also welcome.
At done points over the last 15 or so years. I've run my own local modifications to pandoc (sometimes experimenting with changes to propose to mainline, though if I remember right I only ever contributed design discussion not code to this project). At other points I was running a custom compilation. For example, when it was still possible to bundle lua53 though mainline had moved to lua54.
At the moment I'm just using a vanilla build (well with data files built in). But I value keeping track of what I need to do to compile it myself when I need to.