Thanx Paul. The objective is to ensure that different C++ shared
objects compiled using mismatching versions of g++ (e.g. 3.x.x and
4.x.x) are not dlopen'ed by the C application because it can cause
runtime errors. We assume that the given solutions are best suited
here. Thanx.
On Jun 8, 5:41 am, Paul Pluzhnikov <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> > How can a C/C++ application which explicitly loads a C++ shared
>
> Explicitly as in dlopen(...)?
>
> > library at runtime determine the g++ version (and even libstdc++
> > version) used for the compilation of the C++ shared library on Linux?
>
> This is somewhat a hack:
>
> If you know the absolute path where the library is coming from,
> you could popen("objdump -p /path/to/dso | grep NEED") and find
> out whether it uses libstdc++.so.5 or libstdc++.so.6.
>
> You could also run 'strings' on that library, and get a very strong clue:
>
> $ strings -a foo.so | grep GNU
> GCC: (GNU) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
> GCC: (GNU) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
> ...
>
> If you don't know where the library will come from, you could
> dlopen() it, then iterate over _r_debug.r_map link chain (see
> /usr/include/link.h) to find its path.
>
> But (AFAIK) there is no "proper API" you could call to find out.
>
> Cheers,
> --
> In order to understand recursion you must first understand recursion.
> Remove /-nsp/ for email.
_______________________________________________
help-gplusplus mailing list
help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus
