<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/1.5.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Concurrent linking</title>
	<link>http://www.airs.com/blog/archives/165</link>
	<description>Ian Lance Taylor</description>
	<pubDate>Sat, 19 Jul 2008 06:50:14 +0000</pubDate>
	<generator>http://wordpress.org/?v=1.5.2</generator>

	<item>
 		<title>Comment on Concurrent linking by: Ian Lance Taylor</title>
		<link>http://www.airs.com/blog/archives/165#comment-13025</link>
		<pubDate>Fri, 02 May 2008 07:34:47 +0000</pubDate>
		<guid>http://www.airs.com/blog/archives/165#comment-13025</guid>
					<description>Thanks for the note.  It's not necessary to work with every build system, and it's not necessary to work from the start of the build--it's OK to start the concurrent link at the point where you know the set of objects.  I'm not proposing associating a link with an object file--I agree that that can't work.</description>
		<content:encoded><![CDATA[	<p>Thanks for the note.  It&#8217;s not necessary to work with every build system, and it&#8217;s not necessary to work from the start of the build&#8211;it&#8217;s OK to start the concurrent link at the point where you know the set of objects.  I&#8217;m not proposing associating a link with an object file&#8211;I agree that that can&#8217;t work.
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Concurrent linking by: DonLindsay</title>
		<link>http://www.airs.com/blog/archives/165#comment-13006</link>
		<pubDate>Thu, 01 May 2008 23:49:54 +0000</pubDate>
		<guid>http://www.airs.com/blog/archives/165#comment-13006</guid>
					<description>On second thought, we're both wrong.

There is a problem with wanting to know a set of objects up front.  Larger build systems tend to do a lot of subsystem discovery, and may be well into the build proper before discovery is completed. 

And the problem with associating a link  with an object file, is that a given object file may have multiple destinations.</description>
		<content:encoded><![CDATA[	<p>On second thought, we&#8217;re both wrong.</p>
	<p>There is a problem with wanting to know a set of objects up front.  Larger build systems tend to do a lot of subsystem discovery, and may be well into the build proper before discovery is completed. </p>
	<p>And the problem with associating a link  with an object file, is that a given object file may have multiple destinations.
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Concurrent linking by: Ian Lance Taylor</title>
		<link>http://www.airs.com/blog/archives/165#comment-12959</link>
		<pubDate>Thu, 01 May 2008 01:22:11 +0000</pubDate>
		<guid>http://www.airs.com/blog/archives/165#comment-12959</guid>
					<description>I think you *could* use some sort of inotify based code, provided you invoked the linker with the set of objects it had to wait for.  I think you would have to first remove all the objects which were going to change, to avoid a race condition.  Of course this approach wouldn't work well with -L -l.

Or, yes, a named pipe would work.  My main concern with that approach is that it would require bigger changes to the build system.</description>
		<content:encoded><![CDATA[	<p>I think you *could* use some sort of inotify based code, provided you invoked the linker with the set of objects it had to wait for.  I think you would have to first remove all the objects which were going to change, to avoid a race condition.  Of course this approach wouldn&#8217;t work well with -L -l.</p>
	<p>Or, yes, a named pipe would work.  My main concern with that approach is that it would require bigger changes to the build system.
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Concurrent linking by: DonLindsay</title>
		<link>http://www.airs.com/blog/archives/165#comment-12954</link>
		<pubDate>Thu, 01 May 2008 00:15:19 +0000</pubDate>
		<guid>http://www.airs.com/blog/archives/165#comment-12954</guid>
					<description>I'm a fan of inotify, but it's wrong for this. Large build systems leave multiple executables, not one, so the build system has to say which object file goes to which link pipeline.

Also, each of the plural link invocations has its own parameters, which I don't think you want to smuggle to it via the GCC invocations.

So I'd give gold some sort of --daemon (OK, --concurrent) flag which makes it leave a named pipe that it then listens on. The build system could follow each GCC invocation with an echo to a pipe of the new object file's name. This (or some similar scheme)  allows multiple consumer invocations, all loosely coupled to the set of producers,  without having to write new locking and buffering code.

How would the build system know that a link daemon was done? Via a 'finish' command?</description>
		<content:encoded><![CDATA[	<p>I&#8217;m a fan of inotify, but it&#8217;s wrong for this. Large build systems leave multiple executables, not one, so the build system has to say which object file goes to which link pipeline.</p>
	<p>Also, each of the plural link invocations has its own parameters, which I don&#8217;t think you want to smuggle to it via the GCC invocations.</p>
	<p>So I&#8217;d give gold some sort of &#8211;daemon (OK, &#8211;concurrent) flag which makes it leave a named pipe that it then listens on. The build system could follow each GCC invocation with an echo to a pipe of the new object file&#8217;s name. This (or some similar scheme)  allows multiple consumer invocations, all loosely coupled to the set of producers,  without having to write new locking and buffering code.</p>
	<p>How would the build system know that a link daemon was done? Via a &#8216;finish&#8217; command?
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Concurrent linking by: Ian Lance Taylor</title>
		<link>http://www.airs.com/blog/archives/165#comment-12258</link>
		<pubDate>Mon, 07 Apr 2008 23:33:16 +0000</pubDate>
		<guid>http://www.airs.com/blog/archives/165#comment-12258</guid>
					<description>fprog: thanks for the examples.  Do they still work if the .o file is up-to-date?  What invokes the prelink step in that case?

I don't know of anybody working on an ARM port yet.

astrange: ZeroLink is different from concurrent linking.  ZeroLink postpones the linking until runtime.  Concurrent linking does a more-or-less regular link, it just does it at the same time as the compilation.</description>
		<content:encoded><![CDATA[	<p>fprog: thanks for the examples.  Do they still work if the .o file is up-to-date?  What invokes the prelink step in that case?</p>
	<p>I don&#8217;t know of anybody working on an ARM port yet.</p>
	<p>astrange: ZeroLink is different from concurrent linking.  ZeroLink postpones the linking until runtime.  Concurrent linking does a more-or-less regular link, it just does it at the same time as the compilation.
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Concurrent linking by: astrange</title>
		<link>http://www.airs.com/blog/archives/165#comment-12255</link>
		<pubDate>Mon, 07 Apr 2008 23:08:27 +0000</pubDate>
		<guid>http://www.airs.com/blog/archives/165#comment-12255</guid>
					<description>Apple had a jit linking system called Zero-Link which was mostly famous for not working and annoying everyone who used it... I'm not sure if that's a fundamental problem with the idea, though.</description>
		<content:encoded><![CDATA[	<p>Apple had a jit linking system called Zero-Link which was mostly famous for not working and annoying everyone who used it&#8230; I&#8217;m not sure if that&#8217;s a fundamental problem with the idea, though.
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Concurrent linking by: fprog</title>
		<link>http://www.airs.com/blog/archives/165#comment-12199</link>
		<pubDate>Sat, 05 Apr 2008 06:24:54 +0000</pubDate>
		<guid>http://www.airs.com/blog/archives/165#comment-12199</guid>
					<description>I like the inotify style approach, 
also ./configure scripts could be changed to add similar code 
if gold is found and the Makefile could be EASILY changed like this:

GCC=gcc
RM=@rm -f
CP=@cp -p
CFLAGS=-O2 -g
LDFLAGS=-lc
CLEAR=@clear
EXT=.x86
RMEXT=*.x86

HAVE_GOLD := $(wildcard /usr/bin/gold)

ifeq ($(strip $(HAVE_GOLD)),)
# Do not create, change only access time (i.e. dummy command harmless)
PRELINK=@touch -c -a
LD=gcc
else
# Gold is present
PRELINK=gold --prelink $(LDFLAGS) -o
LD=gold --postlink
endif

all: a$(EXT) b$(EXT) d$(EXT)
        @

clear:
        $(CLEAR)

clean:
        $(RM) a b d *.o a.out $(RMEXT)

a.o: a.h a.c
        @echo &quot;MUST add this line to prelink&quot;
        $(PRELINK) a$(EXT) a.o &amp;#38;
        $(PRELINK) d$(EXT) d.o &amp;#38;
        $(GCC) $(CFLAGS) -c a.c -o a.o

b.o: b.h b.c
        @echo &quot;MUST add this line to prelink&quot;
        $(PRELINK) b$(EXT) b.o &amp;#38;
        $(PRELINK) d$(EXT) d.o &amp;#38;
        $(GCC) $(CFLAGS) -c b.c -o b.o

d.o: d.h d.c
        @echo &quot;MUST add this line to prelink&quot;
        $(PRELINK) d$(EXT) d.o &amp;#38;
        $(GCC) $(CFLAGS) -c b.c -o b.o

a$(EXT): a.o
        @echo &quot;Wrap up the linking process&quot;
        $(LD) $(LDFLAGS) -o a$(EXT) a.o

b$(EXT): b.o
        @echo &quot;Wrap up the linking process&quot;
        $(LD) $(LDFLAGS) -o b$(EXT) b.o

d$(EXT): a.o b.o d.o
        @echo &quot;Wrap up the linking process&quot;
        $(LD) $(LDFLAGS) -o d$(EXT) a.o b.o d.o

run: a$(EXT) b$(EXT) d$(EXT)
        ./a$(EXT)
        ./b$(EXT)
        ./d$(EXT)

# make clean clear all run

In this approach you have 3 instance of gold --prelink working on d.x86,
and one final instance doing the last operation,
so some locking/sharing/synchronization will have to be used somehow.
For instance gold --prelink processes could &quot;talk&quot; via a shared file:
d$(EXT).prebuild

Another approach is this:

GCC=gcc
RM=@rm -f
CP=@cp -p
CFLAGS=-O2 -g
LDFLAGS=-lc
CLEAR=@clear
EXT=.x86
RMEXT=*.x86

HAVE_GOLD := $(wildcard /usr/bin/gold)

ifeq ($(strip $(HAVE_GOLD)),)
# Do not create, change only access time (i.e. dummy command harmless)
PRELINK=@touch -c -a
LD=gcc
else
PRELINK=gold --prelink $(LDFLAGS) -o
LD=gold --postlink
endif

all: b$(EXT) d$(EXT)
        @

clear:
        $(CLEAR)

clean:
        $(RM) a b d *.o a.out $(RMEXT)

a.o: a.h a.c
        $(GCC) $(CFLAGS) -DNOMAIN -c a.c -o a.o

b.o: b.h b.c
        $(GCC) $(CFLAGS) -c b.c -o b.o

d.o: d.h d.c
        $(GCC) $(CFLAGS) -c d.c -o d.o

# Add these rules
b$(EXT).prebuild:
        @echo &quot;prebuild b&quot;
        $(PRELINK) b$(EXT) a.o b.o

d$(EXT).prebuild:
        @echo &quot;prebuild d&quot;
        $(PRELINK) d$(EXT) a.o d.o

b$(EXT): b$(EXT).prebuild a.o b.o
        @echo &quot;Wrap up the linking process&quot;
        $(LD) $(LDFLAGS) -o b$(EXT) a.o b.o

d$(EXT): d$(EXT).prebuild a.o d.o
        @echo &quot;Wrap up the linking process&quot;
        $(LD) $(LDFLAGS) -o d$(EXT) a.o d.o

Now, you have only one gold --prelink that will exits once all files are linked
and dump the results in d$(EXT).prebuild
and gold --postlink finds the d$(EXT).prebuild file
and do the last bit of linking...

Another way even simpler is to have $(LD) do &quot;nothing&quot;, 
similar to LD=@touch -c -a
and pass $(LDFLAGS) to $(PRELINK)
but that may be inconvenient,
if the executables do not have the same parameters...

So another way is this, which is easy to script out:

GCC=gcc
RM=@rm -f
CP=@cp -p
CFLAGS=-O2 -g
LDFLAGS=-lc
CLEAR=clear
EXT=.x86
RMEXT=*.x86

HAVE_GOLD := $(wildcard /usr/bin/gold)

# Check if HAVE_GOLD is not found and null
ifeq ($(strip $(HAVE_GOLD)),)
# Returns true and never execute the inner content
PRELINK=@true &amp;#166;&amp;#166; (false &amp;#38;&amp;#38; echo &quot;
PRELINKEND=&quot;)
LD=gcc
LDEND=
else
PRELINK=gold --prelink
PRELINKOUT=
LD=@true &amp;#166;&amp;#166; (false &amp;#38;&amp;#38; echo &quot;
LDEND=&quot;)
endif

all: b$(EXT) d$(EXT)
        @

clear:
        $(CLEAR)

clean:
        $(RM) a b d *.o a.out $(RMEXT)

a.o: a.h a.c
        $(GCC) $(CFLAGS) -DNOMAIN -c a.c -o a.o

b.o: b.h b.c
        $(GCC) $(CFLAGS) -c b.c -o b.o

d.o: d.h d.c
        $(GCC) $(CFLAGS) -c d.c -o d.o

b.prebuild:
        @echo &quot;prebuild b - Copy-paste from below with PRELINK..PRELINKEND prefix/suffix&quot;
        $(PRELINK) $(LDFLAGS) -o b$(EXT) a.o b.o $(PRELINKEND)

d.prebuild:
        @echo &quot;prebuild d - Copy-paste from below with PRELINK..PRELINKEND prefix/suffix&quot;
        $(PRELINK) $(LDFLAGS) -o d$(EXT) a.o d.o $(PRELINKEND)

b$(EXT): b.prebuild a.o b.o
        @echo &quot;no post processing&quot;
        $(LD) $(LDFLAGS) -o b$(EXT) a.o b.o $(LDEND)

d$(EXT): d.prebuild a.o d.o
        @echo &quot;no post processing&quot;
        $(LD) $(LDFLAGS) -o d$(EXT) a.o d.o $(LDEND)



It all depends on much work and how much life should be easy
for Makefile maintainers...

My 2 cents.

P.S.: Thanks for sharing gold with the community =)
       Anything that can make compilation/linking time smaller
       and our life simpler is always appreciated.
       I saw MIPS, but is anyone working on having ARM support too?</description>
		<content:encoded><![CDATA[	<p>I like the inotify style approach,<br />
also ./configure scripts could be changed to add similar code<br />
if gold is found and the Makefile could be EASILY changed like this:</p>
	<p>GCC=gcc<br />
RM=@rm -f<br />
CP=@cp -p<br />
CFLAGS=-O2 -g<br />
LDFLAGS=-lc<br />
CLEAR=@clear<br />
EXT=.x86<br />
RMEXT=*.x86</p>
	<p>HAVE_GOLD := $(wildcard /usr/bin/gold)</p>
	<p>ifeq ($(strip $(HAVE_GOLD)),)<br />
# Do not create, change only access time (i.e. dummy command harmless)<br />
PRELINK=@touch -c -a<br />
LD=gcc<br />
else<br />
# Gold is present<br />
PRELINK=gold &#8211;prelink $(LDFLAGS) -o<br />
LD=gold &#8211;postlink<br />
endif</p>
	<p>all: a$(EXT) b$(EXT) d$(EXT)<br />
        @</p>
	<p>clear:<br />
        $(CLEAR)</p>
	<p>clean:<br />
        $(RM) a b d *.o a.out $(RMEXT)</p>
	<p>a.o: a.h a.c<br />
        @echo &#8220;MUST add this line to prelink&#8221;<br />
        $(PRELINK) a$(EXT) a.o &amp;<br />
        $(PRELINK) d$(EXT) d.o &amp;<br />
        $(GCC) $(CFLAGS) -c a.c -o a.o</p>
	<p>b.o: b.h b.c<br />
        @echo &#8220;MUST add this line to prelink&#8221;<br />
        $(PRELINK) b$(EXT) b.o &amp;<br />
        $(PRELINK) d$(EXT) d.o &amp;<br />
        $(GCC) $(CFLAGS) -c b.c -o b.o</p>
	<p>d.o: d.h d.c<br />
        @echo &#8220;MUST add this line to prelink&#8221;<br />
        $(PRELINK) d$(EXT) d.o &amp;<br />
        $(GCC) $(CFLAGS) -c b.c -o b.o</p>
	<p>a$(EXT): a.o<br />
        @echo &#8220;Wrap up the linking process&#8221;<br />
        $(LD) $(LDFLAGS) -o a$(EXT) a.o</p>
	<p>b$(EXT): b.o<br />
        @echo &#8220;Wrap up the linking process&#8221;<br />
        $(LD) $(LDFLAGS) -o b$(EXT) b.o</p>
	<p>d$(EXT): a.o b.o d.o<br />
        @echo &#8220;Wrap up the linking process&#8221;<br />
        $(LD) $(LDFLAGS) -o d$(EXT) a.o b.o d.o</p>
	<p>run: a$(EXT) b$(EXT) d$(EXT)<br />
        ./a$(EXT)<br />
        ./b$(EXT)<br />
        ./d$(EXT)</p>
	<p># make clean clear all run</p>
	<p>In this approach you have 3 instance of gold &#8211;prelink working on d.x86,<br />
and one final instance doing the last operation,<br />
so some locking/sharing/synchronization will have to be used somehow.<br />
For instance gold &#8211;prelink processes could &#8220;talk&#8221; via a shared file:<br />
d$(EXT).prebuild</p>
	<p>Another approach is this:</p>
	<p>GCC=gcc<br />
RM=@rm -f<br />
CP=@cp -p<br />
CFLAGS=-O2 -g<br />
LDFLAGS=-lc<br />
CLEAR=@clear<br />
EXT=.x86<br />
RMEXT=*.x86</p>
	<p>HAVE_GOLD := $(wildcard /usr/bin/gold)</p>
	<p>ifeq ($(strip $(HAVE_GOLD)),)<br />
# Do not create, change only access time (i.e. dummy command harmless)<br />
PRELINK=@touch -c -a<br />
LD=gcc<br />
else<br />
PRELINK=gold &#8211;prelink $(LDFLAGS) -o<br />
LD=gold &#8211;postlink<br />
endif</p>
	<p>all: b$(EXT) d$(EXT)<br />
        @</p>
	<p>clear:<br />
        $(CLEAR)</p>
	<p>clean:<br />
        $(RM) a b d *.o a.out $(RMEXT)</p>
	<p>a.o: a.h a.c<br />
        $(GCC) $(CFLAGS) -DNOMAIN -c a.c -o a.o</p>
	<p>b.o: b.h b.c<br />
        $(GCC) $(CFLAGS) -c b.c -o b.o</p>
	<p>d.o: d.h d.c<br />
        $(GCC) $(CFLAGS) -c d.c -o d.o</p>
	<p># Add these rules<br />
b$(EXT).prebuild:<br />
        @echo &#8220;prebuild b&#8221;<br />
        $(PRELINK) b$(EXT) a.o b.o</p>
	<p>d$(EXT).prebuild:<br />
        @echo &#8220;prebuild d&#8221;<br />
        $(PRELINK) d$(EXT) a.o d.o</p>
	<p>b$(EXT): b$(EXT).prebuild a.o b.o<br />
        @echo &#8220;Wrap up the linking process&#8221;<br />
        $(LD) $(LDFLAGS) -o b$(EXT) a.o b.o</p>
	<p>d$(EXT): d$(EXT).prebuild a.o d.o<br />
        @echo &#8220;Wrap up the linking process&#8221;<br />
        $(LD) $(LDFLAGS) -o d$(EXT) a.o d.o</p>
	<p>Now, you have only one gold &#8211;prelink that will exits once all files are linked<br />
and dump the results in d$(EXT).prebuild<br />
and gold &#8211;postlink finds the d$(EXT).prebuild file<br />
and do the last bit of linking&#8230;</p>
	<p>Another way even simpler is to have $(LD) do &#8220;nothing&#8221;,<br />
similar to LD=@touch -c -a<br />
and pass $(LDFLAGS) to $(PRELINK)<br />
but that may be inconvenient,<br />
if the executables do not have the same parameters&#8230;</p>
	<p>So another way is this, which is easy to script out:</p>
	<p>GCC=gcc<br />
RM=@rm -f<br />
CP=@cp -p<br />
CFLAGS=-O2 -g<br />
LDFLAGS=-lc<br />
CLEAR=clear<br />
EXT=.x86<br />
RMEXT=*.x86</p>
	<p>HAVE_GOLD := $(wildcard /usr/bin/gold)</p>
	<p># Check if HAVE_GOLD is not found and null<br />
ifeq ($(strip $(HAVE_GOLD)),)<br />
# Returns true and never execute the inner content<br />
PRELINK=@true || (false &amp;&amp; echo &#8221;<br />
PRELINKEND=&#8221;)<br />
LD=gcc<br />
LDEND=<br />
else<br />
PRELINK=gold &#8211;prelink<br />
PRELINKOUT=<br />
LD=@true || (false &amp;&amp; echo &#8221;<br />
LDEND=&#8221;)<br />
endif</p>
	<p>all: b$(EXT) d$(EXT)<br />
        @</p>
	<p>clear:<br />
        $(CLEAR)</p>
	<p>clean:<br />
        $(RM) a b d *.o a.out $(RMEXT)</p>
	<p>a.o: a.h a.c<br />
        $(GCC) $(CFLAGS) -DNOMAIN -c a.c -o a.o</p>
	<p>b.o: b.h b.c<br />
        $(GCC) $(CFLAGS) -c b.c -o b.o</p>
	<p>d.o: d.h d.c<br />
        $(GCC) $(CFLAGS) -c d.c -o d.o</p>
	<p>b.prebuild:<br />
        @echo &#8220;prebuild b - Copy-paste from below with PRELINK..PRELINKEND prefix/suffix&#8221;<br />
        $(PRELINK) $(LDFLAGS) -o b$(EXT) a.o b.o $(PRELINKEND)</p>
	<p>d.prebuild:<br />
        @echo &#8220;prebuild d - Copy-paste from below with PRELINK..PRELINKEND prefix/suffix&#8221;<br />
        $(PRELINK) $(LDFLAGS) -o d$(EXT) a.o d.o $(PRELINKEND)</p>
	<p>b$(EXT): b.prebuild a.o b.o<br />
        @echo &#8220;no post processing&#8221;<br />
        $(LD) $(LDFLAGS) -o b$(EXT) a.o b.o $(LDEND)</p>
	<p>d$(EXT): d.prebuild a.o d.o<br />
        @echo &#8220;no post processing&#8221;<br />
        $(LD) $(LDFLAGS) -o d$(EXT) a.o d.o $(LDEND)</p>
	<p>It all depends on much work and how much life should be easy<br />
for Makefile maintainers&#8230;</p>
	<p>My 2 cents.</p>
	<p>P.S.: Thanks for sharing gold with the community =)<br />
       Anything that can make compilation/linking time smaller<br />
       and our life simpler is always appreciated.<br />
       I saw MIPS, but is anyone working on having ARM support too?
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Concurrent linking by: Ian Lance Taylor</title>
		<link>http://www.airs.com/blog/archives/165#comment-11767</link>
		<pubDate>Thu, 27 Mar 2008 01:30:41 +0000</pubDate>
		<guid>http://www.airs.com/blog/archives/165#comment-11767</guid>
					<description>Thanks for the note.  That sounds cool.  It seems like it doesn't really permit a distributed compilation model, though.  I suppose that's OK for a project named &quot;tiny&quot;.</description>
		<content:encoded><![CDATA[	<p>Thanks for the note.  That sounds cool.  It seems like it doesn&#8217;t really permit a distributed compilation model, though.  I suppose that&#8217;s OK for a project named &#8220;tiny&#8221;.
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Concurrent linking by: landley</title>
		<link>http://www.airs.com/blog/archives/165#comment-11760</link>
		<pubDate>Wed, 26 Mar 2008 21:28:03 +0000</pubDate>
		<guid>http://www.airs.com/blog/archives/165#comment-11760</guid>
					<description>Concurrent linking is essentially how tinycc works.  The linker is built into the compiler, it assembles the ELF segments in ram as it's compiling the software, and then writes them out towards the end.

I've actually spent a large chunk of the past week reading the ELF spec so I can improve the version of it I inherited when Fabrice Bellard lost interest in the project (he does QEMU these days).  I'm turning it into a busybox-style swiss army knife executable that has various different &quot;cc&quot;, &quot;ld&quot;, &quot;as&quot;, &quot;ar&quot; etc. functions...

I'm also extending it until it can build an unmodified Linux kernel, but there's rather a lot of work to do before then. :)</description>
		<content:encoded><![CDATA[	<p>Concurrent linking is essentially how tinycc works.  The linker is built into the compiler, it assembles the ELF segments in ram as it&#8217;s compiling the software, and then writes them out towards the end.</p>
	<p>I&#8217;ve actually spent a large chunk of the past week reading the ELF spec so I can improve the version of it I inherited when Fabrice Bellard lost interest in the project (he does QEMU these days).  I&#8217;m turning it into a busybox-style swiss army knife executable that has various different &#8220;cc&#8221;, &#8220;ld&#8221;, &#8220;as&#8221;, &#8220;ar&#8221; etc. functions&#8230;</p>
	<p>I&#8217;m also extending it until it can build an unmodified Linux kernel, but there&#8217;s rather a lot of work to do before then. <img src='http://www.airs.com/blog/wp-images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Concurrent linking by: ncm</title>
		<link>http://www.airs.com/blog/archives/165#comment-11754</link>
		<pubDate>Wed, 26 Mar 2008 05:38:10 +0000</pubDate>
		<guid>http://www.airs.com/blog/archives/165#comment-11754</guid>
					<description>Or you could leave the incremental linker running all the time, watching your current list of executables.</description>
		<content:encoded><![CDATA[	<p>Or you could leave the incremental linker running all the time, watching your current list of executables.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
