Coexistence of gcc 3.2 and gcc 2.95
When g++ 3.2 becomes the next Debian compiler, it will be necessary to recompile a lot of packages. Also, it will be necessary to have the old binary packages, and their shared libraries, coexist. Is there a specific plan to implement this coexistence? I can think of the following strategies: - disallow coexistence, require that all packages are built with the system compiler, - bump the SO library version of every library. This is undesirable, since the upstream maintainer may need to bump the library version later to the same value, for a different reason. - mangle the compiler version into the soname of every library. If the latter strategy is taken, I think guidelines will be needed of how precisely this mangling should happen. It would then also be desirable to coordinate this procedure with other Linux distributions, to have executables compiled with gcc 3.2 on one distribution execute on a different distribution. Thoughts? Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Are YOU looking for a new website, to develop an existing website, for cheaper hosting or domain names?
We can help YOU to develop a new or existing website or even provide cheaper hosting and domain names. Remove instructions below. We are a UK based company who can offer YOU our considerable experience and expertise in the field of website design, eCommerce development, all types of web hosting, any domain name available and search engine positioning with excellent prices while maintaining a personal service tailored for YOU. More details at www.bbqmeat.co.uk. We can offer you cheaper solutions for YOUR website design, both new and updated sites undertaken from £100 or $150, website hosting from £60 or $90 per year, domain name registration from £10 or $15 per year, secure server space and security certificates from £50 or $75 per year, full professional after sales service, marketing tips and advice free to our clients, top ranking search engine positioning and email marketing available. We can also help you market your business in the UK and Europe. All of our websites are custom designed to meet our client's requirements and are our best advert. Please ask to see our portfolio. Our hosting services are independently tested on a daily basis and are consistently in the top of the performance listings of all the major ISP hosting companies in the UK. Most of our clients prefer to discuss their requirements by telephone, please send us a contact telephone number, together with a best time to call you and we will phone you shortly to discuss your needs in more detail. Alternatively, please ask for more details by replying to this email for a prompt response. We look forward to hearing from you. You can be assured that this email is sent in compliance with strict anti-abuse and NO SPAM regulations. Your address was collected as a result of posting to a link, a classified ad, a message to my FFA Page, you have sent me an E-mail recently, or you are on a list that I have purchased. TO REMOVE: If your email address was used without your permission or you no longer want to receive email from us, we apologise for any inconvenience caused and ask that you simply reply to this email putting REMOVE as the subject.
re: Coexistence of gcc 3.2 and gcc 2.95
Martin, I think the primary problem debian will have with gcc 3.2 (or 3.1.1 for that matter) is dealing with rebuilding glibc under it. Because the gcc 3.1 fixed a bug relating to incorrectly linking in libgcc symbols into binaries, glibc trunk and glibc-2-2-branch have fixes to address this through a new libgcc-compat file on ppc. Other arches may have handled this issue in a slightly different manner. Basically on ppc, we make sure that these libgcc symbols that were improperly linked in by gcc < 3.1 are exported from glibc now but only for resolving and not for linking. The problem I see if that it is unclear how many arches for linux have had these changes made. The basic approach is to search all the binaries on a arch for libgcc symbols and when you have the list create a libgcc-compat that provides them for resolving but not for linking. Again without this addition to glibc for every arch debian has you will get massive breakage of existing binaries when you install a gcc > 3.1 built glibc. With it, the problem is a non-issue. As I said these changes have been made in glibc-2-2-branch for ppc, but I'm unclear how many other arches have have the changes migrated back from the glibc cvs trunk into glibc-2-2-branch. Jack ps You can see the overall scheme of this from... http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/powerpc/libgcc-compat.c?rev=1.1.2.3&content-type=text/x-cvsweb-markup&cvsroot=glibc&only_with_tag=glibc-2-2-branch http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/powerpc/Versions.diff?r1=1.2&r2=1.2.2.1&cvsroot=glibc&only_with_tag=glibc-2-2-branch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#154525: g++-3.0: c++ symlink and alternatives are not created when installing
Package: g++-3.0 Version: 1:3.0.4-12 Severity: normal Alternatives for /usr/bin/c++ are not created/updated when installing g++-3.0. -- System Information: Debian Release: 3.0 Architecture: i386 Kernel: Linux lappa 2.2.20 #1 Sat Apr 20 11:45:28 EST 2002 i586 Locale: LANG=C, LC_CTYPE=C Versions of packages g++-3.0 depends on: ii gcc-3.0 1:3.0.4-12 The GNU C compiler. ii gcc-3.0-base 1:3.0.4-12 The GNU Compiler Collection (base ii libc6 2.2.5-12 GNU C Library: Shared libraries an ii libstdc++3-dev1:3.0.4-12 The GNU stdc++ library version 3 ( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Coexistence of gcc 3.2 and gcc 2.95
Jack Howarth <[EMAIL PROTECTED]> writes: >I think the primary problem debian will have with gcc 3.2 (or > 3.1.1 for that matter) is dealing with rebuilding glibc under it. > Because the gcc 3.1 fixed a bug relating to incorrectly linking in > libgcc symbols into binaries, glibc trunk and glibc-2-2-branch have > fixes to address this through a new libgcc-compat file on ppc. Jack, To comment on this issue, I feel I would need more details, like: - what symbols are you talking about? (probably ashldi3, etc, as mentioned in the patches you refer to), - what was the bug that was fixed in gcc 3.1? - why has fixing this bug in gcc 3.1 caused you to add fixes to glibc? If this is really about a few libgcc symbols only, I doubt there is any serious problem hidden in there. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
