The version of a binary package in Debian is determined by dpkg-gencontrol
, which generates the final control file which ends up in the binary package. The -v
option specifies the version number; by default the version number is taken from debian/changelog
, but that can be overridden.
There are a few examples of this in the archive; see for example my own gcc-mingw-w64
package, which has its own (source) version number, but generates binary packages whose versions merge the underlying gcc-source
(currently, gcc-7-source
) version number and the source package's number. Thus in Debian 9, gcc-mingw-w64
version 19.3 produces binary packages versioned 6.3.0-18+19.3.
To build different binary packages with different versions from a single source, you'd combine the -v
option with the -p
option (which specifies the package to process), and run dpkg-gencontrol
(or one of its wrappers, such as dh_gencontrol
) as many times as necessary.
There is at least one package in the archive which demonstrates this: android-sdk-meta
builds binary packages with two different versions, android-sdk
which takes the source version, and four other packages whose binary version is specified in debian/rules
.
The Debian Policy chapter on control fields has more detail on the differences between source and binary control files.
You can definitely compile a new version of GLIBC and have it stored in a separate directory.
The first thing you'll have to do is download the version of glibc that you want from http://ftp.gnu.org/gnu/glibc/.
Run the configure
script and set the --prefix=
to something like /home/you/mylibs
.
After you've managed to install it into that directory, you'll have to set your LD_LIBRARY_PATH
to the location of the new glibc.
You'll need to figure out any dependencies you may need to compile. You can create a shell script that sets the LD_* variables and the runs your program (which you'd have to do anyway), and run it repeatedly - download/recompiling missing libs along the way.
You could also use ldd
to determine what shared libraries the program needs, then use ldd
on each of the libraries to find out if they require glibc.
This can be a very time consuming process and is not for the impatient or faint of heart - traversing/recompiling your way through the possible dependencies required to make your application work may occasionally make you want to pull out your hair.
Update 1:
I downloaded glibc-2.4 and tried to compile it on CentOS 6. To get configure
working properly I had to change the ac
and ld
version checks by changing:
2.1[3-9]*)
to:
2.*)
at lines 4045
and 4106
in the configure
file itself. I set my *FLAGS environment variables like so:
LDFLAGS="-Wl,--sort-common -Wl,-zcombreloc -Wl,-znow"
CFLAGS="-pipe -fomit-frame-pointer -g1 -O3 -frename-registers -fweb -ftracer -fmodulo-sched -fvariable-expansion-in-unroller -fgcse-sm"
CXXFLAGS="${CFLAGS}"
CFLAGS="${CFLAGS} -freorder-blocks-and-partition"
export LDFLAGS CFLAGS CXXFLAGS
and then executed ./configure --prefix=/home/tim/masochist
. It configured properly... and it began building properly too... but then I started running into errors - mostly the compiler complaining about things being redefined.
At that point I gave up... Because it was becoming too time consuming. ;)
Best Answer
Yes, it's possible. You'll have to be very careful with the library load paths, and you may need to recompile some other libraries.
As the path of least friction, I recommend installing an older version of Debian or Ubuntu in a chroot. That is, make a directory, say
/old/etch
, and install the older distribution in the tree rooted there; to run that problematic program, callchroot
to restrict its view of the filesystem to/old/etch
.Debian (or Ubuntu) comes with a package to assist with installing another system in a chroot: schroot (successor of dchroot). First, use debootstrap to install the older distribution (install only the base system and what your program needs, no servers). Then set up schroot to run the program conveniently (with
/dev
,/proc
,/home
and other “satellite” filesystems accessible).So the plan is: debootstrap, then dchroot. In How do I run 32-bit programs on a 64-bit Debian/Ubuntu?, I give a tutorial about a similar setup − whether you're running different versions of the distribution, or different architectures, or different Debian-like distributions, it's only a matter of selecting the appropriate package source, the rest is the same.