Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

[TT#2107] Fix dynloading of libraries from exact file name. #144

merged 1 commit into from Aug 2, 2011


None yet
3 participants

gagern commented Aug 2, 2011

This should fix a problem introduced by 9116125 causing loadlib to fail if its argument is a full file name including extension and all, and not located in the parrot runtime directory.


@zhuomingliang zhuomingliang pushed a commit that referenced this pull request Aug 2, 2011

Jimmy Zhuo Merge pull request #144 from gagern/tt2107-dynext-get_path
[TT#2107] Fix dynloading of libraries from exact file name.

@zhuomingliang zhuomingliang merged commit 2d6e52a into parrot:master Aug 2, 2011


leto commented Aug 2, 2011

Something like this really needs a test.


gagern commented Aug 2, 2011

How would you test for this? I guess there are basically two options.

Either you'd test for a library that you expect to exist. You'd have to call it by its full SONAME. Tricky to get this in a cross-platform fashion. One way would be to ldd the parrot binary itself on *nix systems, and use some SONAME listed as needed. On WIndows you'd probably rather skip the test, or test for some common C runtime stuff or whatever. You'd also have to skip this if ldd isn't installed, unless you'd rather parse ELF binaries yourself.

Or you could create the library yourself, and place it inside some temporary subdirectory which you add to the LD_LIBRARY_PATH. At least on Linux. Not sure how to do this on other *nix systems. On Windows you'd have to add the dir to the PATH, if I remember correctly.

In either case, I don't know enough about parrot and its test framework to implement either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment