FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 09-24-2008, 07:39 PM
Maarten
 
Default Problem building statically linked e2fsprogs

Hi List,

I'm in a bit of trouble. A server or ours has a broken e2fsck because it
is linked to a library version that doesn't exist anymore. Yes, I should
have fixed this before-- but alas, I obviously didn't... :-(


Tonight, the server had a hard crash and the only way to get it up again
(no IT people at the location) was by talking someone through a process
wherein I replaced e2fsck by /bin/true so it would not complain at boot
(where it would remain in an inaccesible state, with a panic shell).

So it is up and running again. All /seems/ fine, for now at least...

However, we must certainly assume the disk is in a dirty state so I
really do not want to do more than the bare minimum to it. So emerging
isn't a real good idea. Even then, I still tried. But it seems that
-despite the state of the bug(s) about e2fsprogs which are in
{resolved,fixed} state I cannot get e2fsprogs to compile AT ALL.

I've tried 10 different versions, etc., etc. To no avail. (Error below)
I believe looking at google and forum entries e2fsprogs on gentoo has a
*terrible* track record of late by the way, but maybe that is just me.


Things get more complicated fast, because this server has a CHOST i386
therefore -unless someone tells me otherwise- I cannot update glibc, and
practise has taught us to not upgrade packages/libs left and right
because you invariably end up, at revdep-rebuild time, with dependencies
which are unsolvable "unless...". And it is the "unless" (meaning emerge
-e world) which is unacceptable for this (or any production-) server...


