Re: dlsym can't use handle returned by dlopen?

2008-11-29 Thread Markus Hoenicka
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?

2008-11-17 Thread Markus Hoenicka
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?

2008-11-14 Thread Markus Hoenicka
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?

2008-11-13 Thread Jeremy Chadwick
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?

2008-11-13 Thread Markus Hoenicka

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?

2008-11-13 Thread Markus Hoenicka

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?

2008-11-13 Thread Jeremy Chadwick
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?

2008-11-13 Thread Jeremy Chadwick
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?

2008-11-13 Thread Markus Hoenicka

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]


dlsym can't use handle returned by dlopen?

2008-11-12 Thread Markus Hoenicka
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]


Re: dlsym can't use handle returned by dlopen?

2008-11-12 Thread Jeremy Chadwick
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]