Unix administration - Problem compiling binutils

Author

Problem compiling binutils

Stan R.

2006-11-21, 1:19 pm

( Original thread: <egpre8014hc@news4.newsguy.com> )

When I try to compile binutils-2.17, it errors out with:

# CC=/usr/local/gcc4/bin/gcc ./configure --prefix=/usr/local/binutils

Moe Trin

2006-11-22, 7:22 pm

On Tue, 21 Nov 2006, in the Usenet newsgroup comp.unix.admin, in article
<ejvhha0129p@news4.newsguy.com>, Stan R. wrote:

>( Original thread: <egpre8014hc@news4.newsguy.com> )

and who knows where _that_ got spewed to - you've posted exactly the same
article to

alt.os.linux.redhat Tue, 21 Nov 2006 10:45:34 -0800
comp.os.linux.misc Tue, 21 Nov 2006 10:45:22 -0800
comp.unix.admin Tue, 21 Nov 2006 10:45:58 -0800
linux.redhat Tue, 21 Nov 2006 10:45:51 -0800

and who knows where else. Think it might be an idea to provide some
information like what operating system you are using? If it's a Linux,
which distribution and version?

>When I try to compile binutils-2.17, it errors out with:
>
> # CC=/usr/local/gcc4/bin/gcc ./configure --prefix=/usr/local/binutils

Do you have all of the prerequisites installed?

> In file included from /usr/local/include/signal.h:358,
> from .././libiberty/pex-unix.c:28:
> /usr/local/include/bits/sigthread.h:36: error:
> storage class specified for parameter 'type name'

This looks like your 'include's are screwed up, but without having any
idea what O/S you are trying to use, who knows. You posted to (at least)
two Red Hat groups, and Fedora Core 6 does include binutils-2.17.50.0.3-6
while earlier versions of Fedora had 2.15.x.x.x and 2.16.x.x.x, but I
don't see a binutils package in any of the errata since RH 7.2 in 2001.

Old guy

Stan R.

2006-11-24, 1:22 pm

Moe Trin wrote:
> On Tue, 21 Nov 2006, in the Usenet newsgroup comp.unix.admin, in
> article <ejvhha0129p@news4.newsguy.com>, Stan R. wrote:
>
>
> and who knows where _that_ got spewed to - you've posted exactly the
> same article to
>
> alt.os.linux.redhat Tue, 21 Nov 2006 10:45:34 -0800
> comp.os.linux.misc Tue, 21 Nov 2006 10:45:22 -0800
> comp.unix.admin Tue, 21 Nov 2006 10:45:58 -0800
> linux.redhat Tue, 21 Nov 2006 10:45:51 -0800
>
> and who knows where else. Think it might be an idea to provide some
> information like what operating system you are using? If it's a
> Linux, which distribution and version?

Sorry for multi posting. I rarely do this.

My system is originally RH 7.3, now Kernel:

2.4.20-20.7 #1 Mon Aug 18 14:56:30 EDT 2003 i686 unknown

>
> Do you have all of the prerequisites installed?

IT would appear so. Actually, Im updating my binutils as a
/prerequisite/ of glibc 2.4 of which I'm trying to install (in parallel
to the existing one for the time being so not to break existing programs
that rely on 2.1)

>
> This looks like your 'include's are screwed up, but without having any
> idea what O/S you are trying to use, who knows. You posted to (at
> least) two Red Hat groups, and Fedora Core 6 does include
> binutils-2.17.50.0.3-6 while earlier versions of Fedora had
> 2.15.x.x.x and 2.16.x.x.x, but I don't see a binutils package in any
> of the errata since RH 7.2 in 2001.

Yes and I just realized that it's using headers from /usr/local/include
instead of /usr/include

I will test with the includes set for /usr/include for the compile (if
this can be set in .configure)

--
Stan

Moe Trin

2006-11-26, 1:28 am

