Opened 2 years ago
Last modified 2 years ago
#65157 assigned defect
ghc @9.2.2 error on 10.6.8: dyld: Symbol not found: _environ, expected in: /opt/x86_64/lib/libMacportsLegacySystem.B.dylib
Reported by: | barracuda156 | Owned by: | essandess (Steve Smith) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.7.2 |
Keywords: | x86_64, snowleopard | Cc: | |
Port: | ghc |
Description
dyld: Symbol not found: _environ Referenced from: /opt/x86_64/var/macports/build/_opt_x86_64_SnowLeopardPorts_lang_ghc/ghc/work/bootstrap/lib/ghc-9.2.2/bin/../lib/x86_64-osx-ghc-9.2.2/libHSprocess-1.6.13.2-ghc9.2.2.dylib Expected in: /opt/x86_64/lib/libMacportsLegacySystem.B.dylib in /opt/x86_64/var/macports/build/_opt_x86_64_SnowLeopardPorts_lang_ghc/ghc/work/bootstrap/lib/ghc-9.2.2/bin/../lib/x86_64-osx-ghc-9.2.2/libHSprocess-1.6.13.2-ghc9.2.2.dylib make: *** [update_package_db] Trace/BPT trap make: Leaving directory `/opt/x86_64/var/macports/build/_opt_x86_64_SnowLeopardPorts_lang_ghc/ghc/work/ghc-9.2.2-x86_64-apple-darwin' Command failed: cd "/opt/x86_64/var/macports/build/_opt_x86_64_SnowLeopardPorts_lang_ghc/ghc/work/ghc-9.2.2-x86_64-apple-darwin" && /usr/bin/make -j1 -w install Exit code: 2 Error: Failed to build ghc: command execution failed
10.6.8, Xcode 3.2.6, gcc11
Attachments (1)
Change History (17)
Changed 2 years ago by barracuda156
comment:1 Changed 2 years ago by barracuda156
comment:3 Changed 2 years ago by kencu (Ken)
This is a minor issue, easily worked around in general in source:
dyld: Symbol not found: _environ
but ghc does not work on 10.6.8, so I'm not sure what you are running. It doesn't seem to have anything to do with MacPorts, anyway -- does it?
comment:4 Changed 2 years ago by barracuda156
Replying to kencu:
where did this ghc come from?
Haskell.org
I tried to build it from source, since x86_64
arch is supported.
- S. I should perhaps start with what you did,
ghc
@9.0.2. The thing is that I made patches to restore PPC for @9.2.2, so hoped it can work without a sequence of earlier versions. Anyway, can make patches for @9.0.2, not a big deal.
comment:5 follow-up: 6 Changed 2 years ago by kencu (Ken)
things have changed somewhat since I last spent time on this, I notice, in legacysupport.
It is possible that legacysupport might be further enhanced to allow the upstream ghc binary to work on 10.6.8, for example adding a compat function for __environ
.
That would make things much simpler if it worked out!
comment:6 Changed 2 years ago by barracuda156
Replying to kencu:
things have changed somewhat since I last spent time on this, I notice, in legacysupport.
It is possible that legacysupport might be further enhanced to allow the upstream ghc binary to work on 10.6.8, for example adding a compat function for
__environ
.That would make things much simpler if it worked out!
I am very much eager to help with this, if you advise me where to look. I need some knowledge on how things are to be done with legacysupport
. There are cases outside of ghc
where we would want stuff to be added for support of PPC and older Intel.
comment:8 Changed 2 years ago by kencu (Ken)
comment:9 follow-ups: 10 11 Changed 2 years ago by kencu (Ken)
ghc is set up to build one and two newer versions of itself.
So ghc 9.0.2 would be expected to build ghc 9.2.x and 9.4.x, but not 9.6.x when it comes along.
Therefore, you should be able to build ghc 9.2.2 using the ghc 9.0.x I fixed for SnowLeopard here:
and it does not require __environ
to be added or any other modifications to work.
It will not (presently) work in MacPorts as the Portfiles have not been modified to use it. You would just have to install it manually like you would do with any old ghc you download from haskell.org, and you will find it works nicely.
ghc is pretty much useless without stack and cabal, and I have fixed recent versions of both of those to work on SnowLeopard as well. stack is a bit hard, as it is it's own little "mini-MacPorts" and will download compilers etc from haskell.org and other places. Those compilers will not work on SnowLeopard though, as they are all broken for SnowLeopard, so one must override the stack defaults and force it to do other things, like use a compiler you want it to use instead of the one it is designed to want to download and use.
That is a little bit hard. All in, you might reasonably expect to spend 2 to 4 weeks of consistent time getting to the point where you can fairly easily use ghc on SnowLeopard. There will be lots of googling issues involved, figuring out stack.yaml, figuring out how to change the default behaviour of stack and cabal to bend them to your will.
You might easily find 1000 issues that seem relevant for tickets -- please don't. Nobody will fix them, it's not MacPort's problem to fix. If you or me or Marcus or somebody one day does all the work needed, we can make one big PR for macports.
But to be honest, the only couple of things I needed ghc for on SnowLeopard anyway was pandoc and shellcheck, and once I built current versions of those, I just changed my copies of the pandoc and shellcheck portfiles to install my binaries on my SnowLeopard systems, and moved on.
Life is just too short!
comment:10 Changed 2 years ago by barracuda156
Replying to kencu:
ghc is set up to build one and two newer versions of itself.
So ghc 9.0.2 would be expected to build ghc 9.2.x and 9.4.x, but not 9.6.x when it comes along.
Therefore, you should be able to build ghc 9.2.2 using the ghc 9.0.x I fixed for SnowLeopard here:
I tried to install it now, but it ignores --with-gcc=
flag:
macmini:~ svacchanda$ cd /Users/svacchanda/GHC_Kencu/ghc-9.0.1 macmini:ghc-9.0.1 svacchanda$ ./configure --prefix=/opt/svacchanda/ghc9 --with-gcc=/opt/svacchanda/gcc11/bin/gcc configure: WARNING: unrecognized options: --with-gcc configure: error: Need at least gcc version 4.7 (newer recommended)
What to do? )
gcc11
I point to is build for x86_64
, of course:
macmini:ghc-9.0.1 svacchanda$ /opt/svacchanda/gcc11/bin/gcc -v Using built-in specs. COLLECT_GCC=/opt/svacchanda/gcc11/bin/gcc COLLECT_LTO_WRAPPER=/opt/svacchanda/gcc11/libexec/gcc/x86_64-apple-darwin10/11.2.0/lto-wrapper Target: x86_64-apple-darwin10 Configured with: /Users/svacchanda/Dev/gcc11/gcc-11.2.0/configure --prefix=/opt/svacchanda/gcc11 --build=x86_64-apple-darwin10 --with-as=/usr/bin/as --with-ld=/usr/bin/ld --enable-languages=all --with-tune-cpu=ivybridge CC=/opt/svacchanda/gcc10/bin/gcc CXX=/opt/svacchanda/gcc10/bin/g++ --with-sysroot=/ --enable-host-shared --disable-nls Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.2.0 (GCC)
UPD. Okay, ./configure --prefix=/opt/svacchanda/ghc9 CC=/opt/svacchanda/gcc11/bin/gcc CXX=/opt/svacchanda/gcc11/bin/g++
worked :)
comment:11 Changed 2 years ago by barracuda156
Replying to kencu:
Therefore, you should be able to build ghc 9.2.2 using the ghc 9.0.x I fixed for SnowLeopard here:
If you could share the source code, it would be super-helpful. (I tried building ghc
@9.2.2 now using your @9.0.1, and it failed immediately. I guess some changes to the source are needed, and those should be not much different from changes you made to @9.0.1.)
comment:13 Changed 2 years ago by barracuda156
comment:14 follow-up: 15 Changed 2 years ago by barracuda156
Replying to kencu:
I will put something together.
Just to remind, whenever you get time to.
I am away from my main hardware until second half of August, but I did not give up on the idea to fix GHC.
comment:15 follow-up: 16 Changed 2 years ago by kencu (Ken)
Replying to barracuda156:
Replying to kencu:
I will put something together.
Just to remind, whenever you get time to.
I put the patches here 65156
ghc
may further fail for another reason (say,alex
is broken for 10.6.x), but the specific failure seems unrelated to that.