Hi!
I'm interested in starting a project to make a linker besides
optlink for dmd on windows. If possible it'd be cool to run it as
a gsoc-project, but if that's not an option I'll try to get it
admitted as a soc-project at my university.
Anyway, the project would aim to be a replacement or
On 04-05-2012 00:47, Pierre LeMoine wrote:
Hi!
I'm interested in starting a project to make a linker besides optlink
for dmd on windows. If possible it'd be cool to run it as a
gsoc-project, but if that's not an option I'll try to get it admitted as
a soc-project at my university.
Absolutely p
I'm interested in starting a project to make a linker besides optlink
for dmd on windows.
Imho changing dmd to use COFF (incl. 64 support) instead of that crappy
OMF would be more beneficial than yet another linker.
My vision is to create a linker in a relatively modern language (D) and
On Fri, May 04, 2012 at 12:53:02AM +0200, Alex Rønne Petersen wrote:
> On 04-05-2012 00:47, Pierre LeMoine wrote:
[...]
> >Anyway, the project would aim to be a replacement or alternative to
> >optlink on windows. I've personally encountered quite a few seemingly
> >random problems with optlink, an
On 04-05-2012 01:57, H. S. Teoh wrote:
On Fri, May 04, 2012 at 12:53:02AM +0200, Alex Rønne Petersen wrote:
On 04-05-2012 00:47, Pierre LeMoine wrote:
[...]
Anyway, the project would aim to be a replacement or alternative to
optlink on windows. I've personally encountered quite a few seemingly
On Fri, May 04, 2012 at 02:43:34AM +0200, Alex Rønne Petersen wrote:
> On 04-05-2012 01:57, H. S. Teoh wrote:
[...]
> >The problem with writing linkers is that they are usually closely
> >tied to implementation details on the host OS.
[...]
> I know, but that doesn't mean you can't write the linker
On 2012-05-04 01:57, H. S. Teoh wrote:
To be frank, I question the wisdom of not just using ld on Posix
systems... but OTOH, the world *needs* better linker technology than we
currently have, so this projects like this one is a good thing.
He can start with a version for Windows. If as much as
On Thu, 03 May 2012 19:47:24 -0400, Trass3r wrote:
I'm interested in starting a project to make a linker besides optlink
for dmd on windows.
Imho changing dmd to use COFF (incl. 64 support) instead of that crappy
OMF would be more beneficial than yet another linker.
+1
-Steve
On Thursday, 3 May 2012 at 23:47:26 UTC, Trass3r wrote:
I'm interested in starting a project to make a linker besides
optlink for dmd on windows.
Imho changing dmd to use COFF (incl. 64 support) instead of
that crappy OMF would be more beneficial than yet another
linker.
My vision is to cr
On Fri, 04 May 2012 18:57:44 +0200, foobar wrote:
On Thursday, 3 May 2012 at 23:47:26 UTC, Trass3r wrote:
I'm interested in starting a project to make a linker besides optlink
for dmd on windows.
Imho changing dmd to use COFF (incl. 64 support) instead of that crappy
OMF would be more ben
On 5/4/12, foobar wrote:
> How about augmenting the object format so that libraries would be
> self contained and would not require additional .di files? Is
> this possible optlink by e.g. adding special sections that would
> be otherwise ignored?
How would you use a library you don't even have t
On 5/4/12, Trass3r wrote:
>> I'm interested in starting a project to make a linker besides optlink
>> for dmd on windows.
>
> Imho changing dmd to use COFF (incl. 64 support) instead of that crappy
> OMF would be more beneficial than yet another linker.
Hear hear.
But I wouldn't mind seeing a li
On Friday, 4 May 2012 at 17:52:54 UTC, simendsjo wrote:
On Fri, 04 May 2012 18:57:44 +0200, foobar wrote:
On Thursday, 3 May 2012 at 23:47:26 UTC, Trass3r wrote:
I'm interested in starting a project to make a linker
besides optlink for dmd on windows.
Imho changing dmd to use COFF (incl. 64
On Friday, 4 May 2012 at 17:54:47 UTC, Andrej Mitrovic wrote:
On 5/4/12, foobar wrote:
How about augmenting the object format so that libraries would
be
self contained and would not require additional .di files? Is
this possible optlink by e.g. adding special sections that
would
be otherwise
On Fri, 04 May 2012 13:54:38 -0400, Andrej Mitrovic
wrote:
On 5/4/12, foobar wrote:
How about augmenting the object format so that libraries would be
self contained and would not require additional .di files? Is
this possible optlink by e.g. adding special sections that would
be otherwise i
On 5/4/12, foobar wrote:
> The di files are mostly meant to be machine read (e.g. the
> compiler) and this belongs as part of the library file in order
> to provide ease of use and maintain the relationship between the
> binary code and it's interface.
>
> maintaining two sets of files that could
On 5/4/12, Steven Schveighoffer wrote:
> Ever heard of Java?
Ever heard of not requiring a bring-your-quadcore-to-its-knees IDE?
On Fri, 04 May 2012 14:31:24 -0400, Andrej Mitrovic
wrote:
On 5/4/12, Steven Schveighoffer wrote:
Ever heard of Java?
Ever heard of not requiring a bring-your-quadcore-to-its-knees IDE?
This is a totally false comparison :) Java's storage of its interface in
its object files has noth
On 5/4/12, Steven Schveighoffer wrote:
> What I'm saying is, it's completely possible to store the API in binary
> format *in* the object files, and use documentation generators to document
Yes but then you need to *modify* existing tools in order to add a new
feature that extracts information fr
On Friday, 4 May 2012 at 18:30:32 UTC, Andrej Mitrovic wrote:
On 5/4/12, foobar wrote:
The di files are mostly meant to be machine read (e.g. the
compiler) and this belongs as part of the library file in order
to provide ease of use and maintain the relationship between
the
binary code and it
On Fri, 04 May 2012 14:48:04 -0400, Andrej Mitrovic
wrote:
On 5/4/12, Steven Schveighoffer wrote:
What I'm saying is, it's completely possible to store the API in binary
format *in* the object files, and use documentation generators to
document
Yes but then you need to *modify* existing
On 5/4/12, Steven Schveighoffer wrote:
> Current tools: read .di files and extract API
> new tools: read .dobj files and extract API.
>
> I'm not really seeing the difficulty here...
I thought he meant libraries that are only distributed in binary form.
So no .di files anywhere. Maybe I misunder
On Fri, 04 May 2012 15:07:43 -0400, Andrej Mitrovic
wrote:
On 5/4/12, Steven Schveighoffer wrote:
Current tools: read .di files and extract API
new tools: read .dobj files and extract API.
I'm not really seeing the difficulty here...
I thought he meant libraries that are only distribute
On Fri, May 4, 2012 at 1:46 PM, foobar wrote:
> On Friday, 4 May 2012 at 18:30:32 UTC, Andrej Mitrovic wrote:
>
>> On 5/4/12, foobar wrote:
>>
>>> The di files are mostly meant to be machine read (e.g. the
>>> compiler) and this belongs as part of the library file in order
>>> to provide ease of
On 2012-05-04 18:57, foobar wrote:
How about augmenting the object format so that libraries would be self
contained and would not require additional .di files? Is this possible
optlink by e.g. adding special sections that would be otherwise ignored?
That would be nice. I guess that would mean
On 2012-05-04 20:30, Andrej Mitrovic wrote:
I'd say the docs are more likely to be out of sync than .di code. If
the .di code is really out of sync you'll likely even get linker
errors. And not everything ends up being documented.
Then you need to manage your docs better.
And then what about
On Friday, 4 May 2012 at 19:13:21 UTC, Steven Schveighoffer wrote:
On Fri, 04 May 2012 15:07:43 -0400, Andrej Mitrovic
wrote:
On 5/4/12, Steven Schveighoffer wrote:
Current tools: read .di files and extract API
new tools: read .dobj files and extract API.
I'm not really seeing the difficu
On Friday, 4 May 2012 at 19:21:02 UTC, Andrew Wiley wrote:
On Fri, May 4, 2012 at 1:46 PM, foobar wrote:
On Friday, 4 May 2012 at 18:30:32 UTC, Andrej Mitrovic wrote:
On 5/4/12, foobar wrote:
The di files are mostly meant to be machine read (e.g. the
compiler) and this belongs as part of
On Fri, 04 May 2012 14:56:56 -0400, Andrew Wiley
wrote:
I like the idea, but what about templates? For them, you'd basically be
stuffing source code into the object files
Nothing wrong with this. There is still a gain here -- object code
compiled from the source containing the original s
On Fri, May 04, 2012 at 07:54:38PM +0200, Andrej Mitrovic wrote:
> On 5/4/12, foobar wrote:
> > How about augmenting the object format so that libraries would be
> > self contained and would not require additional .di files? Is
> > this possible optlink by e.g. adding special sections that would
>
On Fri, May 04, 2012 at 03:13:21PM -0400, Steven Schveighoffer wrote:
[...]
> I think he meant that object (and library) binary files would be
> augmented by API segments that provide what di files provide now --
> an interface-only version of the code. It doesn't have to be text,
> it can be bina
On Fri, 04 May 2012 14:12:16 -0700, H. S. Teoh
wrote:
On Fri, May 04, 2012 at 07:54:38PM +0200, Andrej Mitrovic wrote:
On 5/4/12, foobar wrote:
> How about augmenting the object format so that libraries would be
> self contained and would not require additional .di files? Is
> this possible
On Friday, 4 May 2012 at 21:11:22 UTC, H. S. Teoh wrote:
Exactly. And while we're at it, *really* strip unnecessary
stuff from
.di files, like function bodies, template bodies, etc.. That
stuff is
required by the compiler, not the user, so stick that in the
object
files and let the compiler dea
On Sat, May 05, 2012 at 12:07:16AM +0200, foobar wrote:
> On Friday, 4 May 2012 at 21:11:22 UTC, H. S. Teoh wrote:
> >Exactly. And while we're at it, *really* strip unnecessary stuff from
> >.di files, like function bodies, template bodies, etc.. That stuff is
> >required by the compiler, not the u
On Friday 04 May 2012 08:56 PM, Andrew Wiley wrote:
On Fri, May 4, 2012 at 1:46 PM, foobar mailto:f...@bar.com>> wrote:
On Friday, 4 May 2012 at 18:30:32 UTC, Andrej Mitrovic wrote:
On 5/4/12, foobar mailto:f...@bar.com>> wrote:
The di files are mostly meant to be machi
On Friday 04 May 2012 11:17 PM, H. S. Teoh wrote:
On Fri, May 04, 2012 at 03:13:21PM -0400, Steven Schveighoffer wrote:
[...]
I think he meant that object (and library) binary files would be
augmented by API segments that provide what di files provide now --
an interface-only version of the code
Am 04.05.2012 20:26, schrieb Steven Schveighoffer:
On Fri, 04 May 2012 13:54:38 -0400, Andrej Mitrovic
wrote:
On 5/4/12, foobar wrote:
How about augmenting the object format so that libraries would be
self contained and would not require additional .di files? Is
this possible optlink by
Am 05.05.2012 09:06, schrieb dennis luehring:
Am 04.05.2012 20:26, schrieb Steven Schveighoffer:
On Fri, 04 May 2012 13:54:38 -0400, Andrej Mitrovic
wrote:
On 5/4/12, foobar wrote:
How about augmenting the object format so that libraries would be
self contained and would not requ
On 2012-05-05 00:39, H. S. Teoh wrote:
It's often impossible to debug something if you don't get to see what
the compiler sees. I suppose you could argue that leaving out function
bodies and stuff amounts to the same thing, but at least the language's
interface for a function is the function's s
On Friday, 4 May 2012 at 22:38:27 UTC, H. S. Teoh wrote:
On Sat, May 05, 2012 at 12:07:16AM +0200, foobar wrote:
On Friday, 4 May 2012 at 21:11:22 UTC, H. S. Teoh wrote:
>Exactly. And while we're at it, *really* strip unnecessary
>stuff from
>.di files, like function bodies, template bodies, et
Am 04.05.2012 19:54, schrieb Andrej Mitrovic:
On 5/4/12, foobar wrote:
How about augmenting the object format so that libraries would be
self contained and would not require additional .di files? Is
this possible optlink by e.g. adding special sections that would
be otherwise ignored?
How wou
On Fri, May 04, 2012 at 02:39:00PM -0700, Adam Wilson wrote:
> On Fri, 04 May 2012 14:12:16 -0700, H. S. Teoh
> wrote:
[...]
> >Exactly. And while we're at it, *really* strip unnecessary stuff from
> >.di files, like function bodies, template bodies, etc.. That stuff is
> >required by the compiler
On Sat, May 05, 2012 at 09:51:40AM -0700, H. S. Teoh wrote:
> On Fri, May 04, 2012 at 02:39:00PM -0700, Adam Wilson wrote:
> > On Fri, 04 May 2012 14:12:16 -0700, H. S. Teoh
> > wrote:
> [...]
> > >Exactly. And while we're at it, *really* strip unnecessary stuff from
> > >.di files, like function
On Thursday, 3 May 2012 at 22:53:03 UTC, Alex Rønne Petersen
wrote:
Absolutely possible, though too late for this year's GSoC. If
you're still interested in working on it for GSoC 2013 (if
Google decides to do another GSoC (which they most likely
will)), then be sure to submit a proposal!
Too
On Thursday, 3 May 2012 at 23:47:26 UTC, Trass3r wrote:
Imho changing dmd to use COFF (incl. 64 support) instead of
that crappy OMF would be more beneficial than yet another
linker.
I'd love to, but i don't think i can spend a whole summer doing
that ;)
If you do write a linker then make
Delphi, Turbo Pascal and FreePascal do the same.
All the required information is stored in the tpu/fpu files (Turbo/Free
Pascal Unit).
A command line tool or IDE support easily show the unit interface.
--
Paulo
"foobar" wrote in message news:abzrrvpylkxhdzsdh...@forum.dlang.org...
On Thurs
AST/symbol table manipulation is way faster than reparsing code.
People keep talking about D and Go compilation speed, while I was already
enjoying such compile times back in 1990 with Turbo Pascal in computers much
less powerfull than my laptop.
But C and C++ with their 70's compiler technology
I also don't see the issue.
This is already a long tradition in the languages that don't have to carry C
linker baggage.
- Turbo Pascal 4.0, 1987
- Oberon 1.0, 1986
So I also don't why a 2012 language can't have a similar mechanism.
--
Paulo
"Andrej Mitrovic" wrote in message
news:mailman
I really really think that mankind did a wrong turn when C won over Pascal
in the 80's.
And that Wirth somehow lost interest in the industry and did not try to push
Modula-* or Oberon. There are some papers where he states this.
Now we suffer from
- daggling pointers
- buffer overflows
- pre-hi
Paulo Pinto wrote:
> AST/symbol table manipulation is way faster than reparsing code.
>
> People keep talking about D and Go compilation speed, while I was already
> enjoying such compile times back in 1990 with Turbo Pascal in computers much
> less powerfull than my laptop.
>
> But C and C++ wit
On Monday, 7 May 2012 at 07:26:44 UTC, Jens Mueller wrote:
Paulo Pinto wrote:
AST/symbol table manipulation is way faster than reparsing
code.
People keep talking about D and Go compilation speed, while I
was already
enjoying such compile times back in 1990 with Turbo Pascal in
computers muc
Paulo Pinto wrote:
> On Monday, 7 May 2012 at 07:26:44 UTC, Jens Mueller wrote:
> >Paulo Pinto wrote:
> >>AST/symbol table manipulation is way faster than reparsing code.
> >>
> >>People keep talking about D and Go compilation speed, while I
> >>was already
> >>enjoying such compile times back in 1
Am 07.05.2012 07:53, schrieb Paulo Pinto:
I really really think that mankind did a wrong turn when C won over Pascal
in the 80's.
And that Wirth somehow lost interest in the industry and did not try to push
Modula-* or Oberon. There are some papers where he states this.
Now we suffer from
- da
On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
wrote:
Purity inference won't happen either way. Purity is part of your API and
also meant to help you reason about your code. If the compiler just
infers purity in a function and you later change the implementation so
it's no longe
On Sat, 05 May 2012 03:06:52 -0400, dennis luehring
wrote:
Am 04.05.2012 20:26, schrieb Steven Schveighoffer:
On Fri, 04 May 2012 13:54:38 -0400, Andrej Mitrovic
wrote:
On 5/4/12, foobar wrote:
How about augmenting the object format so that libraries would be
self contained and woul
On 07-05-2012 13:21, Steven Schveighoffer wrote:
On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
wrote:
Purity inference won't happen either way. Purity is part of your API
and also meant to help you reason about your code. If the compiler
just infers purity in a function and you later
On 05/07/12 13:21, Steven Schveighoffer wrote:
> On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
> wrote:
>
>> Purity inference won't happen either way. Purity is part of your API and
>> also meant to help you reason about your code. If the compiler just infers
>> purity in a function
On Thu, 03 May 2012 19:47:19 -0300, Pierre LeMoine
wrote:
Hi!
I'm interested in starting a project to make a linker besides
optlink for dmd on windows. If possible it'd be cool to run it as
a gsoc-project, but if that's not an option I'll try to get it
admitted as a soc-project at my universi
On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen
wrote:
On 07-05-2012 13:21, Steven Schveighoffer wrote:
On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
wrote:
Purity inference won't happen either way. Purity is part of your API
and also meant to help you reason about your
This just confirms what I saw yesterday on a presentation.
Many developers re-invent the wheel, or jump to the fad technology of the
year, because they don't have the knowledge of old already proven
technologies,
that for whatever reason, are no longer common.
We need better ways to preserve k
I think it was there where I read about it.
I'll update you if I have any success, otherwise I need to retract my
statement. :(
--
Paulo
"Jens Mueller" wrote in message
news:mailman.380.1336380192.24740.digitalmar...@puremagic.com...
Paulo Pinto wrote:
On Monday, 7 May 2012 at 07:26:44 U
On 07-05-2012 14:50, Steven Schveighoffer wrote:
On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen
wrote:
On 07-05-2012 13:21, Steven Schveighoffer wrote:
On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
wrote:
Purity inference won't happen either way. Purity is part of your A
I like the idea, need to check what information I could provide.
Wirth's books about Oberon also provide similar information.
--
Paulo
"dennis luehring" wrote in message news:jo85t1$1n9b$1...@digitalmars.com...
Am 07.05.2012 07:53, schrieb Paulo Pinto:
I really really think that mankind did
On Mon, 07 May 2012 09:22:05 -0400, Paulo Pinto
wrote:
This just confirms what I saw yesterday on a presentation.
Many developers re-invent the wheel, or jump to the fad technology of the
year, because they don't have the knowledge of old already proven
technologies,
that for whatever rea
On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen
wrote:
On 07-05-2012 14:50, Steven Schveighoffer wrote:
On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen
wrote:
On 07-05-2012 13:21, Steven Schveighoffer wrote:
On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
wrote:
On Monday, 7 May 2012 at 12:36:18 UTC, Roald Ribe wrote:
If you are interested in getting results rather than
reinventing the wheel,
I would advice you to have a look at the openwatcom.org wlink,
and the
forked jwlink as a starting point. The linker is open source,
written in
C and has user do
On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer wrote:
> On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen <
> xtzgzo...@gmail.com> wrote:
>
> On 07-05-2012 14:50, Steven Schveighoffer wrote:
>>
>>> On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen
>>> wrote:
>>>
>>> On 07-05-2
On Mon, 07 May 2012 12:59:24 -0400, Andrew Wiley
wrote:
On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer
wrote:
On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen <
That's exactly what storing the interface in the object file does. You
don't need the source because the object fil
Am 07.05.2012 15:30, schrieb Steven Schveighoffer:
On Mon, 07 May 2012 09:22:05 -0400, Paulo Pinto
wrote:
This just confirms what I saw yesterday on a presentation.
Many developers re-invent the wheel, or jump to the fad technology of the
year, because they don't have the knowledge of old alr
On Mon, May 7, 2012 at 12:21 PM, Steven Schveighoffer
wrote:
> On Mon, 07 May 2012 12:59:24 -0400, Andrew Wiley
> wrote:
>
> On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer > >wrote:
>>
>>> On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen <
>>>
>>> That's exactly what storing the int
On Mon, May 07, 2012 at 07:21:54PM +0200, Paulo Pinto wrote:
[...]
> I have spent a huge time in the university learning about compiler
> development, reading old books and papers from the early computing
> days.
>
> So in a general way, and not directed to you now, I saddens me that a
> great par
On Mon, 07 May 2012 13:34:49 -0400, Andrew Wiley
wrote:
On Mon, May 7, 2012 at 12:21 PM, Steven Schveighoffer
wrote:
I agree that's the case with the current object/linker model. Something
that puts inferred properties into the object file needs a new model,
one
which does not blindly l
On 2012-05-07 20:13, H. S. Teoh wrote:
On Mon, May 07, 2012 at 07:21:54PM +0200, Paulo Pinto wrote:
Sometimes I wonder what do students learn in modern CS courses.
[...]
Way too much theory and almost no practical applications. At least, that
was my experience when I was in college. It gets
On 2012-05-07 17:41, Pierre LeMoine wrote:
On Monday, 7 May 2012 at 12:36:18 UTC, Roald Ribe wrote:
If you are interested in getting results rather than reinventing the
wheel,
I would advice you to have a look at the openwatcom.org wlink, and the
forked jwlink as a starting point. The linker is
Hi,
it seems I have to excuse myself. I could not find anything
from Adele Goldberg.
So my statement is false. Most likely I ended up confusing
Fran Allen's interview in Coders at Work, with some nonsense
in my head.
Still, I leave here a few links I manage to find from Fran Allen.
Some remark
Am 07.05.2012 15:27, schrieb Paulo Pinto:
I like the idea, need to check what information I could provide.
Wirth's books about Oberon also provide similar information.
--
Paulo
"dennis luehring" wrote in message news:jo85t1$1n9b$1...@digitalmars.com...
Am 07.05.2012 07:53, schrieb Paulo Pinto
Interesting reading.
I took a look at page 23, and didn't find the mention of C.
Maybe I didn't read carefully?
On 5/8/2012 3:34 AM, Paulo Pinto wrote:
> Hi,
>
> it seems I have to excuse myself. I could not find anything
> from Adele Goldberg.
>
> So my statement is false. Most likely I ended u
Oops, copy/paste error. :(
I'll check it, when I get back home.
--
Paulo
"Andre Tampubolon" wrote in message news:joa0lq$1t2k$1...@digitalmars.com...
Interesting reading.
I took a look at page 23, and didn't find the mention of C.
Maybe I didn't read carefully?
On 5/8/2012 3:34 AM, Paulo Pin
The correct link should have been
http://uhaweb.hartford.edu/ccscne/Allen.pdf
Am 08.05.2012 04:33, schrieb Andre Tampubolon:
Interesting reading.
I took a look at page 23, and didn't find the mention of C.
Maybe I didn't read carefully?
On 5/8/2012 3:34 AM, Paulo Pinto wrote:
Hi,
it seems I h
Am 04.05.2012 01:47, schrieb Trass3r:
>> I'm interested in starting a project to make a linker besides optlink
>> for dmd on windows.
>
> Imho changing dmd to use COFF (incl. 64 support) instead of that crappy
> OMF would be more beneficial than yet another linker.
>
>
>> My vision is to create
On Mon, 07 May 2012 12:41:09 -0300, Pierre LeMoine
wrote:
On Monday, 7 May 2012 at 12:36:18 UTC, Roald Ribe wrote:
If you are interested in getting results rather than
reinventing the wheel,
I would advice you to have a look at the openwatcom.org wlink,
and the
forked jwlink as a starting poi
On 5/4/12, Pierre LeMoine wrote:
> I'm interested in starting a project to make a linker besides
> optlink for dmd on windows.
I've found this randomly in my links (ELF Linux linker, but still
might be useful info): http://research.google.com/pubs/pub34417.html
The source is probably hosted some
82 matches
Mail list logo