Discussion:
compiling gcc 2.95.3 under ubuntu 10.04.2, x86_64
Andrew Haley
2012-04-03 10:17:44 UTC
Permalink
The URL above contains a link to my stdout/stderr logs too.
That thing wants me to use flash. I don't use flash.

Andrew.
Andrew Haley
2012-04-03 10:22:04 UTC
Permalink
Hello everyone,
Not sure if this is the right place to ask this question, feel free to point me in the right direction.
Redirect to gcc-help.
I'm looking into the evolution of Linux kernel and this requires me
to build some ancient releases (as old as 2.4.0) from source using
GCC. I have gcc 4.4.3-4ubuntu5 installed on my lab machine but it's
incompatible with these old sources, and the "lowest common
denominator" would be gcc 2.95.3, so I've been trying to compile it
from source - so far with little success.
http://www.trevorpounds.com/blog/?p=111&cpage=1#comment-102. I
followed all of his suggestions but so far hasn't had much luck -
/usr/bin/ld.bfd.real: error in pic/cstrmain.o(.eh_frame); no .eh_frame_hdr table will be created.
The URL above contains a link to my stdout/stderr logs too. Has anyone here tried compiling such an old version of GCC? Any advice/help would be greatly appreciated.
It's going to be hard. gcc 2.95 doesn't support using x86_64 as a host,
so you're going to have to build in in a 32-bit virtual machine or by
using mock.

You'll have other problems too. gcc back then wasn't so standards-
clean as it is now; we have a lot of warnings and better diagnostics
that have allowed us to clean up gcc. I don't know why you got that
particular message, and as I said I can't look at your logs. I might
have a try myself to build gcc 2.95 later today.

Andrew.
Roman Suvorov
2012-04-03 17:12:24 UTC
Permalink
Hi Andrew,

Here's the relevant bit from the website I referenced:
***
GCC 2.95.x
About half of the changes needed for GCC 3.0.x are also applicable here (e.g. Makefile fixes, lib32 fix-ups, spec flags, etc). Unfortunately, the other half are workarounds for compiler and glibc nuances that are fixed in later releases. One of the big changes needed is a workaround for the internal use of an _IO_MTSAFE_IO define. This define causes an error due to a missing header due to difference in glibc headers included with modern Linux distributions (see here and here for more info). Luckily, a straightforward workaround is to use glibc's generic stdio-lock.h header, which in my case needed to be pulled from the glibc 2.10.1 source to match my installed version. Additionally, another glibc fix is required due to an unnamed union declaration (see this bug) inside a pthread header which is not supported by GCC 2.95.x. To workaround the issue I pulled in the glibc 2.10.1 system dependent pthreadtypes.h header from the source and appended a variable name (e.g. __gcc_295_workaround__) to the unnamed union declaration. Build this version using the provided patch @ (gcc-v2.95.x.debian.x86_64.diff)
and the following instructions:

# shell commands
tar xzf glibc-2.10.1.tar.gz
mkdir -p gcc-2.95.3/glibc-workaround/include/bits
cp glibc-2.10.1/bits/stdio-lock.h gcc-2.95.3/glibc-workaround/include/bits
cp glibc-2.10.1/nptl/sysdeps/unix/sysv/linux/x86_64/bits/pthreadtypes.h gcc-2.95.3/glibc-workaround/include/bits
sed -i -n '1h;1!H;${;g;s/\(__pthread_slist_t __list;\n[ \t]*}\)/\1 __gcc_295_workaround__/g;p;}' gcc-2.95.3/glibc-workaround/include/bits/pthreadtypes.h
tar xzf gcc-2.95.3.tar.gz
cd gcc-2.95.3
patch -p0 < gcc-v2.95.x.debian.x86_64.diff
mkdir ../gcc-2.95.3-objdir
cd ../gcc-2.95.3-objdir
../gcc-2.95.3/configure --prefix=/opt/i386/gcc/gcc-2.95.3 --enable-languages=c,c++ --enable-threads=posix --enable-shared --host i386-pc-linux-gnu
make
make install
***

