Re: [dev] How about sta.li ?

On 2 August 2010 19:04, pancake <pancake_AT_youterm.com> wrote:
> Dunno about gold. Url? But well... Being c++ i farly prefer to use radare apis. Which are saner and C.

http://google-opensource.blogspot.com/2008/04/gold-google-releases-new-and-improved.html

It's part of binutils nowadays:

http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/?cvsroot=src

> On 01/08/2010, at 20:15, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
>
>> On 1 August 2010 08:30, pancake <pancake_AT_youterm.com> wrote:
>>> Cant this be done with a wraper shellscript ? Messing with gnu ld is like a
>>> near death experience.
>>
>> Indeed, it can be done using some shell scripts but it'll be quite
>> slow. My initial efforts were gold related, though that's written in
>> C++ which is a bit annoying.
> Indeed
>>
>>> Using r2libs can also be possible.. But would be more complex than a few loc
>>> shellscript.
>>>
>>> That's what libtool does ( between many other silly things) which we dont
>>> need, and certainly i would prefer to be cmpiler agnostic and be able to use
>>> tcc or llvm.
>>
>> Afaik gold is compiler agnostic as long as ELF is involved.
>
> Each compiler generates its own .o files.. Doesnt means to be compatible betweeen versions or distributiobs.

Well true, but gcc and llvm have gold integration afaik.

>>> Inthe other side u can do this by specifying --enable-static and
>>> --dudable-shared in any prj using autofools (webkit, X11 ..)
>>>
>>> I dont get the point with the 'tee like'
>>
>> With tee-like I mean that the static libraries are created in a
>> different place for later linking lookups, but also to support the
>> normal behavior in order that vanilla builds run through smoothly,
>> since they usually check for libsomething.so's to carry on.
>>
>> A simplified example, imagine:
>>
>>  ld -o libsomething.so foo.o bar.o baz.o
>>
>> The tee-like behavior would result in libsomething.so and some archive
>> in /different/place/lib/libsomething.a
>>
> This implicit stuff looks weird to me.
>> If an executable is involed:
>>
>>  ld -o something /lib/crt0.o libsomething.so
>>
>> we perform a static link and ignore all .so's involved and look for
>> /different/place/lib/libsomething.a instead.
>>
>
> But..why you need a .so? I still dont get the point to do it that complicated without any benefit, because all buildings will be static, not dynamic.

Having both, hidden static libs and official shared libs enables
autogenerated Makefiles to not break, because they aren't aware of the
static result.

>> With this in place we should get quite far with building most sta.li
>> dependencies and executables.
>>
> I dont think this is necessary to compile stali.

It's not necessary to compile the core bits of stali, but it's quite
neat to compile new packages without changes to the build
configuration, which is the only intention behind all this.

Cheers,
Anselm
Received on Fri Aug 06 2010 - 10:21:09 CEST