inconsistency in location of static and shared libraries on sparc64-sun-solaris*
I've just built gcc with sparc64 as build target (64-bit gcc binary that generates 64-bit code by default, much like Linux amd64 does). I've noticed one inconsistency how libraries are installed. For shared libraries (lib*.so), the 32-bit version is installed in prefix/lib, while 64-bit version is installed in prefix/lib/sparcv9. For static libraries (lib*.a archives), it is the other way around. The 64-bit version is installed in prefix/lib, while 32-bit version is installed in prefix/lib/sparcv7!? Just wondering if this was by design, and/or if there was some good reason for this? Looking at the system libraries (/lib, /usr/lib), the lib/lib*.a are 32-bit, there is no sparcv7 directory anywhere in sight. There's almost no static 64-bit libs either (with exception of two, libadt_jni.a and libldfeature.a, and they are in lib/sparcv9 as expected). A bit off topic. While configure script for gcc creates makefiles that generate both 32-bit and 64-bit libraries, I noticed that configure script in all other GNU packages doesn't. Even more, when building on sparc64 target, the libraries (which are 64-bit) get installed in prefix/lib (not in prefix/lib/sparcv9). Hmmm... kind of annoying. Is this generic configure script problem, or libtool problem, or developers not caring about Solaris 32/64 bit specifics, or something else? Any good way to go around that? I've used --libdir $prefix/lib/sparcv9, but that has side effect of placing data files in sparcv9 with some packages (while only 64-bit libs should go there). Gettext is an example of such package where using --libdir has not desired side-effects. This message was sent using IMP, the Internet Messaging Program.
Re: inconsistency in location of static and shared libraries on sparc64-sun-solaris*
Quoting Eric Botcazou <[EMAIL PROTECTED]>: I've noticed one inconsistency how libraries are installed. For shared libraries (lib*.so), the 32-bit version is installed in prefix/lib, while 64-bit version is installed in prefix/lib/sparcv9. For static libraries (lib*.a archives), it is the other way around. The 64-bit version is installed in prefix/lib, while 32-bit version is installed in prefix/lib/sparcv7!? How many libraries do you have in prefix/lib/sparcv7? Which one(s)? Only one so far, libiberty.a. The lib/sparcv7/libiberty.a contains 32-bit object files, while lib/libiberty.a contains 64-bit object files. Actually, looking more closely, the libiberty.a is the only one installed that way (from the gcc sources). All others (for example libstdc++.a) seem to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9). Hmmm... bug in gcc-4.0.2/libiberty/Makefile.in? This message was sent using IMP, the Internet Messaging Program.
build fails with shared libs intalled in non-standard locations
I was doing a build on sparc64-sun-solaris2.9 (I guess all sparc*-*-solaris* targets are affected). The build was failing because library search path was not hardcoded (via -rpath or -R options) into xgcc executable. On my system, I have two libintl.so libraries. Solaris version in /usr/lib/sparcv9/libintl.so.1 and GNU version in /usr/local/lib/sparcv9/libintl.so.3 (from GNU gettext). Of course, xgcc got linked with GNU libint.so.3, however dynamic linker couldn't load it at runtime (since it wasn't in its search path, and binary did not had RUNPATH and RPATH in dynamic section (as displayed by "dump -Lv")). Since I really don't need gcc to complain in any other language (just English is fine), I opted for easy solution. I added --disable-nls option to configure flags. Helped to get me pass building C and C++ compilers. However, than I hit another problem, the f95 failed to build. The reason was that I had GMP library installed as shared lib, and again, dynamic linker couldn't find it (same reason as above, the path to it was not hard coded into the C and Fortran compiler binaries during bootstrapping). Is there anything I can add to "configure" or "make bootstrap" command line to get around this? I attempted using LDFLAGS, but it hasn't helped. I also attempted defining LD_LIBRARY_PATH, however it had no effect during bootstrapping. This message was sent using IMP, the Internet Messaging Program.
Problem with gfortran or did I messsed up GMP installation?
I've just recompiled GCC 4.0.2 for sparc-sun-solaris2.9 with fortran
language enabled. To test it, I found short hello world program on the
net (included).
If I produce 32-bit binary by simply using "gfortran hello.f", it
compiles, but the resulting binary exits immediatelly (no output). If
I produce 64-bit binary using "gfortran -m64 hello.f", the program
prints hello world in an infinite loop. Hmph...
The only "unusual" thing on my system was small manual fix to have both
32-bit and 64-bit GMP installed with same prefix. The fix was to
compare gmp.h file from 32-bit and 64-bit build and merge them (so that
I can use same gmp.h file for compiling both 32-bit and 64-bit
programs) by changing lines that define __GMP_BITS_PER_MP_LIMB and
GMP_LIMB_BITS like this:
#ifdef _LP64
#define __GMP_BITS_PER_MP_LIMB 64
#else /* _ILP32 */
#define __GMP_BITS_PER_MP_LIMB 32
#endif
#ifdef _LP64
#define GMP_LIMB_BITS 64
#else /* _ILP32 */
#define GMP_LIMB_BITS 32
#endif
This looked like the correct way to go. The same ifdef construct is
used throughout system include files (/usr/include) for the same
purpose.
Of course, 32-bit and 64-bit libgmp and libmpfr libraries live each in
its own directory (32-bit in /prefix/lib, 64-bit in
/prefix/lib/sparcv9).
So, the question is, did I broke something by attempting to have both
32-bit and 64-bit GMP library installed simultaniously? Did I miss
anything needed to have both 32-bit and 64-bit GMP available on the
system? Or is there something wrong with gfortran compiler?
The "hello world" program looks like this. I haven't done anything
fortran in a vry long time (last time like in 1992 or
something). Looks to me like it should just print hello world in
endless loop.
c
c Hello, world.
c
Program Hello
implicit none
logical DONE
DO while (.NOT. DONE)
write(*,10)
END DO
10 format('Hello, world.')
END
This message was sent using IMP, the Internet Messaging Program.
Re: Problem with gfortran or did I messsed up GMP installation?
Quoting Eric Botcazou <[EMAIL PROTECTED]>: So, the question is, did I broke something by attempting to have both 32-bit and 64-bit GMP library installed simultaniously? Did I miss anything needed to have both 32-bit and 64-bit GMP available on the system? Do not install both 32-bit and 64-bit GMP, you only need one of them: sparc-sun-solaris2.* compiler -> 32-bit GMP sparc64-sun-solaris2.* compiler -> 64-bit GMP. OK. But what if I want sparc-sun-solaris2.* compiler, and later want to compile some 64-bit app that links with GMP too (or the other way around)? I should be able to have both libs on system where multilib is supported option (such as sparc*-sun-solaris*). Anyhow, if the problem was with multilib GMP installation, I would expect 64-bit binary to fail. Not 32-bit. When compiler was bootstrapped, it saw 32-bit definitions in gmp.h and was linked with matching 32-bit GMP library. So I would expect it to produce correct 32-bit code. If there were any issues with having GMP installed "multilib", I would expect it to generate faulty 64-bit code in this configuration. This message was sent using IMP, the Internet Messaging Program.
Re: Problem with gfortran or did I messsed up GMP installation?
Quoting Eric Botcazou <[EMAIL PROTECTED]>: GMP is used by the compiler, not by the application, so you only need the version that the compiler will use. Right, that's what I previously said. :-) But Aleksandar apparently insists on having both versions installed. Well, I'm not insisting... Simply asking. Somehow it sounded natural to me that there might be two applications on the system installed under same tree (for example 32-bit gcc and 64-bit gcc64 compiler, lacking any other example of application that uses GMP) that need different versions of the library. This message was sent using IMP, the Internet Messaging Program.
Re: Problem with gfortran or did I messsed up GMP installation?
Nix wrote: On 13 Jan 2006, Eric Botcazou mused: GMP is used by the compiler, not by the application, so you only need the version that the compiler will use. Right, that's what I previously said. :-) But Aleksandar apparently insists on having both versions installed. Doesn't Solaris have an equivalent of /usr/lib64 where you could put the 64-bit-only version? It has. It is sparcv9 subdirectory of lib. That is exactly how I have it installed. 32-bit version in lib/libgmp.so*, 64-bit version in lib/sparcv9/libgmp.so*. They don't clash with each other (or at least they shouldn't). The ifdefs I inserted into gmp.h header will provide correct definitions depending on compilation mode (-m32 or -m64). In any case this is an OS/shared library loader thing, not anything that anyone here can reasonably solve, I'd think. The ld.so loads correct version of shared library. If it wasn't, executable (f951) would fail at runtime with "wrong ELF class". So, the OS is OK, dynamic loader is OK. It's something between GMP and GCC.
Re: Problem with gfortran or did I messsed up GMP installation?
Eric Botcazou wrote: So, the question is, did I broke something by attempting to have both 32-bit and 64-bit GMP library installed simultaniously? Did I miss anything needed to have both 32-bit and 64-bit GMP available on the system? Do not install both 32-bit and 64-bit GMP, you only need one of them: sparc-sun-solaris2.* compiler -> 32-bit GMP sparc64-sun-solaris2.* compiler -> 64-bit GMP. OK, so I reinstalled GMP. Now I have only 32-bit GMP on the system. Stock gmp.h file. Recompiled gcc (4.0.2), target sparc-sun-solaris2.9. Got exactly same thing. When I compile simple looping hello world program (source in my first post), it exits right away. When I use -m64, it works OK (loops forever printing "hello world"). Now, the interesting part. I also built gcc 4.0.2 on sparc-sun-solaris2.6. If I compile the "hello world" program on it (obviously it will be 32-bit), it runs just fine (prints hello world in endless loop). If I copy the executable to Solaris 2.9 system and run it, it exits immediately. Hmph... Interesting... Looks like the problem is in libgfortran? Should I file bug on bugzilla?
Re: Problem with gfortran or did I messsed up GMP installation?
Quoting Eric Botcazou <[EMAIL PROTECTED]>: Please make sure every bit of the hacked GMP has been wiped out on Solaris 9. Should I file bug on bugzilla? Sure, if you can reproduce it after cleaning up the Solaris 9 machine. To confirm things, I did following: Install gcc 2.8.1 binary (from gnat-3.15p-sparc-sun-solaris2.5.1-bin.tar.gz) into /gcc-test (empty directory). I used this one, since I guess anybody starting from scratch (fresh clean system) would use a binary like this (and this one can also bootstrap Ada compiler if needed). /usr/local on this system does not conatin any include or library files. Place /gcc-test/bin first in my path and define LD_RUN_PATH: $ export PATH=/gcc-test/bin:$PATH $ hash -r $ export LD_RUN_PATH=/gcc-test/lib:/gcc-test/lib/sparcv9 Install binutils 2.16: $ ../configure --prefix=/gcc-test --disable-nls \ --enable-64-bit-bfd Compile GMP 4.1.4: $ ../configure ABI=32 --prefix=/gcc-test --enable-mpfr Bootstrap GCC 4.0.2 with c and f95: $ ../configure --prefix=/gcc-test --with-local-prefix=/gcc-test \ --enable-languages=c,f95 --disable-nls \ --with-as=/gcc-test/bin/as --with-ld=/gcc-test/bin/ld \ --with-gnu-as --with-gnu-ld \ --with-mpfr=/gcc-test --with-gmp=/gcc-test Prior to compilation, I removed all sources (binutils, GMP, and GCC), and untarred them from original tar archives. Would this be clean enough? I don't see anything wrong in the way I created this test environment. If there is something wrong, please let me know. After doing all this, the problem is still there. So I would say I can reproduce it. This message was sent using IMP, the Internet Messaging Program.
Re: Problem with gfortran or did I messsed up GMP installation?
Quoting Eric Botcazou <[EMAIL PROTECTED]>: Compile GMP 4.1.4: $ ../configure ABI=32 --prefix=/gcc-test --enable-mpfr Would you mind trying as documented in http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2 i.e. with --build=sparc-sun-solaris2.9 instead of ABI=32? I'll try it. The only difference (AFAIK) should be that GMP will use only sparcv7 optimized assembler code. I'll also try it out on Solaris 2.11 beta (just for the kicks, and because it is the only virgin Solaris box I have). This message was sent using IMP, the Internet Messaging Program.
Re: Problem with gfortran or did I messsed up GMP installation?
Eric Botcazou wrote: Compile GMP 4.1.4: $ ../configure ABI=32 --prefix=/gcc-test --enable-mpfr Would you mind trying as documented in http://gcc.gnu.org/install/specific.html#sparc-sun-solaris2 i.e. with --build=sparc-sun-solaris2.9 instead of ABI=32? Done. I got same thing (32-bit hello world doesn't work, 64-bit hello world works). It could still be something with my local configuration. After all, 32-bit hello world works on my 2.6 box. However, I don't see anything obvious... I did builds (the ones I'm now using) in exactly same way on both 2.6 and 2.9. The Solaris 2.11 build is still running (building all languages on an older box). Hopefully it will be done sometime tomorrow ;-)
Re: Problem with gfortran or did I messsed up GMP installation?
Quoting Vincent Lefevre <[EMAIL PROTECTED]>: Hi, On 2006-01-25 13:10:50 -0600, Aleksandar Milivojevic wrote: Compile GMP 4.1.4: $ ../configure ABI=32 --prefix=/gcc-test --enable-mpfr You shouldn't use the MPFR version distributed with GMP; it is very old and buggy. It is much better to compile GMP without MPFR support then compile MPFR 2.2.0 separately: http://www.mpfr.org/mpfr-current/ Probably a good idea. While on the subject, but not directly related to gcc as such, is there a way to compile gdb to use already installed bfd and opcodes libraries (from binutils package) instead of insisting on its own copy? This message was sent using IMP, the Internet Messaging Program.
Re: Problem with gfortran or did I messsed up GMP installation?
Vincent Lefevre wrote: You shouldn't use the MPFR version distributed with GMP; it is very old and buggy. It is much better to compile GMP without MPFR support then compile MPFR 2.2.0 separately: http://www.mpfr.org/mpfr-current/ Heh... If MPFR 2.2.0 (fully patched) is configured with --enable-thread-safe option, GCC's configure script complains MPFR is non-functional. Looking at config.log (that I already managed to remove, sorry), linker couldn't resolve some symbol with "__" and "tls" in name (don't remember exact name) from libmpfr.so. Probably some library missing. Seems that when MPFR is compiled without that option, GCC compiles (well, it's compiling as I type this, but I guess it should be OK).
Re: Problem with gfortran or did I messsed up GMP installation?
Quoting Eric Botcazou <[EMAIL PROTECTED]>: So, the question is, did I broke something by attempting to have both 32-bit and 64-bit GMP library installed simultaniously? Did I miss anything needed to have both 32-bit and 64-bit GMP available on the system? Do not install both 32-bit and 64-bit GMP, you only need one of them: sparc-sun-solaris2.* compiler -> 32-bit GMP sparc64-sun-solaris2.* compiler -> 64-bit GMP. I did some additional testing. I can reproduce the problem *only* on UltraSPARC-IIe machine. If I run the program on any other machine, it runs correctly. Also, if I statically link program on UltraSPARC-IIe machine, it doesn't run on any other machine. If I statically link it on any other machine, it runs correctly on UltraSPARC-IIe. H... I've filled bug report with more information. This might or might not be the bug in gcc/f951, since obviously there are many more components involved (gmp, mpfr, Solaris system libraries, the processor itself, or any combination). The bug ID is 25998 for those interested. This message was sent using IMP, the Internet Messaging Program.
libmudflap on Solaris?
Was there any work (or plans) on porting libmudflap to Solaris (either SPARC or x86)? This message was sent using IMP, the Internet Messaging Program.
Re: libmudflap on Solaris?
Quoting Rainer Orth <[EMAIL PROTECTED]>: Aleksandar Milivojevic <[EMAIL PROTECTED]> writes: Was there any work (or plans) on porting libmudflap to Solaris (either SPARC or x86)? Last time I looked (cf. PR libmudflap/15176), libmudflap depended on GNU ld's --wrap option. You might have some success when you use GNU binutils, but I prefer the vendor linker if at all possible, so I haven't tried this. I'm using GNU ld. Before I sent this email, I simply attempted to pass '--enable-libmudflap' to gcc configure script. The compilation failed while compiling libmudflap/mf-hooks2.c with bunch of warnings about 'bzero', 'bcopy, and so on, and then errors about dereferencing pointer to incomplete type. I was just curious if anybody was already porting it to Solaris... This message was sent using IMP, the Internet Messaging Program.
