Date: Wed, 12 Nov 2008 20:29:12 -0800 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: Markus Hoenicka <markus.hoenicka@mhoenicka.de> Cc: freebsd-questions@freebsd.org Subject: Re: dlsym can't use handle returned by dlopen? Message-ID: <20081113042912.GA10018@icarus.home.lan> In-Reply-To: <18715.28127.306511.577084@yeti.mininet> References: <18715.28127.306511.577084@yeti.mininet>
next in thread | previous in thread | raw e-mail | index | archive | help
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 markus@yeti.mininet:/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 Chadwick jdc 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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081113042912.GA10018>