Date: Sat, 13 Feb 1999 00:31:18 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: erich@lodgenet.com (Eric L. Hernes) Cc: hackers@FreeBSD.ORG, erich@lodgenet.com Subject: Re: dlopen and ELF v. a.out Message-ID: <199902130031.RAA29859@usr01.primenet.com> In-Reply-To: <199902121628.KAA29685@jake.lodgenet.com> from "Eric L. Hernes" at Feb 12, 99 10:28:33 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I've been looking at x11amp, and I've run into a bit of a problem.
> The program is set up as a program and a few shared-library plug-ins.
> The shared libs all have some common symbol names in global scope,
> (obviously) to provide an interface between the program and the plugin.
>
> What happens, though is that the plug-ins aren't very well encapsulated,
> so there's big time global symbol polution. If the plug-ins were contained
> in one .c module, I could just declare the offending symbols as static,
> and all would be fine. But the plug-ins are often aggregates where
> some symbols need to be seen from different c-sources.
>
> So is there any way to get the linker to export only specific symbols,
> and hide the rest (and resolve them internally to the lib)?
Use ld -r to make a single object per module.
See also -x and -X, if you are willing to edit symbol names.
You may also look at -s, in combination with either -defsym or --wrap,
though I'm not sure about precedence.
You could also modify your test program:
> Attached is a test prog that illustrates the problem. There is two
[ ... ]
> for(i=0;i<3;i++) {
> asprintf(&pn, "%s/test%d.so", cwd, i);
> h = dlopen(pn, RTLD_NOW);
> if (h) {
> fp = dlsym(h, "testFunction");
> if (fp){
> fprintf(stderr, "got fp at %p\n", fp);
> m = fp();
> fprintf(stderr, "message: %s\n", m);
> }
> } else {
> warn("%s: dlopen failed", pn);
> }
> free(pn);
dlclose( h);
> }
This is probably not an option for you, I'm betting, if the code is
that promiscuous.
The resoloution order is not specific; a.out's dlopen (apparently) puts
newer symbols first, so FreeBSD's behaviour in that case is not really
incorrect.
One final alternative would be to correct the namespace pollution,
and submit the changes back.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902130031.RAA29859>