Upgrading Glibc Issues? - Linux

This is a discussion on Upgrading Glibc Issues? - Linux ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Upgrading Glibc Issues?

  1. Upgrading Glibc Issues?

    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?

    Or must I develop an isolated toolchain environment that
    is independent of the old system so that operations will
    not fatally break during the Glibc upgrade? Ref: Linux From
    Scratch project.

    - Steve Hathaway




  2. Re: Upgrading Glibc Issues?

    "Steven J. Hathaway" writes:

    > 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?


    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:

    http://groups.google.com/group/comp....e454154e77340b

    __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_'

    > Or must I develop an isolated toolchain environment that
    > is independent of the old system


    The toolchain itself is unlikely to have any problems.

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  3. Re: Upgrading Glibc Issues?

    In comp.os.linux.development.system Steven J. Hathaway :
    > 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?


    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 zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
    #bofh excuse 28: CPU radiator broken

  4. Re: Upgrading Glibc Issues?

    "Steven J. Hathaway" writes:
    > 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?


    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.

+ Reply to Thread