Skip to content
This repository

NativeCall attempts to load nonexisting .bundle when .dylib is available on Mac OS X. #7

Open
bbkr opened this Issue March 30, 2012 · 6 comments

2 participants

Pawel Pabian Arne Skjærholt
Pawel Pabian
bbkr commented March 30, 2012
 DYLD_LIBRARY_PATH=/opt/local/lib perl6 -e 'use NativeCall; sub GeoIP_new(Int) returns OpaquePointer is native("libGeoIP") { * }; GeoIP_new(0);'

gives

Cannot locate native library 'libGeoIP.bundle'
  in method postcircumfix:<( )> at /Users/bbkr/.perl6/lib/NativeCall.pm6:102
  in <anon> at src/gen/BOOTSTRAP.pm:812
  in any <anon> at src/gen/BOOTSTRAP.pm:808
  in block <anon> at -e:1

Somehow it cannot fallback to available dylib:

$ ls /opt/local/lib/libGeoIP.*

/opt/local/lib/libGeoIP.1.dylib /opt/local/lib/libGeoIP.a       /opt/local/lib/libGeoIP.dylib   /opt/local/lib/libGeoIP.la

Everything works when dylib is forced using

is native("libGeoIP.dylib")

But this is not portable to other operating systems.

Pawel Pabian
bbkr commented March 30, 2012

This is perl6 version 2012.03-27-g5793035 built on parrot 4.2.0 revision RELEASE_4_2_0

Spotted when working on https://github.com/bbkr/GeoIPerl6

Arne Skjærholt
Collaborator

I've run into this same issue, and I did some digging. is native("foo") boils down to dlopen("foo") in the C (dyncall) layer, and that will only look for "foo.bundle", not "libfoo.dylib", it seems. So making this work will require a workaround somewhere, probably in NQP or as a patch to dyncall.

Arne Skjærholt arnsholt closed this issue from a commit September 01, 2012
Arne Skjærholt Add test calling a function from libc.
This isn't necessary on Linux, but OS X distinguishes between shared libraries
(dylibs) and loadable modules (bundles), which we need to make sure works.
This closes #7.
20e96d5
Arne Skjærholt arnsholt closed this in 20e96d5 September 01, 2012
Pawel Pabian

Please reopen this issue, problem came back:

r$ DYLD_LIBRARY_PATH=/opt/local/lib perl6 -e 'use NativeCall; sub GeoIP_new(Int) returns OpaquePointer is native("libGeoIP") { * }; GeoIP_new(0);'
Cannot locate native library 'libGeoIP.bundle'
$ ls /opt/local/lib/libGeoIP.*
/opt/local/lib/libGeoIP.1.dylib /opt/local/lib/libGeoIP.a       /opt/local/lib/libGeoIP.dylib   /opt/local/lib/libGeoIP.la

When I force is native("libGeoIP.dylib") suffix everything works fine.

Arne Skjærholt
Collaborator

Hmm. That's not supposed to happen. I'll look into it as soon as I can.

Arne Skjærholt arnsholt reopened this February 24, 2013
Pawel Pabian

I've also noticed that $*VM = .so does not load available .so.1 on Linux, may be related to this bug.

Arne Skjærholt
Collaborator

That's a different issue (unfortunately). I haven't figured it out completely yet, but as far as I can tell, executables on Linux are actually linked with the libfoo.so.1 library, not plain libfoo. What happens is that when the executable is linked with ld -lfoo the linker resolves the library to the appropriate .so.x thing, rather than just linking directly to libfoo.so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.