On Fri, 24 Nov 2006, in the Usenet newsgroup comp.unix.admin, in article
<ek75pk0a1k@news4.newsguy.com>, Stan R. wrote:

>My system is originally RH 7.3, now Kernel:
>
>2.4.20-20.7 #1 Mon Aug 18 14:56:30 EDT 2003 i686 unknown

Hmmm, where'd you find that? I ran 7.2 (and 7.3) for a long time, and
that's not on my list of updated kernels. At download.fedoralegacy.org,
the last kernel available is 2.4.20-30.7.legacy from February 2004.

[vbcol=seagreen]
>
>IT would appear so. Actually, Im updating my binutils as a
>/prerequisite/ of glibc 2.4 of which I'm trying to install (in parallel
>to the existing one for the time being so not to break existing programs
>that rely on 2.1)

You are REALLY a glutton for punishment. Do yourself a favor and get a
new distribution. Trying to update glibc is a critical mess, and it's
far easier to just pour on a new release. For perspective, 7.2 was

Version Released Name Last Updated "in service"
redhat-7.2 22 Oct 01 enigma 31 Dec 03/May 04 26 mo
redhat-7.3 6 May 02 valhalla 31 Dec 03* 20 mo
redhat-8.0 30 Sep 02 psyche 31 Dec 03/May 04 15 mo
redhat-9 7 Apr 03 shrike 30 Apr 04* 13 mo
fedora-core-1 5 Nov 03 yarrow 16 Sep 04/Jul 06 10 mo
fedora-core-2 18 May 04 tettnang 01 May 06/Jul 06 23 mo
fedora-core-3 8 Nov 04 heidelberg 22 Mar 06* 17 mo
fedora-core-4 13 Jun 05 stentz *
fedora-core-5 15 Mar 06 bordeaux
fedora-core-6 24 Oct 06

The '*' means some support is still available at fedoralegacy.org and that
does include 7.3 (though the support is poor and slow). The 'in-service'
figures are release date to the last 'non-legacy' errata.

Old guy

Stan R.

2006-11-27, 7:23 pm

Moe Trin wrote:
> On Fri, 24 Nov 2006, in the Usenet newsgroup comp.unix.admin, in
> article <ek75pk0a1k@news4.newsguy.com>, Stan R. wrote:
>
>
> Hmmm, where'd you find that? I ran 7.2 (and 7.3) for a long time, and
> that's not on my list of updated kernels. At
> download.fedoralegacy.org, the last kernel available is
> 2.4.20-30.7.legacy from February 2004.

I can't recall where, I just remember coming across it when I was once
scouring for updates.

>
>
> You are REALLY a glutton for punishment. Do yourself a favor and get
> a new distribution. Trying to update glibc is a critical mess, and
> it's
> far easier to just pour on a new release. For perspective, 7.2 was
>
> Version Released Name Last Updated "in
> service" redhat-7.2 22 Oct 01 enigma 31 Dec 03/May 04
> 26 mo redhat-7.3 6 May 02 valhalla 31 Dec 03*
> 20 mo redhat-8.0 30 Sep 02 psyche 31 Dec 03/May 04
> 15 mo redhat-9 7 Apr 03 shrike 30 Apr 04*
> 13 mo fedora-core-1 5 Nov 03 yarrow 16 Sep 04/Jul 06
> 10 mo fedora-core-2 18 May 04 tettnang 01 May 06/Jul 06
> 23 mo fedora-core-3 8 Nov 04 heidelberg 22 Mar 06*
> 17 mo fedora-core-4 13 Jun 05 stentz *
> fedora-core-5 15 Mar 06 bordeaux
> fedora-core-6 24 Oct 06
>
> The '*' means some support is still available at fedoralegacy.org and
> that does include 7.3 (though the support is poor and slow). The
> 'in-service' figures are release date to the last 'non-legacy' errata.
>
> Old guy

