Chris Staub wrote: > mike wrote: >> hi all, >> >> i have a good working x86_64 multilib and i try to compile the new >> blueZ package but it fails with an error. >> >>> device.o: In function `disconnect': >>> device.c:(.text+0x1847): undefined reference to `g_timeout_add_seconds' >>> collect2: ld returned 1 exit status >> >> the blueZ-mailinglist help with the hint to my glibc. >> ok, i use /lib[64]/ld-2.5. my question is: can i simply install a new >> glibc beside the version 2.5? and how can i change the linker to use >> then the new library instead the old...? >> >> for understanding: >> all installed apps use my ld-2.5 so it must be leave on the hard >> disk. and after installing the new glibc all new apps use this new >> library, right? >> > Nope. The dynamic linker is hard-wired into every program. To use a > new Glibc, you must rebuild every package. In other words, if you want > to upgrade Glibc, you're better off just rebuilding your entire system. I've seen cases where installing a new version of glibc causes basically all apps to fail to execute properly. Granted it's rare, but it's always a possibility. You would want to re-compile everything against glibc again. Just as a precaution. > > I do know that I've seen some users mention that you could do a minor > upgrade (like Glibc 2.5 ---> 2.5.1) - as something like that is just > generally just bugfixes it would likely work. However, anything more > than that (Glibc 2.5 ---> 2.6 for example) is taking a huge risk. Agreed, After doing a update like that your best bet would be to recompile every package that was compiled against Glib. It sucks, but it's the way it has to be.
_______________________________________________ Clfs-support mailing list [email protected] http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
