Discussion:
[coreutils] stdbuf util prevents easy static building of coreutils
Mike Frysinger
2010-07-19 19:48:18 UTC
Permalink
the semi-recent addition of the stdbuf util (and more importantly the
libstdbuf.so library) prevents easy static compilation of coreutils.
previously, i would do:
LDFLAGS=-static ./configure

now though on a gcc system i get:
CCLD libstdbuf.so
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/crtbeginT.o: relocation R_X86_64_32
against `__DTOR_END__' can not be used when making a shared object; recompile
with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/crtbeginT.o: could not read symbols:
Bad value
collect2: ld returned 1 exit status
make[3]: *** [libstdbuf.so] Error 1

looking at the configure.ac script, i thought this might work:
./configure --enable-no-install-program=stdbuf,libstdbuf.so
but alas, it does not

so what route shall we go here ? libtool obviously would workaround this, but
introduce quite a bit of complexity otherwise, so that isnt fun. should i
just extend the no-install-program option to support stdbuf (and implicitly,
libstdbuf.so) ? other ideas ?
-mike
Jim Meyering
2010-07-19 20:58:31 UTC
Permalink
Post by Mike Frysinger
the semi-recent addition of the stdbuf util (and more importantly the
libstdbuf.so library) prevents easy static compilation of coreutils.
LDFLAGS=-static ./configure
CCLD libstdbuf.so
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/crtbeginT.o: relocation R_X86_64_32
against `__DTOR_END__' can not be used when making a shared object; recompile
with -fPIC
Bad value
collect2: ld returned 1 exit status
make[3]: *** [libstdbuf.so] Error 1
./configure --enable-no-install-program=stdbuf,libstdbuf.so
but alas, it does not
Hi Mike,

My first reflex was that simply excluding stdbuf should suffice:

./configure --enable-no-install-program=stdbuf

but I haven't looked at what that would imply on the
implementation front. Wouldn't want to unduly specialize...
Post by Mike Frysinger
so what route shall we go here ? libtool obviously would workaround this, but
introduce quite a bit of complexity otherwise, so that isnt fun. should i
just extend the no-install-program option to support stdbuf (and implicitly,
libstdbuf.so) ?
That sounds fine.
Mike Frysinger
2010-07-20 06:02:49 UTC
Permalink
Post by Mike Frysinger
Post by Mike Frysinger
./configure --enable-no-install-program=stdbuf,libstdbuf.so
but alas, it does not
./configure --enable-no-install-program=stdbuf
but I haven't looked at what that would imply on the
implementation front. Wouldn't want to unduly specialize...
i'm sure you saw the bugs-coreutils report, so just following up for mail
archives completeness ...

stdbuf does disable fine, but libstdbuf.so does not. it is always enabled for
gcc targets. so i posted a patch to make the latter conditional on the
former.
-mike

Loading...