[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [coreutils] stdbuf util prevents easy static building of coreutils
From: |
Jim Meyering |
Subject: |
Re: [coreutils] stdbuf util prevents easy static building of coreutils |
Date: |
Mon, 19 Jul 2010 22:58:31 +0200 |
Mike Frysinger wrote:
> 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
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...
> 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.