Re: Upgrading Glibc Issues?
"Steven J. Hathaway" <shathawa@e-z.net> writes:
[color=blue]
> Can I compile and install a new Glibc without breaking the
> development toolchain of compilers, assemblers, and linkers
> that are currently operational on the old system?[/color]
Maybe.
First off, upgrading glibc is not for the faint of heart: if you
screw up, the system will become unbootable, so follow instructions
very carefully, and have a bootable CD ready.
Also note that glibc comes in many pieces ('rpm -ql glibc | wc -l'
answers 320 on my system), and most of these pieces must match
*exactly*.
Second, all the existing binaries are supposed to continue to work,
but archive libraries compiled against the old libc may become
unusable. Here is one example of such breakage:
[url]http://groups.google.com/group/comp.os.linux.development.apps/browse_frm/thread/f6e454154e77340b[/url]
__ctype_b, __ctype_tolower and __ctype_toupper are the only symbols
I've seen that cause the problem, but there are many others that
could cause a problem.
You can easily tell whether any of your archive libraries have
references to the __ctype_* with 'nm -A *.a | grep __ctype_'
[color=blue]
> Or must I develop an isolated toolchain environment that
> is independent of the old system[/color]
The toolchain itself is unlikely to have any problems.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Re: Upgrading Glibc Issues?
In comp.os.linux.development.system Steven J. Hathaway <shathawa@e-z.net>:[color=blue]
> Upgrading Glibc Issues:[/color]
[color=blue]
> I have a system with an older Glibc and wish to update the
> library to a current version. I currently have a new kernel
> running with the old Glibc, but wish to take advantage of
> the new kernel features supported by a newer Glibc.[/color]
[color=blue]
> Can I compile and install a new Glibc without breaking the
> development toolchain of compilers, assemblers, and linkers
> that are currently operational on the old system?[/color]
Looking at your headers, I'd suggest to reinstall:
Mozilla 4.7 [en] (X11; I; Linux 2.2.17 i586)
Of course it isn't impossible to additional install another glibc
version. However the work needed sounds likely to be much more
then just starting over with something recent. I'd make a full
backup of your old system, reinstall and recover needed stuff
from the backup.
Good luck
[..]
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo [email]zvpunry@urvzvat.qr[/email] | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 28: CPU radiator broken
Re: Upgrading Glibc Issues?
"Steven J. Hathaway" <shathawa@e-z.net> writes:[color=blue]
> Upgrading Glibc Issues:
>
> I have a system with an older Glibc and wish to update the
> library to a current version. I currently have a new kernel
> running with the old Glibc, but wish to take advantage of
> the new kernel features supported by a newer Glibc.
>
> Can I compile and install a new Glibc without breaking the
> development toolchain of compilers, assemblers, and linkers
> that are currently operational on the old system?[/color]
Maybe, maybe not. Depending on the changes between your running libc
and the libc you want to install, some or all of your applications may
need to be recompiled or relinked. If you want to migrate the complete
system, you should first do a chrooted install of the new glibc for
safe testing without risking to have an unusable system. If you just
want to use the new libc for 'some applications' that you can
recompile, an alternative would be to install the new libc to 'some
directory' and use a spec-file for your compiler that uses the 'new'
dynamic linker and a different set of 'standard' include directories.