I also attached my logs: gcc295.log / gcc295.err in plain text.

If you have any success compiling GCC 2.95 on your own without using the method above please let me know too!

Thank you,
Roman.
Andrew Haley
2012-04-04 13:17:42 UTC
Permalink
Post by Roman Suvorov
***
GCC 2.95.x
About half of the changes needed for GCC 3.0.x are also applicable here (e.g. Makefile fixes, lib32 fix-ups, spec flags, etc). Unfortunately, the other half are workarounds for compiler and glibc nuances that are fixed in later releases. One of the big changes needed is a workaround for the internal use of an _IO_MTSAFE_IO define. This define causes an error due to a missing header due to difference in glibc headers included with modern Linux distributions (see here and here for more info). Luckily, a straightforward workaround is to use glibc's generic stdio-lock.h header, which in my case needed to be pulled from the glibc 2.10.1 source to match my installed version. Additionally, another glibc fix is required due to an unnamed union declaration (see this bug) inside a pthread header w
hich is not supported by GCC 2.95.x. To workaround the issue I pulled in the glibc 2.10.1 system dependent pthreadtypes.h header from the source and appended a variable name (e.g. __gcc_295!
_workaroun
Well, what do you know? I just bootstrapped gcc 2.95.3 on Fedora 17
(i686 mock) with no changes at all. The only problem I had was with
texinfo, where the in-tree version supplied with gcc didn't work, so
I deleted it and used Fedora's own.

"make install" produces a fully-functional gcc that you can use in a
x86_64 system:

zebedee:~ $ /usr/local/bin/gcc home/aph/hello.c -Wa,--32
/usr/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for -lc
zebedee:~ $ ./a.out
Hello, world!

The -Wa,--32 (which tells the native assembler to use 32-bit source) is
a pain, though. I guess you'd want to fix that by installing an explicit.
i686-pc-linux-gnu-as and building gcc 2.95 with that.

Andrew.
Roman Suvorov
2012-04-05 16:03:12 UTC
Permalink
Hi Andrew, this is great news! Could you provide exact instructions on how you got this to work though? As you can tell I'm pretty new to building from source, especially an old version of GCC.

I assumed you meant using "mock" (http://linux.die.net/man/1/mock) to aid in building and to emulate a 32-bit machine.
Version 0.97-3 of mock provided with Ubuntu 10's apt-get has a bug (https://bugs.launchpad.net/ubuntu/+source/mock/+bug/600564) and I used 1.1.22 instead, trying to build gcc using something like this:

mock -r fedora-17-i386 --resultdir=/path/to/home/dir/mock/ /path/to/home/dir/c32-gcc-2.95.3-lx.rpm

I got the rpm from http://www.rpmfind.net/linux/rpm2html/search.php?query=gcc&submit=Search+...&system=&arch=i386
Even this isn't working yet (I don't have root access to the server and mock for some reason refuses to run this without them), but am I on the right path at least?

Cheers,
Roman.
Post by Roman Suvorov
Post by Roman Suvorov
***
GCC 2.95.x
About half of the changes needed for GCC 3.0.x are also applicable here (e.g. Makefile fixes, lib32 fix-ups, spec flags, etc). Unfortunately, the other half are workarounds for compiler and glibc nuances that are fixed in later releases. One of the big changes needed is a workaround for the internal use of an _IO_MTSAFE_IO define. This define causes an error due to a missing header due to difference in glibc headers included with modern Linux distributions (see here and here for more info). Luckily, a straightforward workaround is to use glibc's generic stdio-lock.h header, which in my case needed to be pulled from the glibc 2.10.1 source to match my installed version. Additionally, another glibc fix is required due to an unnamed union declaration (see this bug) inside a pthread header which is not supported by GCC 2.95.x. To workaround the issue I pulled in the glibc 2.10.1 system dependent pthreadtypes.h header from the source and appended a variable name (e.g. __gcc_295!
_workaroun
Well, what do you know? I just bootstrapped gcc 2.95.3 on Fedora 17
(i686 mock) with no changes at all. The only problem I had was with
texinfo, where the in-tree version supplied with gcc didn't work, so
I deleted it and used Fedora's own.
"make install" produces a fully-functional gcc that you can use in a
zebedee:~ $ /usr/local/bin/gcc home/aph/hello.c -Wa,--32
/usr/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for -lc
zebedee:~ $ ./a.out
Hello, world!
The -Wa,--32 (which tells the native assembler to use 32-bit source) is
a pain, though. I guess you'd want to fix that by installing an explicit.
i686-pc-linux-gnu-as and building gcc 2.95 with that.
Andrew.
Andrew Haley
2012-04-10 09:27:45 UTC
Permalink
Post by Roman Suvorov
Hi Andrew, this is great news! Could you provide exact instructions
on how you got this to work though? As you can tell I'm pretty new
to building from source, especially an old version of GCC.
I think that a person who is not used to building large projects from
source perhaps shouldn't even try to build 2.95. It takes an expert,
and an expert would not use such an old compiler but would fix the
source code of the program he's trying to compile. But if you insist I
will give a little help. But please allow me to be straight with you:
I think that what you are doing is wrong, and you should not now be
using gcc 2.95 for anything.
Post by Roman Suvorov
I assumed you meant using "mock" (http://linux.die.net/man/1/mock)
to aid in building and to emulate a 32-bit machine.
Yes, that's the right too.
Post by Roman Suvorov
Version 0.97-3 of mock provided with Ubuntu 10's apt-get has a bug
(https://bugs.launchpad.net/ubuntu/+source/mock/+bug/600564) and I
mock -r fedora-17-i386 --resultdir=/path/to/home/dir/mock/ /path/to/home/dir/c32-gcc-2.95.3-lx.rpm
I used the gcc source tarball. I used "mock -r fedora-17-i386 shell"
to get me a shell and I then configured and built gcc with

<dir>/gcc-2.95.3/configure --enable-languages=c++ --disable-docs
make

I had to install a ton of dependencies for gcc. Mock will install the
right ones for you if you try to build the gcc RPM.

Andrew.
Jonathan Wakely
2012-04-03 18:21:23 UTC
Permalink
Please move this thread to gcc-help, thanks,
Hi Richard,
Could you please provide some more instructions on how you got your 2.95 build using GCC 3?
You can't just take a single file from the package and expect it to
work, you need to install the whole package or install 3.4.6 properly,
i.e. by building it from source.
CC=../gcc-3.4/bin/gcc-3.4 CFLAGS=-D_FORTIFY_SOURCE=0 ./configure --
prefix=~/gcc-2.95.3 --enable-languages=c,c++ --enable-threads=posix
--enable-shared --host i386-pc-linux-gnu

You haven't read the installation docs.

Do not run ./configure, build in a separate directory.

You probably want to use --prefix=$HOME/gcc-2.95.3 because the shell
won't expand ~ in the middle of a word like that.

You don't need to use --enable-threads=posix or --enable-shared, those
are enabled by default on GNU/Linux.

You're missing a '=' after --host (not sure if that matters though)
Roman Suvorov
2012-04-12 17:25:19 UTC
Permalink
Hello Andrew,

Thank you very much for your help. Just to clarify, absolutely, I'm not an expert in building from source but I don't really need to be one. What I need a build of gcc 2.95 on my machine for is compiling some really old code and recording performance metrics (i.e., build times). I don't intend to use the resulting binaries, but I can't use a more modern build of gcc as it would need massive code to compile such old projects.

I ran into a problem with mock & rpm and I was wondering if you could help. I posted this on the rpm mailing list but if you could shed some light on this it'd be appreciated. The error message from mock prompting to update rpm appears immediately even before I build the shell - when initializing a chroot with "mock -r fedora-17-i386 --init".

###
I'm trying to build rpm from source to use with mock (1.1.22), which with my current build complains that:
***
ERROR You need to update rpm to handle:
rpmlib(PayloadIsXz) <= 5.2-1 is needed by coreutils-8.15-6.fc17.i686
--snip--
rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-3-2.fc17.i686
--snip--
***
I'm trying to build the latest version, 4.9.1.2, using the following configure/make commands:

./configure --prefix=/usr --enable-sqlite3 --enable-python --with-cap --with-acl --with-lua --with-dmalloc CPPFLAGS="`pkg-config --cflags nss` -I/path/to/lua/src" LDFLAGS="-L/path/to/lua/src -llua -lm" LUA_CFLAGS="-I/path/to/lua/src" LUA_LIBS="-L/path/to/lua/src"
make

This should enable just about everything in my rpm build. CPPFLAGS are set to find NSPR & NSS headers; /path/to/lua contains a build of lua-5.1.5 with an additional shared library liblua.so target (that's what -llua in LDFLAGS is for). All the other flags ensure I use my 5.1.5 lua build.
This still produces a build with the following rpmlib's. Here's part of the output of ./rpm --showrc:
***
rpmlib(BuiltinLuaScripts) = 4.2.2-1
rpmlib(CompressedFileNames) = 3.0.4-1
rpmlib(ConcurrentAccess) = 4.1-1
rpmlib(ExplicitPackageProvide) = 4.0-1
rpmlib(FileCaps) = 4.6.1-1
rpmlib(FileDigests) = 4.6.0-1
rpmlib(HeaderLoadSortsTags) = 4.0.1-1
rpmlib(PartialHardlinkSets) = 4.0.4-1
rpmlib(PayloadFilesHavePrefix) = 4.0-1
rpmlib(PayloadIsBzip2) = 3.0.5-1
rpmlib(ScriptletExpansion) = 4.9.0-1
rpmlib(ScriptletInterpreterArgs) = 4.0.3-1
rpmlib(VersionedDependencies) = 3.0.3-1
***
So BuiltinLuaScripts & FileCaps are now present - the 4.7.2 build I had on my system was lacking those too, but I'm still not seeing PayloadIsXz & X-CheckUnifiedSystemdir.
What can I do to enable those rpmlib's? Any help would be greatly appreciated.
###

Regards,
Roman.
Post by Andrew Haley
Post by Roman Suvorov
Hi Andrew, this is great news! Could you provide exact instructions
on how you got this to work though? As you can tell I'm pretty new
to building from source, especially an old version of GCC.
I think that a person who is not used to building large projects from
source perhaps shouldn't even try to build 2.95. It takes an expert,
and an expert would not use such an old compiler but would fix the
source code of the program he's trying to compile. But if you insist I
I think that what you are doing is wrong, and you should not now be
using gcc 2.95 for anything.
Post by Roman Suvorov
I assumed you meant using "mock" (
http://linux.die.net/man/1/mock
)
Post by Roman Suvorov
to aid in building and to emulate a 32-bit machine.
Yes, that's the right too.
Post by Roman Suvorov
Version 0.97-3 of mock provided with Ubuntu 10's apt-get has a bug
(
https://bugs.launchpad.net/ubuntu/+source/mock/+bug/600564
) and I
Post by Roman Suvorov
mock -r fedora-17-i386 --resultdir=/path/to/home/dir/mock/ /path/to/home/dir/c32-gcc-2.95.3-lx.rpm
I used the gcc source tarball. I used "mock -r fedora-17-i386 shell"
to get me a shell and I then configured and built gcc with
<dir>/gcc-2.95.3/configure --enable-languages=c++ --disable-docs
make
I had to install a ton of dependencies for gcc. Mock will install the
right ones for you if you try to build the gcc RPM.
Andrew.
Andrew Haley
2012-04-12 18:03:20 UTC
Permalink
Post by Roman Suvorov
Thank you very much for your help. Just to clarify, absolutely, I'm
not an expert in building from source but I don't really need to be
one. What I need a build of gcc 2.95 on my machine for is compiling
some really old code and recording performance metrics (i.e., build
times). I don't intend to use the resulting binaries, but I can't
use a more modern build of gcc as it would need massive code to
compile such old projects.
I ran into a problem with mock & rpm and I was wondering if you
could help. I posted this on the rpm mailing list but if you could
shed some light on this it'd be appreciated. The error message from
mock prompting to update rpm appears immediately even before I build
the shell - when initializing a chroot with "mock -r fedora-17-i386
--init".
###
***
rpmlib(PayloadIsXz) <= 5.2-1 is needed by coreutils-8.15-6.fc17.i686
--snip--
rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-3-2.fc17.i686
--snip--
***
The latest version of what RPM?
Post by Roman Suvorov
./configure --prefix=/usr --enable-sqlite3 --enable-python --with-cap --with-acl --with-lua --with-dmalloc CPPFLAGS="`pkg-config --cflags nss` -I/path/to/lua/src" LDFLAGS="-L/path/to/lua/src -llua -lm" LUA_CFLAGS="-I/path/to/lua/src" LUA_LIBS="-L/path/to/lua/src"
make
This should enable just about everything in my rpm build. CPPFLAGS are set to find NSPR & NSS headers; /path/to/lua contains a build of lua-5.1.5 with an additional shared library liblua.so target (that's what -llua in LDFLAGS is for). All the other flags ensure I use my 5.1.5 lua build.
***
rpmlib(BuiltinLuaScripts) = 4.2.2-1
rpmlib(CompressedFileNames) = 3.0.4-1
rpmlib(ConcurrentAccess) = 4.1-1
rpmlib(ExplicitPackageProvide) = 4.0-1
rpmlib(FileCaps) = 4.6.1-1
rpmlib(FileDigests) = 4.6.0-1
rpmlib(HeaderLoadSortsTags) = 4.0.1-1
rpmlib(PartialHardlinkSets) = 4.0.4-1
rpmlib(PayloadFilesHavePrefix) = 4.0-1
rpmlib(PayloadIsBzip2) = 3.0.5-1
rpmlib(ScriptletExpansion) = 4.9.0-1
rpmlib(ScriptletInterpreterArgs) = 4.0.3-1
rpmlib(VersionedDependencies) = 3.0.3-1
***
So BuiltinLuaScripts & FileCaps are now present - the 4.7.2 build I had on my system was lacking those too, but I'm still not seeing PayloadIsXz & X-CheckUnifiedSystemdir.
What can I do to enable those rpmlib's? Any help would be greatly appreciated.
Sorry, it's hard for me to say. All I can say for sure is that I just
built gcc from the source tree without all this RPM stuff. :-)

Andrew.
Roman Suvorov
2012-04-12 19:27:32 UTC
Permalink
Post by Andrew Haley
The latest version of what RPM?
The latest version of the rpm tool itself (RPM Package Manager, www.rpm.org). When using mock to initialize a chroot, mock complains that I have to update rpm (I have 4.7.2, latest is 4.9.1.2) and that the current build is missing a few of those rpmlib "capabilities".
So I'm configuring and building rpm from source too - all to make mock work.

Regards,
Roman.
Michael Shell
2012-04-12 19:57:19 UTC
Permalink
On Thu, 12 Apr 2012 13:25:19 -0400
Post by Roman Suvorov
***
rpmlib(PayloadIsXz) <= 5.2-1 is needed by coreutils-8.15-6.fc17.i686
--snip--
rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-3-2.fc17.i686
PayloadIsXz probably depends on the xz compression utility and library:

xz --version

More info about xz is here:

http://www.linuxfromscratch.org/lfs/view/development/chapter06/xz-utils.html
http://tukaani.org/xz/

Xz is a good thing to have in any case as many packages are now being
distributed using .xz as it usually compresses better than bzip2. After
installing xz, you might want to later rebuild tar (backup your old
version first in case something goes wrong as tar is important) so it
can unpack .tar.xz files:

http://www.linuxfromscratch.org/lfs/view/development/chapter06/tar.html
http://www.gnu.org/software/tar/

However, I do not know what X-CheckUnifiedSystemdir requires. Check the
rpm config.log to see what configure is looking for to enable it. Also,
look through the --enable options of

./configure --help

to see if anything catches your eye.


Cheers,

Mike Shell
Roman Suvorov
2012-04-12 20:46:13 UTC
Permalink
This post might be inappropriate. Click to display it.
Michael Shell
2012-04-13 02:14:50 UTC
Permalink
On Thu, 12 Apr 2012 16:46:13 -0400
Post by Roman Suvorov
xz (and liblzma) are definitely installed (v. 4.999.9beta), and I'm
using tar 1.22. I looked through all of the configure tool's help,
nothing mentions X-CheckUnifiedSystemdir.
Roman,

OK, I did scan through rpm-4.9.1.2's source tree for PayloadIsXz:

find . -type f -print | sort | xargs grep PayloadIsXz

./build/pack.c: (void) rpmlibNeedsFeature(h, "PayloadIsXz", "5.2-1");
./ChangeLog: - rpmlib(PayloadIsXz) dependency versioned 5.2-1 to avoid unnecessary
./lib/rpmds.c: { "rpmlib(PayloadIsXz)", "5.2-1",


lib/rpmds.c is interesting and mentions other dependencies too.
As far as PayloadIsXz is concerned, HAVE_LZMA_H must be set.
After configuring, my config.h has:

/* Define to 1 if you have the <lzma.h> header file. */
#define HAVE_LZMA_H 1

What does yours say?

As far as X-CheckUnifiedSystemdir goes, a search for it shows nothing
in the entire rpm tree source tree, not even in the ChangeLog:

find . -type f -print | sort | xargs grep CheckUnifiedSystemdir

I wonder if they removed it, or is this something for a special version
of rpm (the alternate 5.x series or some such).

Google would be the way to go here for info, but Google search seems
to be broken (error 404, with broken robot response) just now (no joke).


Mike
Michael Shell
2012-04-13 18:23:21 UTC
Permalink
On Thu, 12 Apr 2012 22:14:50 -0400
Post by Michael Shell
find . -type f -print | sort | xargs grep CheckUnifiedSystemdir
I wonder if they removed it, or is this something for a special version
of rpm (the alternate 5.x series or some such).
Google would be the way to go here for info, but Google search seems
to be broken (error 404, with broken robot response) just now (no joke).
Well, I did not find the CheckUnifiedSystemdir in RPM5 either:

http://rpm5.org/

BTW, this package uses spaces in some of its filenames which requires
a change in the search command above:

find . -type f -print0 | sort -z | xargs -0 grep CheckUnifiedSystemdir

After Google came back, I did find out what the X-CheckUnifiedSystemdir
business is all about:

https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17

It seems that Fedora 17 merged all the /bin, /sbin, /usr/bin stuff
into /usr/bin. So, this is a major change. The X-CheckUnifiedSystemdir
is an artificial added dependency that guards against installing
packages that require a Fedora 17 directory layout to non-upgraded
systems that are using the old layout.

But, you are using Fedora 17, right? Is your /bin dir a symlink to
/usr/bin as it should be for Fedora 17?

I am curious as to how rpmlib even can "provide"
X-CheckUnifiedSystemdir on Fedora 17 systems given that I could not find
the string in either of the RPM source package releases. Is this found
only in the official Red Hat / Fedora releases of RPM? Red Hat, oh
what a tangled web we weave.


Cheers,

Mike Shell

Loading...