> One peculiarity with the ordering is that linkers only search static
> archives for existing undefined references. If the reference to `Cffi`
> actually comes first, then nothing should be required from it yet and
> *it shouldn't be linked* (absent options like GNU ld's
> `--whole-archive`).
One peculiarity with the ordering is that linkers only search static
archives for existing undefined references. If the reference to `Cffi`
actually comes first, then nothing should be required from it yet and
*it shouldn't be linked* (absent options like GNU ld's
`--whole-archive`).
This said,
I believe I've figured out what is happening here. This will take a bit of
explanation, so bear with me.
First, it's important to note that this behavior depends on whether your
GHC was configured with the `--with-system-libffi` flag or not. If it was
configured with this flag, then GHC will
No, I'm using macOS 10.15.7 (BuildVersion 19H2) on an x86_64 machine.
Ryan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
i think brandon is also referring to the Rosetta stuff on Arm Macs, are you
using one of those?
On Mon, Aug 8, 2022 at 8:00 PM Brandon Allbery wrote:
> https://developer.apple.com/forums/thread/692383 is what I'm thinking
> of, but in this case there would still be library references shown by
>
https://developer.apple.com/forums/thread/692383 is what I'm thinking
of, but in this case there would still be library references shown by
"otool -L", so I guess that's not what you're seeing.
On Mon, Aug 8, 2022 at 7:49 PM Ryan Scott wrote:
>
> Possibly? I'm not familiar with the system cache
Possibly? I'm not familiar with the system cache you're referring to, but
it's a more solid lead than what I have currently. Do you know how one
would confirm if this is the case or not?
Ryan
___
ghc-devs mailing list
ghc-devs@haskell.org
Any chance this is related to the weird system cache thing for system
dylibs that came in with the most recent OS X releases? I don't think
those show up in the normal way.
On Mon, Aug 8, 2022 at 7:33 PM Ryan Scott wrote:
>
> I should clarify that I'm using a borrowed macOS on which I don't have
I should clarify that I'm using a borrowed macOS on which I don't have
admin privileges, so I'm unable to install pkg-config. As a result, I'm
commenting out the pkgconfig-depends: line in libffi.cabal and manually
specifying the extra-lib-dirs and include-dirs via a cabal.project.local
file.
ahh, pkgconfig is what i was overlooking!
agreed with viktor, using the system provided one is definitely safer
On Mon, Aug 8, 2022 at 10:46 AM Viktor Dukhovni
wrote:
> On Mon, Aug 08, 2022 at 09:59:48AM -0400, Viktor Dukhovni wrote:
>
> > On my MacOS laptop I get:
> >
> > $
On Mon, Aug 08, 2022 at 09:59:48AM -0400, Viktor Dukhovni wrote:
> On my MacOS laptop I get:
>
> $ /usr/local/bin/pkg-config --libs libffi
> -lffi
>
> which does not use the "brew"-installed libffi. Not surprising, since
> /usr/local/lib/pkgconfig/ has no symlink to the "libffi.pc"
On Mon, Aug 08, 2022 at 07:29:38AM -0400, Ryan Scott wrote:
> An exception to this rule is macOS, however. On macOS, building libffi
> always appears to default to linking against the static version of libffi,
> even when a dynamic version is also available. To reproduce this
> phenomenon, check
I'm trying to diagnose strange GHC linking behavior which, as far as I can
tell, only occurs on macOS. I feel a bit out of my league debugging this,
so I'm hoping someone knows what is causing this.
When building the Haskell libffi library [1], it will link pass -lffi to
GHC. Typically, most
13 matches
Mail list logo