I know I could install a new version, though thre are many reasons I
cannot do that with this box. A lot of of work has gone into it, a lot
of cusotmized programs/daemons/module, many of which were compiled with
the original glibc (2.1)

For the time being it will be better to preserve the original glibc (2.4
is to be installed in a seperate directory - ie /usr/local/glibc-2.4/ -
so nothing that really exists will be broken.)

I'm not saying its bad to go to the newest, what is really wrong with
wanting to preserve a system? Why should one toss a well running system
for the sake of having a brand new distro? I mean, you can install a new
glibc (either as a replacement, which takes more work, or in parallel
like I'm doing) a well as upgrding/recompiling your kernel, and other
things are realatively easy to upgrade. For instance, it wasn't very
difficult to upgrade GCC and such.

--
Stan

Moe Trin

2006-11-29, 1:30 am

On Mon, 27 Nov 2006, in the Usenet newsgroup comp.unix.admin, in article
<ekfhe002ds5@news4.newsguy.com>, Stan R. wrote:

[vbcol=seagreen]
>I can't recall where, I just remember coming across it when I was once
>scouring for updates.

That sorta looks like a Red Hat kernel - what does 'rpm -qi kernel' tell
you? Do the version/release numbers and date match up?

>I know I could install a new version, though thre are many reasons I
>cannot do that with this box. A lot of of work has gone into it, a lot
>of cusotmized programs/daemons/module, many of which were compiled with
>the original glibc (2.1)

or the even earlier compat-glibc-6.2-2.1.3.2 I'd suspect.

>For the time being it will be better to preserve the original glibc (2.4
>is to be installed in a seperate directory - ie /usr/local/glibc-2.4/ -
>so nothing that really exists will be broken.)

Never tried making that big of a jump.

>I'm not saying its bad to go to the newest, what is really wrong with
>wanting to preserve a system? Why should one toss a well running system
>for the sake of having a brand new distro?

The main problem occurs if the box is IN ANY WAY reachable by possible
hostiles - which usually means network access. The old distributions are
not patched, so your security not depends on the attacker not believing
that anyone could be allowing something like that to be attacked by
yesteryear's r00tkit. If this were a 6.2 box, for example, there were
at least three worms in the wild that kicked in the door using holes in
the printer daemon, port mapper, and FTP server. Sure, you are probably
not running that, but what about sshd - several recent exploits there.
but is that older version you're running vulnerable?

You certainly can run old stuff - I have physical access to systems still
running a 1.2.13 kernel from 1995, but they are air-gap firewalled for a
reason.

Old guy

Stan R.

2006-11-29, 1:17 pm

Moe Trin wrote:
> On Mon, 27 Nov 2006, in the Usenet newsgroup comp.unix.admin, in
> article <ekfhe002ds5@news4.newsguy.com>, Stan R. wrote:
>
>
>
> That sorta looks like a Red Hat kernel - what does 'rpm -qi kernel'
> tell you? Do the version/release numbers and date match up?

# uname -a
Linux *** 2.4.20-20.7 #1 Mon Aug 18 14:56:30 EDT 2003 i686 unknown
(*** = host name stripped for security reason)

# rpm -qi kernel
Name : kernel Relocations: (not
relocateable)
Version : 2.4.20 Vendor: Red Hat, Inc.
Release : 20.7 Build Date: Mon 18 Aug 2003
12:08:40 PM PDT
Install date: Mon 10 Nov 2003 01:40:14 PM PST Build Host:
porky.devel.redhat.com
Group : System Environment/Kernel Source RPM:
kernel-2.4.20-20.7.src.rpm
Size : 32140732 License: GPL
[...]

And I'll probably be compiling a newer one soon, probably from tarballs
this time. Back when I updated to 2.4.20-20.7 kernel stuff was still
pretty new to me, though I have learned a great deal since then.

>
> or the even earlier compat-glibc-6.2-2.1.3.2 I'd suspect.

# rpm -qa | grep -i glibc | sort
compat-glibc-6.2-2.1.3.2 <----- good call
glibc-2.2.5-44
glibc-common-2.2.5-44
glibc-debug-2.2.5-44
glibc-debug-static-2.2.5-44
glibc-devel-2.2.5-44
glibc-kernheaders-2.4-7.16
glibc-utils-2.2.5-44
glibc-common-2.2.5-44

The main system glibc is 2.2.5-44, the highest I could go with RPMs back
then.

>
> Never tried making that big of a jump.

Thats why I'm keeping the new one seperate for now. I'm keeping GCC 2.96
for the old stuff (just in case and old stuff that refuses to
(re)compile on GCC 4), while GCC 4.1.1 will compile the newer glibc
things (which will be used more primarly)...

>
> The main problem occurs if the box is IN ANY WAY reachable by possible
> hostiles - which usually means network access. The old distributions
> are not patched, so your security not depends on the attacker not
> believing that anyone could be allowing something like that to be
> attacked by yesteryear's r00tkit.

I have this box pretty well secured. It is not directly exposed to the
internet. It sits behind a firewall-router, all of which is under my
control. And as I said I'll be updating my kernel soon and checking for
any other security updates.

> If this were a 6.2 box, for example, there were at least three
> worms in the wild that kicked in the door using holes in the
> printer daemon, port mapper, and FTP server.

I only allow a few certain services through (ssh, pop, smtp) the
firewall/router to the outside, and only on non standard ports (cept for
smtp, for obvious reasons.) things like Telnet and FTP are not mapped
through the router at all.

> Sure, you are probably not running that, but what about sshd
> - several recent exploits there. but is that older version you're
> running vulnerable?
# rpm -qa | grep -i ssh | sort
openssh-3.1p1-14
openssh-askpass-3.1p1-14
openssh-askpass-gnome-3.1p1-14
openssh-clients-3.1p1-14
openssh-server-3.1p1-14

# rpm -qi openssh-3.1p1-14
Name : openssh Relocations: (not
relocateable)
Version : 3.1p1 Vendor: Red Hat, Inc.
Release : 14 Build Date: Wed 17 Sep 2003
09:11:35 AM PDT
Install date: Mon 22 Sep 2003 08:48:33 AM PDT Build Host:
bugs.devel.redhat.com
[...]

I should probably see if theres an update for that.

> You certainly can run old stuff - I have physical access to systems
> still running a 1.2.13 kernel from 1995, but they are air-gap
> firewalled for a reason.

True. The box I'm working with is actually my dev box and also acts as a
private mail server for my house hold. It is for the most part locked
down from an internet point of view, with a tiny hand full of open
ports, 99.9% of which are on mapped to the outside as nonstandard
variations, simply as an extra step.

Also, over the many years of observations and lots of reading, it has
come to my understanding that a high percentage of "attacks" are for
some specific reason or another. Such as a grudge against someone, or
some entity. IE, DoS attacks. Most of which make use of an exploit.

Sure, there are random assaults, but even those are generally limited to
large hosting environments. It seems that most of the time, "hacker"
groups are more focused on more public targets then on small home based
dev systems, but at the same time on can never be to careful.

And extra prudence never hurt anyone. :-)