It crashes on the "../../lib/libuuid.so: undefined reference to
`___tls_get_addr'". The two bugzilla entries that apply basically tell
me to rebuild from scratch, which I cannot do for reasons outlined
above. (http://bugs.gentoo.org/204102 & http://bugs.gentoo.org/232743)



-in short-
So as to avoid any further messing with the box I opted for building a
statically linked e2fsck binary on another box and copy it. However, I'm
having no luck with that. I can build static binaries fine for other
packages, but e2fsprogs refuses to build a static version.

(It builds, but the result is still dynamically linked)

Can anyone help with this ? Does this package not support building
static ? The USE flag is there for a reason, no? Did I take the wrong
approach here ? What is up with this [damn] package ?!?



# Grep works fine...
maarten@thoughtpad ~ $ ldd /bin/grep
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/libc.so.6 (0xb7e42000)
/lib/ld-linux.so.2 (0xb7f96000)

thoughtpad ~ # USE="static" emerge -v grep
[snip]

maarten@thoughtpad ~ $ ldd /bin/grep
not a dynamic executable

# But e2fsprogs doesn't...

maarten@thoughtpad ~ $ ldd /sbin/e2fsck
linux-gate.so.1 => (0xffffe000)
libext2fs.so.2 => /lib/libext2fs.so.2 (0xb7ea1000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7e9d000)
libblkid.so.1 => /lib/libblkid.so.1 (0xb7e93000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb7e8e000)
libe2p.so.2 => /lib/libe2p.so.2 (0xb7e87000)
libc.so.6 => /lib/libc.so.6 (0xb7d55000)
/lib/ld-linux.so.2 (0xb7ee8000)

thoughtpad ~ # USE="static" emerge -v e2fsprogs
[ebuild R ] sys-fs/e2fsprogs-1.40.9 USE="nls static*" 0 kB
[snip]
Enabling ELF shared libraries
[snip]
checking whether linker accepts -static... yes
[snip]
>>> Completed installing e2fsprogs-1.40.9 into
/var/tmp/portage/sys-fs/e2fsprogs-1.40.9/image/


# After that, no change, however...
maarten@thoughtpad ~ $ ldd /sbin/e2fsck
linux-gate.so.1 => (0xffffe000)
libext2fs.so.2 => /lib/libext2fs.so.2 (0xb7f7f000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7f7b000)
libblkid.so.1 => /lib/libblkid.so.1 (0xb7f71000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb7f6c000)
libe2p.so.2 => /lib/libe2p.so.2 (0xb7f65000)
libc.so.6 => /lib/libc.so.6 (0xb7e33000)
/lib/ld-linux.so.2 (0xb7fc6000)

maarten@thoughtpad ~ $ ls -la /sbin/e2fsck
-rwxr-xr-x 1 root root 159896 Sep 24 21:17 /sbin/e2fsck

maarten@thoughtpad ~ $ file /sbin/e2fsck
/sbin/e2fsck: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped



Thanks in advance for any insights...
Maarten
 
Old 09-24-2008, 07:59 PM
Albert Hopkins
 
Default Problem building statically linked e2fsprogs

On Wed, 2008-09-24 at 21:39 +0200, Maarten wrote:
> Hi List,
>
[...]
>
> # Grep works fine...
> maarten@thoughtpad ~ $ ldd /bin/grep
> linux-gate.so.1 => (0xffffe000)
> libc.so.6 => /lib/libc.so.6 (0xb7e42000)
> /lib/ld-linux.so.2 (0xb7f96000)
>
> thoughtpad ~ # USE="static" emerge -v grep
> [snip]
>
> maarten@thoughtpad ~ $ ldd /bin/grep
> not a dynamic executable
>
> # But e2fsprogs doesn't...
>
> maarten@thoughtpad ~ $ ldd /sbin/e2fsck
> linux-gate.so.1 => (0xffffe000)
> libext2fs.so.2 => /lib/libext2fs.so.2 (0xb7ea1000)
> libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7e9d000)
> libblkid.so.1 => /lib/libblkid.so.1 (0xb7e93000)
> libuuid.so.1 => /lib/libuuid.so.1 (0xb7e8e000)
> libe2p.so.2 => /lib/libe2p.so.2 (0xb7e87000)
> libc.so.6 => /lib/libc.so.6 (0xb7d55000)
> /lib/ld-linux.so.2 (0xb7ee8000)
>
> thoughtpad ~ # USE="static" emerge -v e2fsprogs
> [ebuild R ] sys-fs/e2fsprogs-1.40.9 USE="nls static*" 0 kB
> [snip]
> Enabling ELF shared libraries
> [snip]
> checking whether linker accepts -static... yes
> [snip]
> >>> Completed installing e2fsprogs-1.40.9 into
> /var/tmp/portage/sys-fs/e2fsprogs-1.40.9/image/
>
> # After that, no change, however...
> maarten@thoughtpad ~ $ ldd /sbin/e2fsck
> linux-gate.so.1 => (0xffffe000)
> libext2fs.so.2 => /lib/libext2fs.so.2 (0xb7f7f000)
> libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7f7b000)
> libblkid.so.1 => /lib/libblkid.so.1 (0xb7f71000)
> libuuid.so.1 => /lib/libuuid.so.1 (0xb7f6c000)
> libe2p.so.2 => /lib/libe2p.so.2 (0xb7f65000)
> libc.so.6 => /lib/libc.so.6 (0xb7e33000)
> /lib/ld-linux.so.2 (0xb7fc6000)
>
The grep package has a "static" USE flag. e2fsprogs does not. So
enabling the static USE flag has no effect on e2fsprogs.

The easiest (easier?) thing to do would be to compile e2fsprogs
statically by hand and copy over the resulting binary

# tar zxvf /path/to/e2fsprogs-1.x.x.tar.gz
# cd e2fsprogs-1.x.x
# ./configure --enable-static
# make
# ldd e2fsck/e2fsck
linux-gate.so.1 => (0xb8033000)
libc.so.6 => /lib/libc.so.6 (0xb7edb000)
/lib/ld-linux.so.2 (0xb8034000)
 
Old 09-24-2008, 08:18 PM
Daniel Pielmeier
 
Default Problem building statically linked e2fsprogs

Maarten schrieb am 24.09.2008 21:39:
Can anyone help with this ? Does this package not support building
static ? The USE flag is there for a reason, no? Did I take the wrong
approach here ? What is up with this [damn] package ?!?


http://bugs.gentoo.org/show_bug.cgi?id=232115 gives some information
about this issue.


Regards,

Daniel
 
Old 09-24-2008, 08:34 PM
Maarten
 
Default Problem building statically linked e2fsprogs

Albert Hopkins wrote:

On Wed, 2008-09-24 at 21:39 +0200, Maarten wrote:

Hi List,


[...]

# Grep works fine...
maarten@thoughtpad ~ $ ldd /bin/grep
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/libc.so.6 (0xb7e42000)
/lib/ld-linux.so.2 (0xb7f96000)

thoughtpad ~ # USE="static" emerge -v grep
[snip]

maarten@thoughtpad ~ $ ldd /bin/grep
not a dynamic executable

# But e2fsprogs doesn't...

maarten@thoughtpad ~ $ ldd /sbin/e2fsck
linux-gate.so.1 => (0xffffe000)
libext2fs.so.2 => /lib/libext2fs.so.2 (0xb7ea1000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7e9d000)
libblkid.so.1 => /lib/libblkid.so.1 (0xb7e93000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb7e8e000)
libe2p.so.2 => /lib/libe2p.so.2 (0xb7e87000)
libc.so.6 => /lib/libc.so.6 (0xb7d55000)
/lib/ld-linux.so.2 (0xb7ee8000)

thoughtpad ~ # USE="static" emerge -v e2fsprogs
[ebuild R ] sys-fs/e2fsprogs-1.40.9 USE="nls static*" 0 kB
[snip]
Enabling ELF shared libraries
[snip]
checking whether linker accepts -static... yes
[snip]
>>> Completed installing e2fsprogs-1.40.9 into
/var/tmp/portage/sys-fs/e2fsprogs-1.40.9/image/


# After that, no change, however...
maarten@thoughtpad ~ $ ldd /sbin/e2fsck
linux-gate.so.1 => (0xffffe000)
libext2fs.so.2 => /lib/libext2fs.so.2 (0xb7f7f000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7f7b000)
libblkid.so.1 => /lib/libblkid.so.1 (0xb7f71000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb7f6c000)
libe2p.so.2 => /lib/libe2p.so.2 (0xb7f65000)
libc.so.6 => /lib/libc.so.6 (0xb7e33000)
/lib/ld-linux.so.2 (0xb7fc6000)


The grep package has a "static" USE flag. e2fsprogs does not. So
enabling the static USE flag has no effect on e2fsprogs.


Ehm, how do you figure that? It surely displays the "static" USE flag:

thoughtpad ~ # emerge -pv e2fsprogs

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] sys-fs/e2fsprogs-1.40.9 USE="nls -static" 0 kB

So I would assume at this point the package is broken in this respect.


The easiest (easier?) thing to do would be to compile e2fsprogs
statically by hand and copy over the resulting binary


Good idea... well, maybe...


# tar zxvf /path/to/e2fsprogs-1.x.x.tar.gz
# cd e2fsprogs-1.x.x
# ./configure --enable-static
# make
# ldd e2fsck/e2fsck
linux-gate.so.1 => (0xb8033000)
libc.so.6 => /lib/libc.so.6 (0xb7edb000)
/lib/ld-linux.so.2 (0xb8034000)


Ehm, exactly. So yes, it uses less libraries than before, but in no way
is this a real statically linked binary:


# ldd e2fsck/e2fsck
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/libc.so.6 (0xb7e32000)
/lib/ld-linux.so.2 (0xb7f86000)

# file e2fsck/e2fsck
e2fsck/e2fsck: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped


However, since this might still perform much better, I tested it...
and indeed, it does the job (despite different glibc versions between
the build host and the bad server):


broken_server ~ # /sbin/e2fsck
e2fsck: error while loading shared libraries: libcom_err.so.2: cannot
handle TLS data


broken_server ~ # ./e2fsck
Usage: ./e2fsck [-panyrcdfvstDFSV] [-b superblock] [-B blocksize]
[-I inode_buffer_blocks] [-P process_inode_size]
[-l|-L bad_blocks_file] [-C fd] [-j external_journal]
[-E extended-options] device

Thank you,
Maarten
 
Old 09-24-2008, 09:04 PM
Maarten
 
Default Problem building statically linked e2fsprogs

Daniel Pielmeier wrote:

Maarten schrieb am 24.09.2008 21:39:
Can anyone help with this ? Does this package not support building
static ? The USE flag is there for a reason, no? Did I take the wrong
approach here ? What is up with this [damn] package ?!?


http://bugs.gentoo.org/show_bug.cgi?id=232115 gives some information
about this issue.


Ah, that explains it. Still, not too nice a fix they did on this.
Instead of really addressing the issue, simply "dropped USE=static".
(But what do I know, maybe it's truely quite complicated)

Anyway, I'll shut up before my frustration of today airs too much. :-)

Regards,
Maarten
 
Old 09-25-2008, 03:23 PM
Albert Hopkins
 
Default Problem building statically linked e2fsprogs

On Wed, 2008-09-24 at 22:34 +0200, Maarten wrote:
> Albert Hopkins wrote:

> > The grep package has a "static" USE flag. e2fsprogs does not. So
> > enabling the static USE flag has no effect on e2fsprogs.
>
> Ehm, how do you figure that? It surely displays the "static" USE flag:
>
> thoughtpad ~ # emerge -pv e2fsprogs
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild R ] sys-fs/e2fsprogs-1.40.9 USE="nls -static" 0 kB
>

Sorry, I am using a later version of e2fsprogs that does not have the
"static" USE flag. I didn't know that earlier versions did have it but,
as another poster said, there is a bug for the package where use of the
"static" flag doesn't work.

> So I would assume at this point the package is broken in this respect.
>
> > The easiest (easier?) thing to do would be to compile e2fsprogs
> > statically by hand and copy over the resulting binary
>
> Good idea... well, maybe...
>
> > # tar zxvf /path/to/e2fsprogs-1.x.x.tar.gz
> > # cd e2fsprogs-1.x.x
> > # ./configure --enable-static
> > # make
> > # ldd e2fsck/e2fsck
> > linux-gate.so.1 => (0xb8033000)
> > libc.so.6 => /lib/libc.so.6 (0xb7edb000)
> > /lib/ld-linux.so.2 (0xb8034000)
>
> Ehm, exactly. So yes, it uses less libraries than before, but in no way
> is this a real statically linked binary:
>
This is true, but it is sufficiently static enough. Pretty much any
Linux shipped within the past 10 years or so has GNU libc 2 .x (libc 6),
so the dependencies are satisfied.

If you really really need static then:

# cd e2fsck
# make e2fsck.static
# ldd e2fsck.static
not a dynamic executable
 
Old 09-25-2008, 06:42 PM
Maarten
 
Default Problem building statically linked e2fsprogs

Albert Hopkins wrote:

On Wed, 2008-09-24 at 22:34 +0200, Maarten wrote:

Albert Hopkins wrote:



# ldd e2fsck/e2fsck
linux-gate.so.1 => (0xb8033000)
libc.so.6 => /lib/libc.so.6 (0xb7edb000)
/lib/ld-linux.so.2 (0xb8034000)
Ehm, exactly. So yes, it uses less libraries than before, but in no way
is this a real statically linked binary:



This is true, but it is sufficiently static enough. Pretty much any
Linux shipped within the past 10 years or so has GNU libc 2 .x (libc 6),
so the dependencies are satisfied.


Ah ? Are there no major difference between recent glibc versions ? I did
not know that versions are so much compatible.



If you really really need static then:


No, it worked. However, the com_err library gave us no end of grief
today. Mount was broken, fetchmail was broken, etc. And reemerging
com_err yielded no results, the error


"libcom_err.so.2: cannot handle TLS data"

persisted like a real plague. I finally fixed it, but am unsure how. I
think reemerging an ancient version together with ss in the exact same
version did the trick. But something is badly broken-- com_err insists
on running revdep-rebuild, but running that does NOT report problems
related to any of the problematic binaries... :-(

As witnessed by, for instance, this:

master sys-libs # mkfs.ext2 --help
mkfs.ext2: error while loading shared libraries: libuuid.so.1: cannot
handle TLS data


master sys-libs # revdep-rebuild --pretend --ignore
Checking reverse dependencies...

<snip>

Checking dynamic linking consistency...
broken /usr/lib/apache2-extramodules/libphp4.so (requires libpdf.so.2)
broken /usr/X11R6/lib/apache2-extramodules/libphp4.so (requires
libpdf.so.2)
broken /opt/blackdown-jre-1.4.2.01/lib/i386/libjsoundalsa.so
(requires libasound.so.2)
broken /opt/blackdown-jdk-1.4.2.03/jre/lib/i386/libjsoundalsa.so
(requires libasound.so.2)

done.

<snip>

All prepared. Starting rebuild...
emerge --oneshot --nodeps --pretend --ignore
=dev-java/blackdown-jdk-1.4.2.03-r12 =dev-java/blackdown-jre-1.4.2.01-r1
=dev-php/mod_php-4.3.10



In other words, no sign at all about this broken stuff. Same goes for
fetchmail, but that has been reemerged so I cannot reproduce it anymore.


All in all, it has been a VERY BAD week for Gentoo from my perspective.
Which is a shame really, because I _want_ to love Gentoo... But... :-(


Another very bad thing which really bites us with our older Gentoo
servers is the fact that having the CHOST set to *i386-* seems to
harshly break any hope of a viable upgrade path. Figure that-- the main
reason we chose Gentoo was, in fact, the possibility to seamlessly
upgrade and thus stay up to date forever. That CHOST has killed that
hope. Now IF someone back in 2004 had mentioned (or had known?) this
fact we would not have fallen in this trap. But now, our management is
pushing real hard to switch to redhat or some other 'terrible choice'.
I really really get angry and disappointed whenever I think about this
situation nad how trivially simple it could have been avoided... :-(


I even think that the com_err thingy has some relations to this. Because
'emerge world' has been effectively cut off for us, many many upgrades
can be done only halfway, and these library problems indirectly stem
from that.


If someone knows a solution to the CHOST=i386 problem that doesn't
involve an 'emerge --emptytree world', I would LOVE to hear it...!


Thanks,
Maarten
 
Old 09-25-2008, 07:02 PM
Erik Hahn
 
Default Problem building statically linked e2fsprogs

I don't know much about servers so this might be rather stupid, but:
What about dismounting the driver and fsck'ing it in another computer?

-Erik
--
hackerkey://v4sw5hw2ln3pr5ck0ma2u7LwXm4l7Gi2e2t4b7Ken4/7a16s0r1p-5.62/-6.56g5OR
 
Old 09-25-2008, 07:57 PM
Stroller
 
Default Problem building statically linked e2fsprogs

On 25 Sep 2008, at 20:02, Erik Hahn wrote:


I don't know much about servers so this might be rather stupid, but:
What about dismounting the driver and fsck'ing it in another computer?


I think the problem is that the drive (the server) is in a physically
remote location.
(from the original message: "... the only way to get it up again (no
IT people at the location) was by talking someone through a process...")


Nevertheless, one can't help thinking the machine could be booted from
a Knoppix CD.


Stroller.
 
Old 09-30-2008, 06:42 AM
Michal 'vorner' Vaner
 
Default Problem building statically linked e2fsprogs

Hello

(Original post too long to quote)

How about building it dynamically and taking all the needed libraries as
well? I had similar problem (I needed fsck.ext3 in my init ramdisk) and
I just used ldd to find out what does it need.

You can test if it has enough by copying the thinks indo a directory,
chrooting there and trying out if it runs.

I hope it helps

--
When all else fails, EAT!!!

Michal 'vorner' Vaner
 

Thread Tools




All times are GMT. The time now is 05:47 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org