Re: [dev] How about sta.li ?

Dunno about gold. Url? But well... Being c++ i farly prefer to use radare apis. Which are saner and C.

Read between lines..

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

> 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.
> Cheers,
> Anselm
>
Received on Mon Aug 02 2010 - 20:04:00 CEST