On Aug 29, 1:32 am, yod...@gmail.com wrote:
> Would like some help if possible...I'm trying to use dlopen et al to
> reload a library from disk. If the library is untouched, the reload
> works fine. But if I overwrite the library with a new copy, I get a
> segmentation fault in do_lookup_x when executing dlsym.
> It would seem that overwriting libraries on disk with updated an
> updated version (in run time) is a pretty common use case...is it
> possible??

I'm not certain, but I would think so. Can you post a compilable
example that shows the problem?

yoddeb@gmail.com writes:
>Would like some help if possible...I'm trying to use dlopen et al to
>reload a library from disk. If the library is untouched, the reload
>works fine. But if I overwrite the library with a new copy, I get a
>segmentation fault in do_lookup_x when executing dlsym.
>It would seem that overwriting libraries on disk with updated an
>updated version (in run time) is a pretty common use case...is it
>possible??
>TIA

If you overwrite a library you _already are using_, then you'll get
strange results as text pages from the new copy get intermingled with
text pages form the old copy in your address space regardless of using
dlopen(3) or not. (The text pages get intermingled because the kernel
doesn't swap text pages, but rather just reloads them from the underlying
library object upon demand. Eventually, you're guaranteed to get a
fault of some sort as the two code bases intermingle).

dlopen(3) won't replace an existing library that's already loaded into
the process address space.

Note from the dlopen man page on fedora 6:

If the same library is loaded again with dlopen(), the same file handle
is returned.

You may be able to dlclose() the original and dlopen() the new, but that
won't work if the original was linked with the executable.

scott