Issue 88845 - testshl2 doesn't load library from given path
Summary: testshl2 doesn't load library from given path
Status: CLOSED FIXED
Alias: None
Product: Build Tools
Classification: Code
Component: code (show other issues)
Version: current
Hardware: All Mac OS X, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: lars.langhans
QA Contact: issues@tools
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-29 13:06 UTC by hjs
Modified: 2013-08-07 15:34 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description hjs 2008-04-29 13:06:40 UTC
when calling testshl2 with a relative path to the library to check (e.g.
"testshl2 ../unxmacxi/lib/libtests..dylib") it seems to prefer the library found
in solver with the same name.
there is a workaround to add the local directory to the DYLD_LIBRARY_PATH variable.
but no, that's no fix. if testshl2 is given a path, it should use it.
Comment 1 lars.langhans 2008-04-30 12:09:02 UTC
Please start the test again with parameter -verbose

testshl2 -verbose ../unxmacxi/lib/libtests..dylib

This will show you, which "absolute" path is taken. If the Path is wrong then,
this could be a problem in sal module.

The relative path '../unxmacxi/lib/libtests..dylib' is _suSysPath and I'm doing
the follows:

// takes the current absolute path
rtl::OUString curDirPth;
osl_getProcessWorkingDir( &curDirPth.pData );

// add the current path and the relative path together, removes the '..' and
convert the path to a file url.
osl::FileBase::getAbsoluteFileURL( curDirPth, _suSysPath, fURL );
Comment 2 lars.langhans 2008-04-30 14:54:16 UTC
Hmmm...
testshl2 use module.c (load() function to load dynamic libraries.)

Please have a look into this URL.
http://developer.apple.com/documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html#//apple_ref/c/func/dlopen

As you can read, the given library name to testshl2 is a 'pathname' due to the
fact it contains '/' so first is looked into DYLD_LIBRARY_PATH and if the
library is found by this path it will be taken. You have to change the
DYLD_LIBRARY_PATH first. BTW: I couldn't change this variable this way for me in
my env (with set DYLD_LIBRARY_PATH=...) maybe this is one of the 'security'
features of macos.

Therefore I will check if a 'simple fix' like the follows will help here.
1. Get the absolute path of the library
2. change to the absolute path by chdir()
3. remove any '/' from the library name
4. dlopen the library by sal::Module::load()
5. chdir back to the old path
6. run the rest.
Comment 3 eric.bachard 2008-05-06 13:39:22 UTC
Interesting :)
Comment 4 lars.langhans 2008-05-06 13:59:34 UTC
fixed as described above.
Comment 5 hjs 2008-05-06 15:53:30 UTC
works for me now
Comment 6 hjs 2008-05-06 16:57:43 UTC
mac is fine now but linux is broken. now testshl2 on linux fetches the library
from solver instead of the given path...
Comment 7 lars.langhans 2008-05-07 12:30:15 UTC
fixed.

I have redesigned the load library, now:
Linux, Solaris & Windows will load the test libraries with absolute path
(relative path will convert to absolute path) BTW: Linux and Windows will fail
with local path, Solaris work right with both.

MacOSX will load the test libraries with local path (chdir() to the path, then
load without any path) MacOSX will fail with absolute path.

Other OS are unknown(FreeBSD, NetBSD, AIX, OS/2)  the default behaviour is here
to load with absolute path, as before.

As second there exists 2 more parameters like
-localpath to force testshl2 to load a library by chdir() to the given path then
load the library without path.
-absolutepath to force testshl2 to load a library with absolute path.

As third, there exists a simple selftest in 'workben/selftest' directory. To run
the test, call dmake, to build the test libraries, call deliver, to copy a test
library into the solver directory, call dmake test to run the test. More you can
find in the README.txt in this directory also.

HTH
Comment 8 hjs 2008-05-14 15:42:19 UTC
.
Comment 9 jens-heiner.rechtien 2008-05-26 16:14:52 UTC
verified
Comment 10 lars.langhans 2008-09-22 12:43:30 UTC
integrated, will be closed.