Is there an API that is equivalent to Win32’s GetModuleFileName(). I
need to know the path of where the DLL is loading from at runtime.
Appreciate any help.
I have posted this question on qnx.public.qnxrtp.porting, no one seems
to know. Sorry, I have to re-post it here, hope I could get some help.
-Beth
This information isn’t stored, only the basename of the libs that have
been loaded.
Sorry, the best way to do it for now is to search the LD_LIBRARY_PATH
yourself.
To be safe, you could do that before you open the dll, then call
dlopen with the fully qualified pathname.
Beth <id@address.com> wrote:
Is there an API that is equivalent to Win32’s GetModuleFileName(). I
need to know the path of where the DLL is loading from at runtime.Appreciate any help.
I have posted this question on qnx.public.qnxrtp.porting, no one seems
to know. Sorry, I have to re-post it here, hope I could get some help.-Beth
Colin, thanks for your response.
I have this library file libfs.so that is linked by libsw.so at compile
time. Both libraries are installed in the
/fi/lib directory.
The executable program ‘swcore’, that is under /fi/bin, calls dlopen() of
libsw.so when it starts.
At the init time of the libfs.so library, it calls fopen(“libfs.so”, rb).
Since fopen() only looks at
the directory of where swcore process is running of , fopen() would fail.
Do you have any suggestion as to how I can get around with this problem?
Appreciate your help.
-Beth
Colin Burgess wrote:
This information isn’t stored, only the basename of the libs that have
been loaded.Sorry, the best way to do it for now is to search the LD_LIBRARY_PATH
yourself.To be safe, you could do that before you open the dll, then call
dlopen with the fully qualified pathname.Beth <> id@address.com> > wrote:
Is there an API that is equivalent to Win32’s GetModuleFileName(). I
need to know the path of where the DLL is loading from at runtime.Appreciate any help.
I have posted this question on qnx.public.qnxrtp.porting, no one seems
to know. Sorry, I have to re-post it here, hope I could get some help.-Beth
Really, if you need to know exactly where you were loaded from, I’d
do something like this…
#include <errno.h>
#include <dlfcn.h>
#include <libgen.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
void *my_dlopen( const char *name, int mode, char *path )
{
char *libpath, *tmppath;
libpath = getenv( “LD_LIBRARY_PATH” );
if ( libpath == NULL ) {
len = confstr( _CS_LIBPATH, NULL, 0 );
if ( len > 0 ) {
libpath = malloc( len + 1 );
confstr( _CS_LIBPATH, libpath, len );
}
}
tmppath = pathfind( libpath?:"", name, “rx” );
if ( tmppath == NULL )
return errno = ESRCH, NULL;
if ( path )
strcpy( path, tmppath, strlen(tmppath) );
return dlopen( tmppath, mode );
}
Beth <id@address.com> wrote:
Colin, thanks for your response.
I have this library file libfs.so that is linked by libsw.so at compile
time. Both libraries are installed in the
/fi/lib directory.
The executable program ‘swcore’, that is under /fi/bin, calls dlopen() of
libsw.so when it starts.
At the init time of the libfs.so library, it calls fopen(“libfs.so”, rb).
Since fopen() only looks at
the directory of where swcore process is running of , fopen() would fail.Do you have any suggestion as to how I can get around with this problem?
Appreciate your help.
-Beth
Colin Burgess wrote:
This information isn’t stored, only the basename of the libs that have
been loaded.Sorry, the best way to do it for now is to search the LD_LIBRARY_PATH
yourself.To be safe, you could do that before you open the dll, then call
dlopen with the fully qualified pathname.Beth <> id@address.com> > wrote:
Is there an API that is equivalent to Win32’s GetModuleFileName(). I
need to know the path of where the DLL is loading from at runtime.Appreciate any help.
I have posted this question on qnx.public.qnxrtp.porting, no one seems
to know. Sorry, I have to re-post it here, hope I could get some help.-Beth
Colin, thanks for your help.
The problem I have was not dlopen(), it was fopen() that can not find the
library file libfs.so at init time.
Since my libfs.so file is linked at the compile time to libsw.so, it is not
loaded by calling dlopen(),
I don’t know how you would find the path for libfs.so at runtime.
-Beth
Colin Burgess wrote:
Really, if you need to know exactly where you were loaded from, I’d
do something like this…#include <errno.h
#include <dlfcn.h
#include <libgen.h
#include <stdio.h
#include <stdlib.h
#include <unistd.hvoid *my_dlopen( const char *name, int mode, char *path )
{
char *libpath, *tmppath;
libpath = getenv( “LD_LIBRARY_PATH” );
if ( libpath == NULL ) {
len = confstr( _CS_LIBPATH, NULL, 0 );
if ( len > 0 ) {
libpath = malloc( len + 1 );
confstr( _CS_LIBPATH, libpath, len );
}
}
tmppath = pathfind( libpath?:"", name, “rx” );
if ( tmppath == NULL )
return errno = ESRCH, NULL;if ( path )
strcpy( path, tmppath, strlen(tmppath) );
return dlopen( tmppath, mode );
}Beth <> id@address.com> > wrote:
Colin, thanks for your response.I have this library file libfs.so that is linked by libsw.so at compile
time. Both libraries are installed in the
/fi/lib directory.
The executable program ‘swcore’, that is under /fi/bin, calls dlopen() of
libsw.so when it starts.
At the init time of the libfs.so library, it calls fopen(“libfs.so”, rb).
Since fopen() only looks at
the directory of where swcore process is running of , fopen() would fail.Do you have any suggestion as to how I can get around with this problem?
Appreciate your help.
-Beth
Colin Burgess wrote:
This information isn’t stored, only the basename of the libs that have
been loaded.Sorry, the best way to do it for now is to search the LD_LIBRARY_PATH
yourself.To be safe, you could do that before you open the dll, then call
dlopen with the fully qualified pathname.Beth <> id@address.com> > wrote:
Is there an API that is equivalent to Win32’s GetModuleFileName(). I
need to know the path of where the DLL is loading from at runtime.Appreciate any help.
I have posted this question on qnx.public.qnxrtp.porting, no one seems
to know. Sorry, I have to re-post it here, hope I could get some help.-Beth
Beth wrote:
Colin, thanks for your help.
The problem I have was not dlopen(), it was fopen() that can not find the
library file libfs.so at init time.
Since my libfs.so file is linked at the compile time to libsw.so, it is not
loaded by calling dlopen(),
I don’t know how you would find the path for libfs.so at runtime.
OK, I’ll bite…
…how about this (in a stunning example of newsgroup code re-use -
otherwise known as thinly disguised cut & paste 
void *my_fopen(const char *name, const char *mode, char *path)
{
char *libpath, *tmppath;
libpath = getenv( “LD_LIBRARY_PATH” );
if ( libpath == NULL ) {
len = confstr( _CS_LIBPATH, NULL, 0 );
if ( len > 0 ) {
libpath = malloc( len + 1 );
confstr( _CS_LIBPATH, libpath, len );
}
}
tmppath = pathfind( libpath?:"", name, “rx” );
if ( tmppath == NULL )
return errno = ESRCH, NULL;
if ( path )
strcpy( path, tmppath, strlen(tmppath) );
return fopen( tmppath, mode );
}
silly question; why fopen() the library ?
Hi Rennie, thank you so much. It works !!
At the init time of loading this library, we do fopen() to check
the signature of the lib file.
Really appreciate your help!
-Beth
Rennie Allen wrote:
Beth wrote:
Colin, thanks for your help.
The problem I have was not dlopen(), it was fopen() that can not find the
library file libfs.so at init time.
Since my libfs.so file is linked at the compile time to libsw.so, it is not
loaded by calling dlopen(),
I don’t know how you would find the path for libfs.so at runtime.OK, I’ll bite…
…how about this (in a stunning example of newsgroup code re-use -
otherwise known as thinly disguised cut & paste >void *my_fopen(const char *name, const char *mode, char *path)
{
char *libpath, *tmppath;
libpath = getenv( “LD_LIBRARY_PATH” );if ( libpath == NULL ) {
len = confstr( _CS_LIBPATH, NULL, 0 );
if ( len > 0 ) {
libpath = malloc( len + 1 );
confstr( _CS_LIBPATH, libpath, len );
}
}tmppath = pathfind( libpath?:"", name, “rx” );
if ( tmppath == NULL )
return errno = ESRCH, NULL;if ( path )
strcpy( path, tmppath, strlen(tmppath) );return fopen( tmppath, mode );
}silly question; why fopen() the library ?
Beth wrote:
Hi Rennie, thank you so much. It works !!
At the init time of loading this library, we do fopen() to check
the signature of the lib file.Really appreciate your help!
As I alluded to in my post, the credit goes to Colin. Essentially, all I
did was re-name my_dlopen to my_fopen (the code fragment was intended only
as a gentle, hopefully illuminating, nudge in the direction of the already
supplied solution