Re: dlsym can't use handle returned by dlopen?
Markus Hoenicka writes: > Don't mean to nag, but is there any news on this? > just for the record: turns out this was a bug that got fixed in 6.3. See http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/129031 regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dlsym can't use handle returned by dlopen?
Don't mean to nag, but is there any news on this? regards, Markus Markus Hoenicka writes: > Jeremy Chadwick writes: > > As promised: http://www.malkavian.com/~jdc/myprog.tar.gz > > > > This test program indeed works as expected. However, this doesn't > quite reflect the situation in libdbi. I took your files and modified > them accordingly, see: > > http://libdbi.sourceforge.net/downloads/dlsymtest.tar.gz > > To run the test use: > > LD_LIBRARY_PATH=. ./myprog > > We need to set the environment variable to let the linker pick up a > shared object that gmake builds. > > myprog.c now just calls a function which is provided in libmylib > (built from mylib.c). The latter file does most of what your test case > did in myprog.c. The second major change is that myshared.so is linked > against libmysqlclient (just like a libdbi database driver is linked > against the client library). myfunc now calls a MySQL function to show > that it is accessible (if you don't have libmysqlclient handy, you can > replace it with whatever function from some .so is convenient) > > Finally, libmylib tries to obtain a pointer to that MySQL function by > means of a dlsym call. This new dlsym call, in contrast to the existing > one that acesses myfunc in myshared.so, indeed fails: > > myint = 0xdeadbeef (3735928559) > ==> entered myfunc() > ==> double = 3.141590 > ==>mysql client version is 50051 > ==> exiting myfunc() > dlsym() in shared lib failed: Undefined symbol > "mysql_get_client_version" > > So, to make the problem clear again: while dlsym works when accessing > symbols in dlopen()ed objects, it fails to access symbols which are > linked into such an object if you use the handle returned by > dlopen(). This is different from other OSes. > > regards, > Markus > > > -- > Markus Hoenicka > [EMAIL PROTECTED] > (Spam-protected email: replace the quadrupeds with "mhoenicka") > http://www.mhoenicka.de > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dlsym can't use handle returned by dlopen?
Jeremy Chadwick writes: > As promised: http://www.malkavian.com/~jdc/myprog.tar.gz > This test program indeed works as expected. However, this doesn't quite reflect the situation in libdbi. I took your files and modified them accordingly, see: http://libdbi.sourceforge.net/downloads/dlsymtest.tar.gz To run the test use: LD_LIBRARY_PATH=. ./myprog We need to set the environment variable to let the linker pick up a shared object that gmake builds. myprog.c now just calls a function which is provided in libmylib (built from mylib.c). The latter file does most of what your test case did in myprog.c. The second major change is that myshared.so is linked against libmysqlclient (just like a libdbi database driver is linked against the client library). myfunc now calls a MySQL function to show that it is accessible (if you don't have libmysqlclient handy, you can replace it with whatever function from some .so is convenient) Finally, libmylib tries to obtain a pointer to that MySQL function by means of a dlsym call. This new dlsym call, in contrast to the existing one that acesses myfunc in myshared.so, indeed fails: myint = 0xdeadbeef (3735928559) ==> entered myfunc() ==> double = 3.141590 ==>mysql client version is 50051 ==> exiting myfunc() dlsym() in shared lib failed: Undefined symbol "mysql_get_client_version" So, to make the problem clear again: while dlsym works when accessing symbols in dlopen()ed objects, it fails to access symbols which are linked into such an object if you use the handle returned by dlopen(). This is different from other OSes. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dlsym can't use handle returned by dlopen?
Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: As promised: http://www.malkavian.com/~jdc/myprog.tar.gz I couldn't figure out what the gcc flag was that I needed to keep certain characters from getting prepended to the symbol names. I believe the char added was an underscore, but I could be wrong. Either way, the example should help you, I think. (You can change RTLD_LAZY to RTLD_NOW and it still functions as expected) Thanks a lot, I'll have a look at it when I get home tonight. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dlsym can't use handle returned by dlopen?
On Thu, Nov 13, 2008 at 12:24:02AM -0800, Jeremy Chadwick wrote: > On Thu, Nov 13, 2008 at 09:20:59AM +0100, Markus Hoenicka wrote: > > Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: > > > >> When I looked at the resulting symbol names using nm or objdump, certain > >> characters were prepended to them. There's a gcc or ld flag which > >> disables this behaviour. I'll have to dig around to remind myself what > >> it is. Once I read about it, it made perfect sense. > >> > >> Again, if you want me to write some code and provide some output of > >> what I'm talking about, I can do so. > >> > > > > I'd greatly appreciate any help here. I feel what I'm doing now is > > writing ugly hacks to make things work somehow. I'd prefer to do it > > properly. > > No problem. I'll try to get something small/simple written up tonight > (I'm at work right now) and send it out. As promised: http://www.malkavian.com/~jdc/myprog.tar.gz I couldn't figure out what the gcc flag was that I needed to keep certain characters from getting prepended to the symbol names. I believe the char added was an underscore, but I could be wrong. Either way, the example should help you, I think. (You can change RTLD_LAZY to RTLD_NOW and it still functions as expected) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dlsym can't use handle returned by dlopen?
On Thu, Nov 13, 2008 at 09:20:59AM +0100, Markus Hoenicka wrote: > Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: > >> When I looked at the resulting symbol names using nm or objdump, certain >> characters were prepended to them. There's a gcc or ld flag which >> disables this behaviour. I'll have to dig around to remind myself what >> it is. Once I read about it, it made perfect sense. >> >> Again, if you want me to write some code and provide some output of >> what I'm talking about, I can do so. >> > > I'd greatly appreciate any help here. I feel what I'm doing now is > writing ugly hacks to make things work somehow. I'd prefer to do it > properly. No problem. I'll try to get something small/simple written up tonight (I'm at work right now) and send it out. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dlsym can't use handle returned by dlopen?
Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: I know that the .so's you're loading with dlopen() need to be built a specific way/with certain arguments, otherwise they won't work (I believe what I saw was dlsym() returning NULL). My symbol names were getting stomped on, and there was a compiler flag that addressed that. Is that a BSD-specific problem? As mentioned previously, I don't run into trouble on other platforms. Is there any documentation available which tells me how to build a dlopen()'able object in a portable way? function_pointer = dlsym(RTLD_DEFAULT, "function_name"); Why is that? Or rather: what am I doing wrong? This code right here is *completely* wrong. RTLD_DEFAULT is a mode bit for dlopen(). I'm willing to bet a strict set of warnings would Citing the FreeBSD dlsym(3) man page: "If dlsym is called with the special handle RTLD_DEFAULT, the search for the symbol follows the algorithm used for resolving undefined symbols when objects are loaded." You probably had RTLD_LAZY and RTLD_NOW in mind which are dlopen() flags. BTW RTLD_NEXT works just as well instead of RTLD_DEFAULT. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dlsym can't use handle returned by dlopen?
Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: When I looked at the resulting symbol names using nm or objdump, certain characters were prepended to them. There's a gcc or ld flag which disables this behaviour. I'll have to dig around to remind myself what it is. Once I read about it, it made perfect sense. Again, if you want me to write some code and provide some output of what I'm talking about, I can do so. I'd greatly appreciate any help here. I feel what I'm doing now is writing ugly hacks to make things work somehow. I'd prefer to do it properly. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dlsym can't use handle returned by dlopen?
On Thu, Nov 13, 2008 at 09:00:21AM +0100, Markus Hoenicka wrote: > Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: > >> I know that the .so's you're loading with dlopen() need to be built a >> specific way/with certain arguments, otherwise they won't work (I >> believe what I saw was dlsym() returning NULL). My symbol names were >> getting stomped on, and there was a compiler flag that addressed that. > > Is that a BSD-specific problem? As mentioned previously, I don't run > into trouble on other platforms. Is there any documentation available > which tells me how to build a dlopen()'able object in a portable way? I wouldn't classify is as a problem in any way, and I cannot imagine it's specific to BSD; I'm much more inclined to believe it's specific to gcc. When I looked at the resulting symbol names using nm or objdump, certain characters were prepended to them. There's a gcc or ld flag which disables this behaviour. I'll have to dig around to remind myself what it is. Once I read about it, it made perfect sense. Again, if you want me to write some code and provide some output of what I'm talking about, I can do so. >>> function_pointer = dlsym(RTLD_DEFAULT, "function_name"); >>> >>> Why is that? Or rather: what am I doing wrong? >> >> This code right here is *completely* wrong. RTLD_DEFAULT is a mode bit >> for dlopen(). I'm willing to bet a strict set of warnings would > > Citing the FreeBSD dlsym(3) man page: > > "If dlsym is called with the special handle RTLD_DEFAULT, the search > for the symbol follows the algorithm used for resolving undefined symbols > when objects are loaded." > > You probably had RTLD_LAZY and RTLD_NOW in mind which are dlopen() > flags. BTW RTLD_NEXT works just as well instead of RTLD_DEFAULT. You are right -- I missed that part of the man page, and I was most definitely thinking of RTLD_LAZY and RTLD_NOW. I cannot explain the behaviour using dlsym(RTLD_DEFAULT, ...). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dlsym can't use handle returned by dlopen?
On Thu, Nov 13, 2008 at 12:59:27AM +0100, Markus Hoenicka wrote: > FreeBSD yeti.mininet 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Mon Aug 28 22:24:48 > CEST 2006 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/YETI i386 > > I'm trying to do the following: libdbi (http://libdbi.sourceforge.net) > is a database abstraction layer which is linked as a shared object > into applications. The libdbi library uses dlopen() to load database > drivers which in turn are linked against database client > libraries. Now I want to access functions defined in the database > client library from within the libdbi library. In brief, I thought > this is going to work like this: > > dlhandle = dlopen("path", RTLD_NOW); > ... > function_pointer = dlsym(dlhandle, "function_name"); > > dlhandle is not NULL and does not crash the app when passed to > dlclose(), so I assume the handle is valid. Accessing the functions > does work on most systems (Linux, OSX, Cygwin, to name a few), but I > get "Undefined symbol" errors on FreeBSD. Interestingly, the following > does work: I've personally used dlopen() and dlsym(), and they do work as documented (my original goal with bsdhwmon was to keep each chip in a separate .so. It worked, but added complexities of the program nature itself kept me from using it at the time). I tested this on both i386 and amd64. I know that the .so's you're loading with dlopen() need to be built a specific way/with certain arguments, otherwise they won't work (I believe what I saw was dlsym() returning NULL). My symbol names were getting stomped on, and there was a compiler flag that addressed that. I can go back and write code that does all of this if you'd like, but my point is that they do work. > function_pointer = dlsym(RTLD_DEFAULT, "function_name"); > > Why is that? Or rather: what am I doing wrong? This code right here is *completely* wrong. RTLD_DEFAULT is a mode bit for dlopen(). I'm willing to bet a strict set of warnings would catch this. Try building your application with: -g3 -ggdb -Werror -Wall -Wunused -Waggregate-return -Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wdisabled-optimization -Wfloat-equal -Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpacked -Wpointer-arith -Wredundant-decls -Wsign-compare -Wstrict-prototypes -Wunreachable-code -Wwrite-strings And see what appears. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dlsym can't use handle returned by dlopen?
Hi, FreeBSD yeti.mininet 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Mon Aug 28 22:24:48 CEST 2006 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/YETI i386 I'm trying to do the following: libdbi (http://libdbi.sourceforge.net) is a database abstraction layer which is linked as a shared object into applications. The libdbi library uses dlopen() to load database drivers which in turn are linked against database client libraries. Now I want to access functions defined in the database client library from within the libdbi library. In brief, I thought this is going to work like this: dlhandle = dlopen("path", RTLD_NOW); ... function_pointer = dlsym(dlhandle, "function_name"); dlhandle is not NULL and does not crash the app when passed to dlclose(), so I assume the handle is valid. Accessing the functions does work on most systems (Linux, OSX, Cygwin, to name a few), but I get "Undefined symbol" errors on FreeBSD. Interestingly, the following does work: function_pointer = dlsym(RTLD_DEFAULT, "function_name"); Why is that? Or rather: what am I doing wrong? Any help is appreciated. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"