Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Open
bbkr opened this Issue · 6 comments

2 participants

@bbkr
 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.

@bbkr

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

@arnsholt
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.

@arnsholt arnsholt closed this issue from a commit
@arnsholt arnsholt 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
@arnsholt arnsholt closed this in 20e96d5
@bbkr

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.

@arnsholt
Collaborator

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

@arnsholt arnsholt reopened this
@bbkr

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

@arnsholt
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.