Re: Status of debian-installer on PPC64
Martin Michlmayr - Debian Project Leader writes: > This is a mail about a possible PPC64 port and how to get started; I > removed some parts, and only include what is relevant to -gcc (the > full message can be found on the -powerpc list). > > * Anton Blanchard <[EMAIL PROTECTED]> [2004-03-03 23:21]: > > An overview of the current status: > > > > - 64bit 2.6 (straight from Linus) should compile and boot on G5, pseries > [...] > > > > - binutils works with 64bit, in fact the current 32bit binutils in > > debian has 64bit support enabled (I requested that a while ago). > > > > - gcc-3.3 requires patches. This is the sticking point at the moment. > > The current repository for this is the SUSE 3.3 hammer branch, it > > includes all the required 64bit support as well. Does debian have a > > x86-64 toolchain? If so its probably the hammer branch and we can > > share with those packages. If not we can handle it a number of ways > > (eg patch against 3.3 mainline). the amd64 port currently uses the 3.3 package, with biarch support enabled. scanning the postings on debian-adm64 it seems to work. > > - My understanding is gcc-3.4 will have all the necessary patches. my understanding as well. 3.4 probably will be released in March. > > - glibc works with 64bit > > > > On a related topic, 32bit ppc currently has no NPTL libc build because > > some of the changes did not make it into gcc-3.3. Again the gcc-3.3 > > hammer branch or gcc-3.4 have the bits. I can understand the guys not > > wanting to upset too much before the next release but we need to get > > NPTL support in or we will be behind x64, x86-64, s390 and ia64. The > > suggestion was to do some experimental gcc-3.3-hammer + libc6-nptl > > packages. Maybe this could tie in with our ppc64 toolchains. hmm, thought that was the gcc-3_3-rhl branch? > Can we get those patches into GCC 3.3 or are those changes too > intrusive? from my understanding the NPTL support is only one difference in the various 3.3 branches. If you can sort out this part ... > What is the status of GCC 3.4, and are those patches in > our gcc-snapshot package? gcc-snapshot has nearly no additional patches applied to be able to track the upstream status. you can find experimental gcc-3.4 packages stuck in the NEW queue (and on http://people.debian.org/~doko/gcc-3.4). Do you want to have gcc-3.4 for sarge? Cons: - New libstdc++, so you probably do no want to mix C++ code compiled with 3.3 and 3.4. - The library package libgcc on all architectures but hppa and m68k is built by 3.4 instead of 3.3. Checked on i386, works ok as a replacement for the one currently built from the 3.3 sources. Needs to be checked for other architectures. On m68k and hppa the exception model changed from sjlj based exceptions to dwarf2 based exceptions (therefore libgcc2 is built). Both cannot be mixed. - The library packages libobjc1, libg2c0 and libffi2 are built by 3.4 instead of 3.3. The ObjC, Fortran77 and Java compilers could be disabled. Disabling the protoize, fixincludes and fastjar packages is not a problem. - Not yet fixed library ABIs, so these may change until the final 3.4 release. - Base packages will be frozen soon. Pros: - see your arguments above - gij/gcj for all architectures (new for mips/mipsel, improved for at least hppa).
Bug#186922: [Bug java/10581] ICE compiling freenet
--- Additional Comments From ruben at ugr dot es 2004-03-04 15:22 --- (In reply to comment #2) Full message of gcj 3.3.3 gcj -c RequestManager.java RequestManager.java:459: internal compiler error: in expand_expr, at expr.c:7350 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10581 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
Help tracking down fPIC optimization bug in g77 3.3
Hi all, I found a bug (?) in g77 3.3's optimization of PIC code (at least on i386), leading to bug # 233689 (closed by the workaround of compiling the affected file without optimization). The problem is that a segfault occurs with code which is called from a dynamic library that doesn't happen when the code is linked in statically. I believe part of the issue is that the FORTRAN function in question: http://borex.princeton.edu/~kmccarty/g77-bug/csrfun.F has multiple entry points. However I haven't been able to construct a simple test case for the bug (which is why I haven't filed anything in the BTS), so assistance is greatly appreciated. How you can help: - Install (with apt-get) the package "paw" on i386/unstable, then obtain and install (with dpkg -i) the three debs in this directory, which are compiled optimized but not stripped: http://borex.princeton.edu/~kmccarty/g77-bug/ - Download this file: http://borex.princeton.edu/~kmccarty/g77-bug/ttt.kumac to some appropriate test directory and cd to that directory. - The bug can be triggered by running pawX11.dynamic (in the "paw" package) and, at the PAW> prompt, typing "exec ttt" (without the quotes). It cannot be triggered from pawX11.static (in the "paw-static" package). Presumably gdb/assembly gurus will be able to figure out what's wrong by looking at the assembly window in the former case... - Source code for the file is also in the above directory, as well as the results of 'g77 -save-temps ...' compiled in the appropriate ways. - Source code for the rest of cernlib (of which paw is a part) can be obtained with apt-get source paw; cd cernlib-* ; make -f debian/generic/Makefile patch - Here is my test framework (which as mentioned above, does not actually illustrate the bug in its current condition, but maybe someone can modify it so that it does): http://borex.princeton.edu/~kmccarty/g77-bug/g77-test.tar.gz Thanks for any light anyone can shed on this. The only other things I can add are that the bug doesn't happen with g77-2.95, and that the compilation options are as follows: - for the statically linked file, g77 -save-temps -g -c -O3 -fno-strength-reduce -funroll-loops -fomit-frame-pointer -fno-automatic -fno-second-underscore -fugly-complex -I/home/kmccarty/Downloads/programs/src/cernlib/cernlib-2003.09.03/build/pawlib/comis -I/home/kmccarty/Downloads/programs/src/cernlib/cernlib-2003.09.03/src/pawlib/comis -I/home/kmccarty/Downloads/programs/src/cernlib/cernlib-2003.09.03/src/pawlib/comis/code -I/home/kmccarty/Downloads/programs/src/cernlib/cernlib-2003.09.03/src/include -DCERNLIB_LINUX -DCERNLIB_UNIX -DCERNLIB_LNX -DCERNLIB_QMGLIBC -DCERNLIB_DEBIAN -DDEBIAN_VERSION=\"2003.09.03-3\" -o archive/csrfun.o /home/kmccarty/Downloads/programs/src/cernlib/cernlib-2003.09.03/src/pawlib/comis/code/csrfun.F - for the file compiled with -fPIC, g77 -save-temps -g -c -O3 -fno-strength-reduce -funroll-loops -fomit-frame-pointer -fPIC -fno-automatic -fno-second-underscore -fugly-complex -I/home/kmccarty/Downloads/programs/src/cernlib/cernlib-2003.09.03/build/pawlib/comis -I/home/kmccarty/Downloads/programs/src/cernlib/cernlib-2003.09.03/src/pawlib/comis -I/home/kmccarty/Downloads/programs/src/cernlib/cernlib-2003.09.03/src/pawlib/comis/code -I/home/kmccarty/Downloads/programs/src/cernlib/cernlib-2003.09.03/src/include -DCERNLIB_LINUX -DCERNLIB_UNIX -DCERNLIB_LNX -DCERNLIB_QMGLIBC -DCERNLIB_DEBIAN -DDEBIAN_VERSION=\"2003.09.03-3\" -o shared/csrfun.o /home/kmccarty/Downloads/programs/src/cernlib/cernlib-2003.09.03/src/pawlib/comis/code/csrfun.F - for the shared library libpaw1.so, gcc -shared -Wl,-soname=libpawlib.so.1 -o libpawlib.so.1.2003 \ `cat shared/objects.list` `cernlib -v "" -dy pawlib | sed s/-lpawlib//g` regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544
