SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I run slackware 10.1, kernel 2.6.10, glibc 2.3.4, and I am trying to use the intel fortran compiler together with the corresponding intel debugger idb. Unfortunately, these are designed to work with glibc 2.3.2 and they don't work on my system.
I have used them with a previous slackware distribution with glibc 2.3.2 and they work fine. So glibc must be my problem.
Can anyone tell me how to
1. install multiple glibc versions in my system
2. force a specific program (in my case idb) to use the not-default glibc version?
Did you find a solution to this? I'm having the same problem (except on Mandriva 10.1).
I've used the crosstool script by Daniel Kegel to build a gcc/glibc toolchain with the required versions, but I don't know how to have the second glibc libraries used on my target machine (which is also the build machine).
Nobber, that will work sometimes -I've done that for several programs.
And Sadohert, you have to pass LD_LIBRARY_PATH to the compiler(linker), I believe at compile time.
I'm currently working on the opposite thing -trying to get two compilers installed using(mostly?) the same libs.
You might find some good leads on this by consulting the Linux From Scratch HOWTO'S.
I learned a lot by compiling a whole 'shadow' system with alternate directory structure(every program patched!) -based on UCLIBC(called uSTEP). But I still don't have my head around it all...
Yup. chroot in there and have just two directories /Sytem and /Users with every single standard Linux directory re-pathed -have to alter code for nearly every prog except init to change the paths. To not chroot and actually run native, you need a path-modified kernel as well.
What I want to do now is much simpler. I have a GCC-3.3.x system, but am using lots of OLD code that compiles better with GCC-2.95. I've compiled GCC-2.95.3 (against native system libs to run on native system) to run from /opt/gcc-2.95.3/bin. It creates a relatively-linked toolpath for its' own tools and libs in /opt.
So then to compile using this i just prepend the path:
'which gcc' should show the bin in /opt
This seems to be working now for c-only code, but not c++. The cxx-libs created by/for the compiler are in /opt, but I haven't gotten all the linking figured out -I need to go back to my notes- they must eb around here somewhere...
Well, there's no way I'm in a position to touch the first thing you described, but I THINK the simpler problem you described is similar to what I want to do. I have a gcc 3.4 based system (Mandrake 10.1), but I absolutely HAVE to compile my research project using gcc 3.2.3 because I'm working with compiled Matlab shared libraries (which need gcc 3.2.3). I built a gcc 3.2.3 using the bootstrap option on my system (it wouldn't work otherwise) and compilation works fine. Basically, most things work except for a very key thing.... debugging. I get really bizarre and sporradic SIGTRAP errors whenever I step over or near the Matlab based function calls. Sometimes they happen, sometimes they don't, and there's never a problem when I don't debug. Calling "where" in gdb after the SIGTRAP error tells me the problem occurs in or around libpthread. That made me think maybe I have to have a libpthread (i.e., glibc) version that is better suited to my older compiler. So that's why I want the two glibc versions. Anyway, still figuring out how to get the linker to use the old glibc libraries.
I'm going a bit crazy. I officially hate threading!
Compile the old libs and install them anywhere. Then to compile code against them configure so:
export LD_LIBRARY_PATH=/path/to/libs ; ./configure --prefix=/prog/install/prefix ...etc.
In the Makefile small-lettered variables are usually what gets configured into the code -it telss where the final prog will install and where it will look for it's libs on the final system.
small_lettered_variables_like_this are usually aclocal/autoconf options.
ALLCAPITAL variables are compiler options. (CFLAGS CPP)
The ALL_CAPITAL_VARIABLES_LIKE_THIS are Linker flags
The C++ linking is giving me problems because the libs are produced with the compiler and I'm not sure if I'M supposed to link the compiles to those, or to the libstdc++ used for the rest of the system...