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 <garb...@gmail.com> wrote: > On 1 August 2010 08:30, pancake <panc...@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 >