--
Stan

Moe Trin

2006-11-30, 7:24 pm

On Wed, 29 Nov 2006, in the Usenet newsgroup comp.unix.admin, in article
<ekkeim071q@news4.newsguy.com>, Stan R. wrote:
>Moe Trin wrote:

>
># uname -a
>Linux *** 2.4.20-20.7 #1 Mon Aug 18 14:56:30 EDT 2003 i686 unknown
>(*** = host name stripped for security reason)
>
># rpm -qi kernel
>Name : kernel Relocations: (not
>relocateable)
>Version : 2.4.20 Vendor: Red Hat, Inc.
>Release : 20.7 Build Date: Mon 18 Aug 2003

Obviously Red Hat. It's just not on any of my Updates archive listings.

>And I'll probably be compiling a newer one soon, probably from tarballs
>this time. Back when I updated to 2.4.20-20.7 kernel stuff was still
>pretty new to me, though I have learned a great deal since then.

[compton ~]$ finger kernel@kernel.org
[kernel.org]
The latest stable version of the Linux kernel is: 2.6.19
The latest 2.4 version of the Linux kernel is: 2.4.33.4
The latest prepatch for the 2.4 Linux kernel tree is: 2.4.34-pre6
The latest 2.2 version of the Linux kernel is: 2.2.26
The latest prepatch for the 2.2 Linux kernel tree is: 2.2.27-rc2
The latest -mm patch to the stable Linux kernels is: 2.6.19-rc6-mm2
[compton ~]$

