LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 05-19-2005, 01:32 PM   #1
gnp
LQ Newbie
 
Registered: May 2005
Posts: 1

Rep: Reputation: 0
using multiple glibc versions on slackware 10.1


Hi all

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?

thank you in advance
-- gnp
 
Old 05-20-2005, 06:28 AM   #2
Nobber
Member
 
Registered: Jun 2002
Location: Nova Scotia
Distribution: Debian (home), Kubuntu 7.04 (work)
Posts: 265

Rep: Reputation: 30
What error message do you get when trying to run the programs under glibc 2.3.4?

My first thought would be to try fooling the programs into accepting glibc 2.3.4 thus:

ln -s libc-2.3.4.so /lib/libc-2.3.2.so

But I don't know enough about this sort of thing to have any idea whether that has a chance of working!

Last edited by Nobber; 05-20-2005 at 06:31 AM.
 
Old 05-31-2005, 02:52 PM   #3
sadohert
LQ Newbie
 
Registered: Apr 2005
Location: Ontario, Canada
Distribution: Debian 3.1
Posts: 13

Rep: Reputation: 0
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).

Stu
 
Old 05-31-2005, 04:43 PM   #4
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,775

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
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...
 
Old 06-01-2005, 08:28 AM   #5
sadohert
LQ Newbie
 
Registered: Apr 2005
Location: Ontario, Canada
Distribution: Debian 3.1
Posts: 13

Rep: Reputation: 0
Gnashley... thanks a lot. My suspicions on how to solve my problem turned out to be wrong .

Roughly what is a shadow system? I'm guessing it's not a dual boot. Does it basically give you two distinct copies of all libraries and tools that you can somehow switch between?

Thanks

Stu
 
Old 06-01-2005, 09:01 AM   #6
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,775

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
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:
export PATH=/opt/gcc-2.95.3/bin:$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...
 
Old 06-01-2005, 09:19 AM   #7
sadohert
LQ Newbie
 
Registered: Apr 2005
Location: Ontario, Canada
Distribution: Debian 3.1
Posts: 13

Rep: Reputation: 0
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!
 
Old 06-01-2005, 04:04 PM   #8
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,775

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
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...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Multiple glibc versions on Debian Sarge Magik Debian 4 06-21-2005 05:49 PM
Multiple versions of GLIBC El Craigo Red Hat 2 08-12-2004 12:14 AM
how to use older versions of glibc turls Programming 4 07-07-2004 04:40 PM
Why do we need so many versions of glibc? deanbrown3d Linux - Newbie 4 06-29-2004 12:17 PM
versions of Glibc elwis Linux - Software 3 12-12-2003 04:31 PM


All times are GMT -5. The time now is 01:16 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration