coreutils
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]