• davidl (7/7) Mar 22 2009 I don't know why there should be different format object files. Couldn't...
• Daniel Keep (4/14) Mar 22 2009 I would imagine it's because OPTLINK requires OMF, linux wants ELF and
• davidl (4/18) Mar 22 2009 One nice thing of .net is your .net assemblies will not requrie further ...
• Daniel Keep (3/27) Mar 22 2009 Ummm... how is that relevant?
• davidl (3/33) Mar 23 2009 I meant to talk about the portability and the distribution effort.
• Yigal Chripun (3/21) Mar 23 2009 it's not a platform issue but more of a linker issue. after all, mingw u...
• Frits van Bommel (3/4) Mar 23 2009 Actually, I'm pretty sure it uses a COFF variant. (Unless this has
• davidl (4/9) Mar 23 2009 I wish a unified object format, a unified linker. That's all. The
• Sergey Gromov (4/16) Mar 24 2009 Add to this a unified compiler and a unified language. ;-)
• davidl (6/13) Mar 22 2009 minid's bind is suffering from optlink issue(seems related to obj feed t...

davidl <davidl 126.com> writes:

I don't know why there should be different format object files. Couldn't  
they be much the same. And the linker finally decide how to link them to  
platform specific binary?

MSVC perhaps has already get some idea of this kind, the link time code  
generation.

I'm just curious why on the X86 arch , we get different object file  
formats just for platform specific.

Daniel Keep <daniel.keep.lists gmail.com> writes:

davidl wrote:
 
 I don't know why there should be different format object files. Couldn't
 they be much the same. And the linker finally decide how to link them to
 platform specific binary?
 
 MSVC perhaps has already get some idea of this kind, the link time code
 generation.
 
 I'm just curious why on the X86 arch , we get different object file
 formats just for platform specific.

I would imagine it's because OPTLINK requires OMF, linux wants ELF and
Mac OSX wants mach-o (or something).

  -- Daniel

davidl <davidl 126.com> writes:

在 Mon, 23 Mar 2009 13:30:48 +0800，Daniel Keep  
<daniel.keep.lists gmail.com> 写道:

 davidl wrote:
 I don't know why there should be different format object files. Couldn't
 they be much the same. And the linker finally decide how to link them to
 platform specific binary?

 MSVC perhaps has already get some idea of this kind, the link time code
 generation.

 I'm just curious why on the X86 arch , we get different object file
 formats just for platform specific.

 I would imagine it's because OPTLINK requires OMF, linux wants ELF and
 Mac OSX wants mach-o (or something).

   -- Daniel

One nice thing of .net is your .net assemblies will not requrie further  
recompilation, and they can run directly by mono on linux.

Daniel Keep <daniel.keep.lists gmail.com> writes:

davidl wrote:
 在 Mon, 23 Mar 2009 13:30:48 +0800，Daniel Keep
 <daniel.keep.lists gmail.com> 写道:
 
 davidl wrote:
 I don't know why there should be different format object files. Couldn't
 they be much the same. And the linker finally decide how to link them to
 platform specific binary?

 MSVC perhaps has already get some idea of this kind, the link time code
 generation.

 I'm just curious why on the X86 arch , we get different object file
 formats just for platform specific.

 I would imagine it's because OPTLINK requires OMF, linux wants ELF and
 Mac OSX wants mach-o (or something).

   -- Daniel

 
 One nice thing of .net is your .net assemblies will not requrie further
 recompilation, and they can run directly by mono on linux.

Ummm... how is that relevant?

  -- Daniel

davidl <davidl 126.com> writes:

在 Mon, 23 Mar 2009 14:57:55 +0800，Daniel Keep  
<daniel.keep.lists gmail.com> 写道:

 davidl wrote:
 在 Mon, 23 Mar 2009 13:30:48 +0800，Daniel Keep
 <daniel.keep.lists gmail.com> 写道:

 davidl wrote:
 I don't know why there should be different format object files.  
 Couldn't
 they be much the same. And the linker finally decide how to link them  
 to
 platform specific binary?

 MSVC perhaps has already get some idea of this kind, the link time  
 code
 generation.

 I'm just curious why on the X86 arch , we get different object file
 formats just for platform specific.

 I would imagine it's because OPTLINK requires OMF, linux wants ELF and
 Mac OSX wants mach-o (or something).

   -- Daniel

 One nice thing of .net is your .net assemblies will not requrie further
 recompilation, and they can run directly by mono on linux.

 Ummm... how is that relevant?

   -- Daniel

I meant to talk about the portability and the distribution effort.

Yigal Chripun <yigal100 gmail.com> writes:

Daniel Keep Wrote:

 
 
 davidl wrote:
 
 I don't know why there should be different format object files. Couldn't
 they be much the same. And the linker finally decide how to link them to
 platform specific binary?
 
 MSVC perhaps has already get some idea of this kind, the link time code
 generation.
 
 I'm just curious why on the X86 arch , we get different object file
 formats just for platform specific.

 
 I would imagine it's because OPTLINK requires OMF, linux wants ELF and
 Mac OSX wants mach-o (or something).
 
   -- Daniel

it's not a platform issue but more of a linker issue. after all, mingw uses elf
on windows, right?

obj files can be converted between different formats so I guess one can take
elf obj files, convert them to omf and feed the result to optlink. it's all a
matter of linker implementation and it would be nice to have all of this
automated by dmd/optlink

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Yigal Chripun wrote:
 it's not a platform issue but more of a linker issue. after all, mingw uses
elf on windows, right?

Actually, I'm pretty sure it uses a COFF variant. (Unless this has 
changed recently?)

davidl <davidl 126.com> writes:

在 Mon, 23 Mar 2009 18:18:55 +0800，Frits van Bommel  
<fvbommel remwovexcapss.nl> 写道:

 Yigal Chripun wrote:
 it's not a platform issue but more of a linker issue. after all, mingw  
 uses elf on windows, right?

 Actually, I'm pretty sure it uses a COFF variant. (Unless this has  
 changed recently?)


I wish a unified object format, a unified linker. That's all. The  
crossplatform shit is just annoying.

Sergey Gromov <snake.scaly gmail.com> writes:

Tue, 24 Mar 2009 14:13:34 +0800, davidl wrote:

 在 Mon, 23 Mar 2009 18:18:55 +0800，Frits van Bommel  
 <fvbommel remwovexcapss.nl> 写道:
 
 Yigal Chripun wrote:
 it's not a platform issue but more of a linker issue. after all, mingw  
 uses elf on windows, right?

 Actually, I'm pretty sure it uses a COFF variant. (Unless this has  
 changed recently?)

 
 I wish a unified object format, a unified linker. That's all. The  
 crossplatform shit is just annoying.

Add to this a unified compiler and a unified language.  ;-)

The reason behind different OSes and object file formats is exactly the
same as the reasons behind different programming languages.

davidl <davidl 126.com> writes:

在 Mon, 23 Mar 2009 13:11:39 +0800，davidl <davidl 126.com> 写道:

 I don't know why there should be different format object files. Couldn't  
 they be much the same. And the linker finally decide how to link them to  
 platform specific binary?

 MSVC perhaps has already get some idea of this kind, the link time code  
 generation.

 I'm just curious why on the X86 arch , we get different object file  
 formats just for platform specific.

minid's bind is suffering from optlink issue(seems related to obj feed to  
the linker, when n files feed to linker at a time would make it crash, n-1  
won't, but error messages). Can ming32 ld accept dmd cross compilation elf  
objs? I think it's a possible wordaround of making dmd generating elf obj  
to bypass optlink.