If you were to dlopen your libs, you would solve this by passing the RTLD_LOCAL flag, right? I admit that I don't know how to do this when you don't use dlopen but directly link against the lib instead.
Cheers, Waldo Intel Corporation - Channel Platform Solutions Group - Hillsboro, Oregon >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:desktop_architects- >[EMAIL PROTECTED] On Behalf Of Mike Hearn >Sent: Monday, December 11, 2006 11:35 AM >To: [EMAIL PROTECTED] >Subject: [Desktop_architects] ELF scoping problem > >During my talk I made a throwaway reference to a design problem with >ELF that tended to whack ISVs. I just debugged the *second* instance >of this with a Google desktop Linux app in about as many weeks, and it >reminded me that I never really explained what it was. > >I used this as an example of a problem that could get fixed, but >probably won't, because the relevant people have no real incentive to >fix it. It typically only shows up when you have multiple versions of >a library loaded into the same process image, something that tends not >to happen inside a distro due to mass recompiles fixing everything to >the same version. It happens a lot more for ISVs who have to pick one >library version and go with it. > >The basic issue is this: take a symbol, call it foo_init, that is >defined as such in version 1 of the library: > >char *foo_init() { > return "zoink"; >} > >In version 2 of the library it is changed to be like this: > >char *foo_init() { > return strdup("zoink"); >} > >Clearly the ABI of this function has changed. In the first version it >is an error to free() the result, in the second version is required. >Because the libfoo author is savvy he notices this is an ABI break, >documents it, and renames the library from libfoo.so.1 to libfoo.so.2 > >Now as it happens, libfoo is used by libwidget internally. Now the >BarLinux distro wants to upgrade to the new libfoo so it patches >libwidget to use free() on the result, as is correct. Because BarLinux >updates every package to use the new version, this works. > >Now Google Whatever is released and it's compiled against libfoo.so.1, >because this version is present on both older and newer distros. It >also uses libwidget. So the link tree looks like this: > >google-whatever > - libfoo.so.1 > - libwidget.so.0 > - libfoo.so.2 > >We now have two versions of the same library loaded into memory at >once. This is perfectly sane and reasonable on, say, Windows .... but >it doesn't work on Linux. > >What happens is the foo_init() call in libwidget.so.0 is NOT linked to >the definition in libfoo.so.2 as you might expect, bu rather to >libfoo.so.1, therefore it will try and free() a string that is >statically allocated causing a crash. > >This is not the exact failure case I just debugged, but it is somewhat >similar. > >This scenario happens a lot with the C++ standard library, because it >is very widely used by many things, and because ISVs tend to use C++ a >lot more than open source projects do. > >It can be "fixed" in some cases using a variety of special case hacks >that almost nobody knows about, but clearly this situation isn't ideal >and it's not the ISVs fault - nobody can protect themselves against >this failure case. It just isn't possible. > >thanks -mike >_______________________________________________ >Desktop_architects mailing list >Desktop_architects@lists.osdl.org >https://lists.osdl.org/mailman/listinfo/desktop_architects _______________________________________________ Desktop_architects mailing list Desktop_architects@lists.osdl.org https://lists.osdl.org/mailman/listinfo/desktop_architects