That's somewhat deceiving, as 2.6.16.33, 2.6.16.34, 2.6.18.4, and 2.6.19
were released in the past ten days. The 2.4.x tree is much more stable, with
2.4.33.3 released back at the end of August, and 2.4.33.4 released about 11
days ago. 2.4.34 may be going to a .rc1 in a week or so. The patchlog is
comparatively small.

-rw-rw-r-- 1 536 536 8937 Nov 19 20:13 patch-2.4.34.log

>The main system glibc is 2.2.5-44, the highest I could go with RPMs back
>then.

That was probably for RH7.3 but usable on 7.2 and 7.1. The highest I
see on download.fedoralegacy.com right now is 2.2.5-44.legacy.8 from March.

>I have this box pretty well secured. It is not directly exposed to the
>internet. It sits behind a firewall-router, all of which is under my
>control. And as I said I'll be updating my kernel soon and checking for
>any other security updates.

You'd almost have to be checking with the application authors. The stuff
that's available on download.fedoralegacy.com is generally backported from
the "current" distribution, but they tend to be quite slow. For example,
FC5 and FC6 got a massive update of php stuff on 6 November, but it hasn't
trickled down to FC4, never mind back to 9 or 7.3. But then, another
place to be watching is Bugtraq.

>I only allow a few certain services through (ssh, pop, smtp) the
>firewall/router to the outside, and only on non standard ports (cept for
>smtp, for obvious reasons.) things like Telnet and FTP are not mapped
>through the router at all.

That helps tremendously. sendmail-8.11.6? There is an update from
September on fedoralegacy for 7.3, but it looks as if it might be
specific to 7.3 rather than 7.x. Sendmail.org says that they aren't
maintaining 8.12.x and earlier (current is 8.13.8 from August).

># rpm -qa | grep -i ssh | sort
>openssh-3.1p1-14

That was the last update for 7.2, and 7.x, but they were also the last
distribution to use 3.1. 3.5 has been updated several times since then,
and FC5/6 were updated earlier this month.

>Also, over the many years of observations and lots of reading, it has
>come to my understanding that a high percentage of "attacks" are for
>some specific reason or another. Such as a grudge against someone, or
>some entity. IE, DoS attacks. Most of which make use of an exploit.

I'm not sure about that. Certainly everyone that is logging failed login
attempts on their SSH servers on port 22 would have a different story.
I moved mine to a different port about 3 years ago, and switched to a
port-knocking firewall setup (attempt to connect to port $FOO, which
opens the firewall for that host to access the SSH server on port $BAR
for one minute). And that's even with the server firewalled to only
accept connections from a restricted range of addresses.

>Sure, there are random assaults, but even those are generally limited to
>large hosting environments. It seems that most of the time, "hacker"
>groups are more focused on more public targets then on small home based
>dev systems, but at the same time on can never be to careful.

Much of the stuff I see reported are worms on zombie boxes. Actual crack
attempts where someone is setting at the keyboard pounding away are quite
rare, probably because the software is improving constantly and it's a
lot harder to do now.

>And extra prudence never hurt anyone. :-)

"Paranoia comes from experience - and is not necessarily a bad thing."

Old guy