mixing compilers (g++ but Intel others)?

[pedr...@lycos.com]

I was mucking around with an open-source omni-shambles, which uses
Fortran, C and C++. It has a lot of makefiles for different platforms,
which are a little inconsistent. I can only get it to work if
Intel compilers are used for Fortran and C but gnu g++ for C++.
Now I was told in undergrad programming class that mixing brands
of compilers like this is not recommended.
(I did engineering and we had a "computer programming for physical sciences"
module of 26 class hours total).

[Paavo Helde]

C has defined binary interface (ABI) on each platform, so using a C
library compiled by another compiler should be fine.

C++ on the other hand does not have defined ABI, so mixing C++ code from
different compilers in general does not work (unless all the
communication happens over the C interfaces (functions declared as
extern "C")). But if all your C++ code is compiled by the same compiler,
there should be no problem.

Not sure what is the state with Fortran.

HTH
Paavo

[FredK]

On my RHEL Linux, Fortran object files compiled using the Intel compiler are not compatible with object files compiled using the GNU gfortran compiler.

[Jerry Stuckle]

On 4/25/2016 10:01 AM, FredK wrote:
> On my RHEL Linux, Fortran object files compiled using the Intel compiler are not compatible with object files compiled using the GNU gfortran compiler.
>

Object files are not the same as libraries. Fortran libraries compiled
using the Intel compiler should be compatible with files compiled with
the GNU Fortran compiler (and vice versa).

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Scott Lurndal]

Jerry Stuckle <jstu...@attglobal.net> writes:
>On 4/25/2016 10:01 AM, FredK wrote:
>> On my RHEL Linux, Fortran object files compiled using the Intel compiler are not compatible with object files compiled using the GNU gfortran compiler.
>>
>
>Object files are not the same as libraries.

Perhaps in Z/OS, that's true.

In unix (and unix-like systems or even VMS) libraries are simply
collections (archives) of object files.

[Jerry Stuckle]

Yes, but even on unix, object files are not the same as libraries.

[Scott Lurndal]

Jerry Stuckle <jstu...@attglobal.net> writes:
>On 4/25/2016 1:23 PM, Scott Lurndal wrote:
>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>> On 4/25/2016 10:01 AM, FredK wrote:
>>>> On my RHEL Linux, Fortran object files compiled using the Intel compiler are not compatible with object files compiled using the GNU gfortran compiler.
>>>>
>>>
>>> Object files are not the same as libraries.
>>
>> Perhaps in Z/OS, that's true.
>>
>> In unix (and unix-like systems or even VMS) libraries are simply
>> collections (archives) of object files.
>>
>
>Yes, but even on unix, object files are not the same as libraries.

You'll have to explain that in further detail. A .a and a .o are
interchangable and almost indistinguishable from the perspective of the linker.

[Jerry Stuckle]

The key here is - ALMOST INDISTINGUISHABLE.

A .a file is an OS standard format and can be used with many linkers and
languages. A .o file is dependent on the compiler, and may or may not
be compatible with other compilers.

[Ian Collins]

UNIX .a files (and Windows .lib files) are a simple archive of object
files. The format of the archive may be standard, but the format of the
archived object files is not. A reasonable analogy would be a physical
library: the library layout is standard, but English books are still in
English and French books are in French.

--
Ian Collins

[Jerry Stuckle]

Ah, but the format of the objects in the library are standard.
Otherwise you would not be able to call the system libraries from C,
PASCAL, FORTRAN, or any of the other languages.

You can make the entry point names and calling conventions non-standard.
But if you define the functions with the PASCAL calling convention,
they are available in any language and any compiler.

You cannot say the same with object files, even with the PASCAL calling
convention. There is no standard format, and every compiler is free to
define it's own.

[Ian Collins]

What part of "UNIX .a files (and Windows .lib files) are a simple
archive of object files" did you miss?

There aren't any transformations when an object file is archived, so any
incompatibilities in the object files are faithfully preserved. With
C++, the usual incompatibility is the name mangling. This isn't an
issue with system libraries which are either written in C or have C linkage.

--
Ian Collins

[David Brown]

Are you sure you are not mixing up /dynamic/ libraries, which follow OS
standards so that any program in any language can call their functions
at runtime, and /static/ libraries that are simply a way to collect
object files to make static linking more efficient?

[Scott Lurndal]

Jerry Stuckle <jstu...@attglobal.net> writes:
>On 4/25/2016 6:43 PM, Scott Lurndal wrote:

>> You'll have to explain that in further detail. A .a and a .o are
>> interchangable and almost indistinguishable from the perspective of the linker.
>>
>
>The key here is - ALMOST INDISTINGUISHABLE.
>
>A .a file is an OS standard format and can be used with many linkers and
>languages. A .o file is dependent on the compiler, and may or may not
>be compatible with other compilers.

Actually, the gABI and psABI define the (ELF) object file format for Unix, specifically to
enable interoperability between toolsets. The fact that one single compiler
may not follow the standard means little.

Likewise, the COFF format was defined in a standard (and even sort of adopted
by MS) before ELF was developed in the late 80's.

[Scott Lurndal]

Jerry Stuckle <jstu...@attglobal.net> writes:
>On 4/25/2016 8:37 PM, Ian Collins wrote:

>> Jerry Stuckle <jstu...@attglobal.net> writes:

>>> A .a file is an OS standard format and can be used with many linkers and
>>> languages. A .o file is dependent on the compiler, and may or may not
>>> be compatible with other compilers.
>>
>> UNIX .a files (and Windows .lib files) are a simple archive of object
>> files. The format of the archive may be standard, but the format of the
>> archived object files is not. A reasonable analogy would be a physical
>> library: the library layout is standard, but English books are still in
>> English and French books are in French.
>>
>
>Ah, but the format of the objects in the library are standard.
>Otherwise you would not be able to call the system libraries from C,
>PASCAL, FORTRAN, or any of the other languages.

Your understanding of linkage (static or at runtime) on unix systems
seems to be somewhat lacking.

The only thing in an archive library are regular object files. The linker
simply extracts each and attempts to resolve any unresolved symbols
from each in turn.

A shared object, on the other hand, is a set of object files linked
into a new object file - one that includes a global offset table(s) and
procedure linkage table(s) designed to enable run-time linkage between
an executable and the shared object.

In both cases, the object file format is defined by the gABI and psABI
for the processor family.

>
>You can make the entry point names and calling conventions non-standard.
> But if you define the functions with the PASCAL calling convention,
>they are available in any language and any compiler.

WTF?

>
>You cannot say the same with object files, even with the PASCAL calling
>convention. There is no standard format, and every compiler is free to
>define it's own.

This is incorrect:

https://refspecs.linuxfoundation.org/elf/gabi41.pdf (chapter 4)
http://www.x86-64.org/documentation/abi.pdf (chapter 4)

[Scott Lurndal]

David Brown <david...@hesbynett.no> writes:
>On 26/04/16 06:17, Jerry Stuckle wrote:

>>
>> Ah, but the format of the objects in the library are standard.
>> Otherwise you would not be able to call the system libraries from C,
>> PASCAL, FORTRAN, or any of the other languages.
>
>Are you sure you are not mixing up /dynamic/ libraries, which follow OS
>standards so that any program in any language can call their functions
>at runtime, and /static/ libraries that are simply a way to collect
>object files to make static linking more efficient?

Even if he were, he'd be wrong. The System V Generic ABI and the
associated processor supplements (psABIs) document completely both the
object file format and the calling sequences for all languages. A
shared object is just another object file using the same ELF-based
format as any other object file. It simply has additional sections
(.dynsym, .got, .plt, et. alia).

There are psABI's for 32-bit intel, 64-bit intel (x86_64 and ia64)
as well as sparc, powerpc, mips and arm (Aarch32 and Aarch64) and
even system/370.

[Jerry Stuckle]

On 4/26/2016 1:14 AM, Ian Collins wrote:
> On 04/26/16 16:17, Jerry Stuckle wrote:
>> On 4/25/2016 8:37 PM, Ian Collins wrote:
>>> On 04/26/16 12:12, Jerry Stuckle wrote:
>>>>
>>>> A .a file is an OS standard format and can be used with many linkers
>>>> and
>>>> languages. A .o file is dependent on the compiler, and may or may not
>>>> be compatible with other compilers.
>>>
>>> UNIX .a files (and Windows .lib files) are a simple archive of object
>>> files. The format of the archive may be standard, but the format of the
>>> archived object files is not. A reasonable analogy would be a physical
>>> library: the library layout is standard, but English books are still in
>>> English and French books are in French.
>>>
>>
>> Ah, but the format of the objects in the library are standard.
>> Otherwise you would not be able to call the system libraries from C,
>> PASCAL, FORTRAN, or any of the other languages.
>>
>> You can make the entry point names and calling conventions non-standard.
>> But if you define the functions with the PASCAL calling convention,
>> they are available in any language and any compiler.
>>
>> You cannot say the same with object files, even with the PASCAL calling
>> convention. There is no standard format, and every compiler is free to
>> define it's own.
>
> What part of "UNIX .a files (and Windows .lib files) are a simple
> archive of object files" did you miss?
>

What part of object file formats being compiler dependent and library
file formats being defined by the operating system did you miss?

> There aren't any transformations when an object file is archived, so any
> incompatibilities in the object files are faithfully preserved. With
> C++, the usual incompatibility is the name mangling. This isn't an
> issue with system libraries which are either written in C or have C
> linkage.
>

Maybe not with gcc - but that is NOT the only compiler in the world.
But it obviously is the only one you've ever used. You once again show
a distinct lack of understanding of anything outside of your limited
experience.

For instance - the Microsoft compiler object files are not compatible
with Watcom object files, and neither were compatible with Borland
object files. But libraries created by any of them are compatible with
the others.

[Jerry Stuckle]

No, I am not. The static library format is also defined by OS standards
and libraries created to that standard can also be used by different
compilers and languages.

>>
>> You can make the entry point names and calling conventions non-standard.
>> But if you define the functions with the PASCAL calling convention,
>> they are available in any language and any compiler.
>>
>> You cannot say the same with object files, even with the PASCAL calling
>> convention. There is no standard format, and every compiler is free to
>> define it's own.
>>
>>
>

[Jerry Stuckle]

Then why aren't Microsoft generated object files compatible with Watcom
generated object file, and neither were compatible with Borland
generated object files? But all of the libraries were.

And why can't you use a Linux object file on a Windows machine, and vice
versa?

If what you say were true, none of the above would be correct. But it
can easily be demonstrated.

[Jerry Stuckle]

On 4/26/2016 10:18 AM, Scott Lurndal wrote:
> Jerry Stuckle <jstu...@attglobal.net> writes:
>> On 4/25/2016 8:37 PM, Ian Collins wrote:
>>> Jerry Stuckle <jstu...@attglobal.net> writes:
>
>>>> A .a file is an OS standard format and can be used with many linkers and
>>>> languages. A .o file is dependent on the compiler, and may or may not
>>>> be compatible with other compilers.
>>>
>>> UNIX .a files (and Windows .lib files) are a simple archive of object
>>> files. The format of the archive may be standard, but the format of the
>>> archived object files is not. A reasonable analogy would be a physical
>>> library: the library layout is standard, but English books are still in
>>> English and French books are in French.
>>>
>>
>> Ah, but the format of the objects in the library are standard.
>> Otherwise you would not be able to call the system libraries from C,
>> PASCAL, FORTRAN, or any of the other languages.
>
> Your understanding of linkage (static or at runtime) on unix systems
> seems to be somewhat lacking.
>

Not at all. I was probably working with them before you were born.

> The only thing in an archive library are regular object files. The linker
> simply extracts each and attempts to resolve any unresolved symbols
> from each in turn.
>

Yes, that is true. The linker then writes the library in an *OS
standard* format.

But the object file may or may not be compatible with other compilers.
gcc is NOT the only compiler in this world!

> A shared object, on the other hand, is a set of object files linked
> into a new object file - one that includes a global offset table(s) and
> procedure linkage table(s) designed to enable run-time linkage between
> an executable and the shared object.
>

Are you talking about a shared object - or a shared library?

> In both cases, the object file format is defined by the gABI and psABI
> for the processor family.
>

Then why aren't object files compatible across compilers and operating
systems? If it were generated with gcc on Linux, I should be able to
link it in using a Microsoft compiler on Windows.

>>
>> You can make the entry point names and calling conventions non-standard.
>> But if you define the functions with the PASCAL calling convention,
>> they are available in any language and any compiler.
>
> WTF?
>

That is correct. The PASCAL calling convention is common to all
compiled languages, including FORTRAN, COBOL and others. Even C
compilers have ways of defining the PASCAL calling convention. OTOH,
the C calling convention is only usable by a few languages, the most
common being C and C++.

That's why system libraries use the PASCAL calling convention - on all OS's.

>>
>> You cannot say the same with object files, even with the PASCAL calling
>> convention. There is no standard format, and every compiler is free to
>> define it's own.
>
> This is incorrect:
>
> https://refspecs.linuxfoundation.org/elf/gabi41.pdf (chapter 4)
> http://www.x86-64.org/documentation/abi.pdf (chapter 4)
>

Then please explain why I can't do the above.

[Jerry Stuckle]

On 4/26/2016 10:11 AM, Scott Lurndal wrote:
> Jerry Stuckle <jstu...@attglobal.net> writes:
>> On 4/25/2016 6:43 PM, Scott Lurndal wrote:
>
>>> You'll have to explain that in further detail. A .a and a .o are
>>> interchangable and almost indistinguishable from the perspective of the linker.
>>>
>>
>> The key here is - ALMOST INDISTINGUISHABLE.
>>
>> A .a file is an OS standard format and can be used with many linkers and
>> languages. A .o file is dependent on the compiler, and may or may not
>> be compatible with other compilers.
>
> Actually, the gABI and psABI define the (ELF) object file format for Unix, specifically to
> enable interoperability between toolsets. The fact that one single compiler
> may not follow the standard means little.
>

The fact that multiple compilers do not follow this standard means a lot.

> Likewise, the COFF format was defined in a standard (and even sort of adopted
> by MS) before ELF was developed in the late 80's.
>

So why aren't compilers able to link each others object files?

[Scott Lurndal]

Jerry Stuckle <jstu...@attglobal.net> writes:
>On 4/26/2016 10:11 AM, Scott Lurndal wrote:
>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>> On 4/25/2016 6:43 PM, Scott Lurndal wrote:
>>
>>>> You'll have to explain that in further detail. A .a and a .o are
>>>> interchangable and almost indistinguishable from the perspective of the linker.
>>>>
>>>
>>> The key here is - ALMOST INDISTINGUISHABLE.
>>>
>>> A .a file is an OS standard format and can be used with many linkers and
>>> languages. A .o file is dependent on the compiler, and may or may not
>>> be compatible with other compilers.
>>
>> Actually, the gABI and psABI define the (ELF) object file format for Unix, specifically to
>> enable interoperability between toolsets. The fact that one single compiler
>> may not follow the standard means little.
>>
>
>The fact that multiple compilers do not follow this standard means a lot.

Citation required.

>
>> Likewise, the COFF format was defined in a standard (and even sort of adopted
>> by MS) before ELF was developed in the late 80's.
>>
>
>So why aren't compilers able to link each others object files?

In my experience, they do.

[Scott Lurndal]

Jerry Stuckle <jstu...@attglobal.net> writes:
>On 4/26/2016 10:18 AM, Scott Lurndal wrote:

>
>> In both cases, the object file format is defined by the gABI and psABI
>> for the processor family.
>>
>
>Then why aren't object files compatible across compilers and operating
>systems? If it were generated with gcc on Linux, I should be able to
>link it in using a Microsoft compiler on Windows.

Last I checked, Windows isn't Unix. gABI/psABI are Unix.

As it happens, the gnu binutils _will_, with effort, handle the
Microsoft PECOFF object format (which was the old, inefficient,
unix object format until superceded by the superior ELF format).
Microsoft has chosen not to support ELF. That's their problem.

[Gareth Owen]

Jerry Stuckle <jstu...@attglobal.net> writes:

> What part of object file formats being compiler dependent and library
> file formats being defined by the operating system did you miss?

Well, mostly that part about the fact that *on Unix its not true*.
The format of the object files is not modified when stored within the
library container format.

If a Pascal program can link to foo() in libfoo.a, then it can just as
easily link to foo() in foo.o

> For instance - the Microsoft compiler object files are not compatible
> with Watcom object files, and neither were compatible with Borland
> object files. But libraries created by any of them are compatible
> with the others.

And this refers to Ian's statement - which is clearly, unambiguously and
explicitly talking about Unix - how, exactly?

[David Brown]

On 26/04/16 16:33, Jerry Stuckle wrote:
> On 4/26/2016 10:21 AM, Scott Lurndal wrote:
>> David Brown <david...@hesbynett.no> writes:
>>> On 26/04/16 06:17, Jerry Stuckle wrote:
>>
>>>>
>>>> Ah, but the format of the objects in the library are standard.
>>>> Otherwise you would not be able to call the system libraries from C,
>>>> PASCAL, FORTRAN, or any of the other languages.
>>>
>>> Are you sure you are not mixing up /dynamic/ libraries, which follow OS
>>> standards so that any program in any language can call their functions
>>> at runtime, and /static/ libraries that are simply a way to collect
>>> object files to make static linking more efficient?
>>
>> Even if he were, he'd be wrong. The System V Generic ABI and the
>> associated processor supplements (psABIs) document completely both the
>> object file format and the calling sequences for all languages. A
>> shared object is just another object file using the same ELF-based
>> format as any other object file. It simply has additional sections
>> (.dynsym, .got, .plt, et. alia).
>>
>> There are psABI's for 32-bit intel, 64-bit intel (x86_64 and ia64)
>> as well as sparc, powerpc, mips and arm (Aarch32 and Aarch64) and
>> even system/370.
>>
>
> Then why aren't Microsoft generated object files compatible with Watcom
> generated object file, and neither were compatible with Borland
> generated object files? But all of the libraries were.

Perhaps this is because Microsoft and their OS's have always gone their
own way - they don't use the ABI's that the *nix world usually agrees on
for different processors. In fact, MS has generally failed to define a
decent ABI at all, outside the context of shared libraries (DLL's) and
older systems such as the INT calls in DOS, so that each tool vendor
made their own calling conventions.

I am not convinced that static libraries created by different compilers
such as Watcom and Borland tools on Windows /are/ compatible - I
certainly won't take your word alone on it. But I have not tried mixing
such libraries, so neither can I say that it is not the case.

>
> And why can't you use a Linux object file on a Windows machine, and vice
> versa?

They have a different object file format, and different ABIs, obviously.
But you would have a fair chance of getting object file compatibility
between Linux and FreeBSD or Solaris on the same target cpu.

[David Brown]

System libraries on all OS's use PASCAL calling convention, do they? I
am sure a lot of *nix developers will be surprised to hear about that.

You might also want to re-write the entire Wikipedia page on x86 calling
conventions:

<https://en.wikipedia.org/wiki/X86_calling_conventions>

[David Brown]

Usually they manage fine on *nix systems, but not on Windows where tools
often have different formats and calling conventions. Even on *nix, it
gets complicated with C++ as there are many versions of the C++ ABI (for
good reasons, as the language and the tools have gained new features).
But for straight extern "C" functions and native C data types, different
compilers on *nix can normally mix object files (and therefore also
static libraries).

[Jerry Stuckle]

On 4/26/2016 2:43 PM, Gareth Owen wrote:
> Jerry Stuckle <jstu...@attglobal.net> writes:
>
>> What part of object file formats being compiler dependent and library
>> file formats being defined by the operating system did you miss?
>
> Well, mostly that part about the fact that *on Unix its not true*.
> The format of the object files is not modified when stored within the
> library container format.
>

How many compilers other than gcc have you used on *nix? gcc is not the
only one (and never has been).

> If a Pascal program can link to foo() in libfoo.a, then it can just as
> easily link to foo() in foo.o
>

Only if both were created with the same compiler.

>> For instance - the Microsoft compiler object files are not compatible
>> with Watcom object files, and neither were compatible with Borland
>> object files. But libraries created by any of them are compatible
>> with the others.
>
> And this refers to Ian's statement - which is clearly, unambiguously and
> explicitly talking about Unix - how, exactly?
>

And the other comments here have indicated it applies to all x86 systems.

But what other compilers have you used? Ones that are not gcc based,
that is.

[Jerry Stuckle]

So your "standard" is not really a standard, is it?

> I am not convinced that static libraries created by different compilers
> such as Watcom and Borland tools on Windows /are/ compatible - I
> certainly won't take your word alone on it. But I have not tried mixing
> such libraries, so neither can I say that it is not the case.
>

They definitely are. I've used development libraries on Windows which
were created by manufacturers. I don't necessarily know which compiler
was used - but I've used the libraries with different compilers.

>>
>> And why can't you use a Linux object file on a Windows machine, and vice
>> versa?
>
> They have a different object file format, and different ABIs, obviously.
> But you would have a fair chance of getting object file compatibility
> between Linux and FreeBSD or Solaris on the same target cpu.
>

But you said it was a 32-bit intel and 64-bit intel standard. If that
were the case, they would be compatible. So obviously that is not true.

>>
>> If what you say were true, none of the above would be correct. But it
>> can easily be demonstrated.
>>
>

[Gareth Owen]

Jerry Stuckle <jstu...@attglobal.net> writes:

> How many compilers other than gcc have you used on *nix? gcc is not the
> only one (and never has been).

Sun CC (multiple versions), clang, gcc, DEC Alpha CC, DEC f77 and f95.

> Only if both were created with the same compiler.

Wrong.

[Jerry Stuckle]

But they're supposed to be 32-bit and 64-bit intel standards - not *nix
standards.

And what other compilers (non-gcc based, that is) have you used on *nix?

[Jerry Stuckle]

There is the truth, and there is Wikipedia. SOMETIMES they coincide.

PASCAL, FORTRAN, etc. use an entirely different calling convention than
C. They push left to right, and the called function pops the stack. C
pushes right to left, and the caller pops the stack. The two are not
compatible. C can use the PASCAL calling convention; PASCAL cannot use
the C calling convention.

stdcall is just a variation of the PASCAL calling convention.

>
>>>>
>>>> You cannot say the same with object files, even with the PASCAL calling
>>>> convention. There is no standard format, and every compiler is free to
>>>> define it's own.
>>>
>>> This is incorrect:
>>>
>>> https://refspecs.linuxfoundation.org/elf/gabi41.pdf (chapter 4)
>>> http://www.x86-64.org/documentation/abi.pdf (chapter 4)
>>>
>>
>> Then please explain why I can't do the above.
>>
>

No explanation?

[Jerry Stuckle]

On 4/26/2016 12:37 PM, Scott Lurndal wrote:
> Jerry Stuckle <jstu...@attglobal.net> writes:
>> On 4/26/2016 10:11 AM, Scott Lurndal wrote:
>>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>>> On 4/25/2016 6:43 PM, Scott Lurndal wrote:
>>>
>>>>> You'll have to explain that in further detail. A .a and a .o are
>>>>> interchangable and almost indistinguishable from the perspective of the linker.
>>>>>
>>>>
>>>> The key here is - ALMOST INDISTINGUISHABLE.
>>>>
>>>> A .a file is an OS standard format and can be used with many linkers and
>>>> languages. A .o file is dependent on the compiler, and may or may not
>>>> be compatible with other compilers.
>>>
>>> Actually, the gABI and psABI define the (ELF) object file format for Unix, specifically to
>>> enable interoperability between toolsets. The fact that one single compiler
>>> may not follow the standard means little.
>>>
>>
>> The fact that multiple compilers do not follow this standard means a lot.
>
> Citation required.
>

How many non-gcc based compilers have you used on *nix?

Compiler manufacturers do not normally document object file formats. If
you want a citation, go out and buy one. Then try to link in other
compiler .o files.

My "citation" is previous experience with different compilers.

>>
>>> Likewise, the COFF format was defined in a standard (and even sort of adopted
>>> by MS) before ELF was developed in the late 80's.
>>>
>>
>> So why aren't compilers able to link each others object files?
>
> In my experience, they do.
>

Which non-gcc based compilers have you used?

[Ian Collins]

None, I even mentioned it: "The format of the archive may be standard,
but the format of the archived object files is not". You appear to be
confusing the archive format with the format of its contents.

>> There aren't any transformations when an object file is archived, so any
>> incompatibilities in the object files are faithfully preserved. With
>> C++, the usual incompatibility is the name mangling. This isn't an
>> issue with system libraries which are either written in C or have C
>> linkage.
>
> Maybe not with gcc - but that is NOT the only compiler in the world.

The system libraries on one of my usual platforms (Solaris) aren't built
with gcc. The system libraries on the other (Illumos) are built with a
mix of gcc and Sun cc. Any C compiler on a UNIX or UNIX like system
that didn't use the platform standard ABI would be considered seriously
broken.

--
Ian Collins

[Cholo Lennon]

On 04/26/2016 05:41 PM, Jerry Stuckle wrote:
> Compiler manufacturers do not normally document object file formats.

Microsoft at least has this document (I have no idea if other
manufacturers provide similar information):

https://msdn.microsoft.com/en-us/windows/hardware/gg463119.aspx

Regards


--
Cholo Lennon
Bs.As.
ARG

[Gareth Owen]

Cholo Lennon <cholo...@hotmail.com> writes:

> On 04/26/2016 05:41 PM, Jerry Stuckle wrote:
>> Compiler manufacturers do not normally document object file formats.
>
> Microsoft at least has this document (I have no idea if other
> manufacturers provide similar information):

Here are Sun CC's
http://docs.oracle.com/cd/E19683-01/817-3677/6mj8mbtc7/index.html
(surprise! It's ELF)

[Jerry Stuckle]

And you were able to link Sun CC object files with DEC Alpha CC programs?

If so, the rest of the world would love to know how you did it.

[Jerry Stuckle]

I never argued about libraries being usable across compilers - they have
to be. My comment was restricted to object files.

[Jerry Stuckle]

They document part of the information. But they also include this:

"Note: This document is provided to aid in the development of tools and
applications for Windows but is not guaranteed to be a complete
specification in all respects. Microsoft reserves the right to alter
this document without notice."

And the undocumented parts can be very important.

[Jerry Stuckle]

Why should that surprise you when it was Sun which owned the copyright
for Unix, and developed the ELF spec? But then they had an ulterior
motive for documenting it - they weren't trying to sell a compiler, they
were trying to sell an OS.

[Ian Collins]

So you didn't write "Ah, but the format of the objects in the library

are standard. Otherwise you would not be able to call the system
libraries from C, PASCAL, FORTRAN, or any of the other languages."

Above?

--
Ian Collins

[Jerry Stuckle]

Yes, the format of the object files IN THE LIBRARY are standard. That
does not mean they were not changed when being inserted into the
library. In fact, they have to be as, among other things external
references need to be satisfied.

But some people are SO DENSE.

[Cholo Lennon]

On 04/27/2016 12:50 AM, Jerry Stuckle wrote:
> On 4/26/2016 5:04 PM, Cholo Lennon wrote:
>> On 04/26/2016 05:41 PM, Jerry Stuckle wrote:
>>> Compiler manufacturers do not normally document object file formats.
>>
>> Microsoft at least has this document (I have no idea if other
>> manufacturers provide similar information):
>>
>> https://msdn.microsoft.com/en-us/windows/hardware/gg463119.aspx
>>
>> Regards
>>
>>
>
> They document part of the information. But they also include this:
>
> "Note: This document is provided to aid in the development of tools and
> applications for Windows but is not guaranteed to be a complete
> specification in all respects. Microsoft reserves the right to alter
> this document without notice."
>
> And the undocumented parts can be very important.
>

You're right, "due to its history, no one can trust on what Microsoft
says" (TM) ;-)

Also I have to say that the last document update was on December 29th,
2015 and IMHO it is very complete (The download page is a bit outdated,
it refers to version 8.3, but the download link refers to the last
version, 9.3)

[Scott Lurndal]

Jerry Stuckle <jstu...@attglobal.net> writes:
>On 4/26/2016 2:43 PM, Gareth Owen wrote:
>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>
>>> What part of object file formats being compiler dependent and library
>>> file formats being defined by the operating system did you miss?
>>
>> Well, mostly that part about the fact that *on Unix its not true*.
>> The format of the object files is not modified when stored within the
>> library container format.
>>
>
>How many compilers other than gcc have you used on *nix? gcc is not the
>only one (and never has been).
>

Let's see: Diab Data, SVR4 CCS, GCC, Intel Compiler, Portland Compiler
Group just off the top of my head.

[Scott Lurndal]

Jerry Stuckle <jstu...@attglobal.net> writes:
>On 4/26/2016 12:41 PM, Scott Lurndal wrote:
>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>> On 4/26/2016 10:18 AM, Scott Lurndal wrote:
>>
>>>
>>>> In both cases, the object file format is defined by the gABI and psABI
>>>> for the processor family.
>>>>
>>>
>>> Then why aren't object files compatible across compilers and operating
>>> systems? If it were generated with gcc on Linux, I should be able to
>>> link it in using a Microsoft compiler on Windows.
>>
>> Last I checked, Windows isn't Unix. gABI/psABI are Unix.
>>
>> As it happens, the gnu binutils _will_, with effort, handle the
>> Microsoft PECOFF object format (which was the old, inefficient,
>> unix object format until superceded by the superior ELF format).
>> Microsoft has chosen not to support ELF. That's their problem.
>>
>
>But they're supposed to be 32-bit and 64-bit intel standards - not *nix
>standards.

No, they're Unix standards. Always have been.

You can't possibly expect object files to be interoperable
between different operating systems, do you? That's never
been the case in the history of computing.

If microsoft can't be bothered to create a standard for their
operating system, that's not their problem.

>
>And what other compilers (non-gcc based, that is) have you used on *nix?

V6 C
V7 C
PCC (w/ cfront 2.1)
SVR4 ccs
Diab Data C++ and F77
Portland Compiler Group compilers (C, C++, F77)
Intel compiler (C++, F77)
Gnu compiler (C, C++, F77, ADA)
Clang (C++)

All of which created compatible, interoperable and interlinkable object files.

[Scott Lurndal]

Jerry Stuckle <jstu...@attglobal.net> writes:

>I never argued about libraries being usable across compilers - they have
>to be. My comment was restricted to object files.

You continue, perhaps willfully, to misunderstand that libraries _are_
object files on *nix. Period.

[Scott Lurndal]

You clearly don't know what LIBRARY means in the context of *nix.

>
>But some people are SO DENSE.

Irony, thy name is Jerry.

[David Brown]

/My/ standard? What do you mean by that?

In the *nix world, each different processor ISA has an ABI that covers
things like calling conventions, register usage, stack framing, etc.
All reasonable compilers for *nix for that target will follow that ABI
for their basic function calls and data (i.e., C-like functions and
data). The conventions will also cover any necessary data tables or
relocation information. When generating externally linkable object
files (as distinct from purely internally linkable ones, which might be
used for link-time optimisation in compilers), the compiler and/or
assembler and/or linker will follow those conventions and formats. When
these object files are combined into libraries, the object file format
is preserved and some indexing information is added to the archive
(following the ABI). In this way, libraries and object files from
different compilers can be used together.

Note that not everything from object files or libraries is directly
usable by different compilers. Of particular relevance for this group,
with C++ you get name mangling, class layouts, and so on. That is why
most compiled languages have some sort of interface for creating and
calling external "C" functions, because those form the standard.

Also note that many compilers in the *nix world don't generate object
files or executable files - they generate assembly files that are
assembled by the /system/ assembler, and the object files are linked by
the /system/ linker. They all work together.


On Windows, it's a different matter - there is no standard for static
linking (only for dynamic linked libraries).


So if by "your standard", you mean the *nix ABI's for different targets,
then yes, those are /real/ standards. Microsoft, Windows, and many
tools on Windows don't follow those standards, and have their own ABI's.
That does not make the standards any less real - it just makes Windows
a poorer choice for a development platform, especially if you want to
combine code from different sources and different tools.

>
>> I am not convinced that static libraries created by different compilers
>> such as Watcom and Borland tools on Windows /are/ compatible - I
>> certainly won't take your word alone on it. But I have not tried mixing
>> such libraries, so neither can I say that it is not the case.
>>
>
> They definitely are. I've used development libraries on Windows which
> were created by manufacturers. I don't necessarily know which compiler
> was used - but I've used the libraries with different compilers.

Usually when I have dealt with development libraries on Windows, they
are delivered in DLL format - /dynamic/ libraries, not static libraries.
Dynamic libraries follow a fixed format on Windows.

>
>>>
>>> And why can't you use a Linux object file on a Windows machine, and vice
>>> versa?
>>
>> They have a different object file format, and different ABIs, obviously.
>> But you would have a fair chance of getting object file compatibility
>> between Linux and FreeBSD or Solaris on the same target cpu.
>>
>
> But you said it was a 32-bit intel and 64-bit intel standard. If that
> were the case, they would be compatible. So obviously that is not true.
>

No, I said no such thing.

There is a *nix standard for 32-bit x86 ABI and one for 64-bit x86 ABI
(AMD was the main author, not Intel). Non *nix systems on these targets
may not follow the same ABI - in particular, Windows does not.

[Jerry Stuckle]

On 4/27/2016 9:36 AM, Scott Lurndal wrote:
> Jerry Stuckle <jstu...@attglobal.net> writes:
>> On 4/26/2016 2:43 PM, Gareth Owen wrote:
>>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>>
>>>> What part of object file formats being compiler dependent and library
>>>> file formats being defined by the operating system did you miss?
>>>
>>> Well, mostly that part about the fact that *on Unix its not true*.
>>> The format of the object files is not modified when stored within the
>>> library container format.
>>>
>>
>> How many compilers other than gcc have you used on *nix? gcc is not the
>> only one (and never has been).
>>
>
> Let's see: Diab Data, SVR4 CCS, GCC, Intel Compiler, Portland Compiler
> Group just off the top of my head.
>

And you've been able to link object files generated by Diab Data with
Portland Compiler generated objects? And other combinations?

[Jerry Stuckle]

On 4/27/2016 9:44 AM, Scott Lurndal wrote:
> Jerry Stuckle <jstu...@attglobal.net> writes:
>> On 4/27/2016 12:55 AM, Ian Collins wrote:
>
>>
>> Yes, the format of the object files IN THE LIBRARY are standard. That
>> does not mean they were not changed when being inserted into the
>> library. In fact, they have to be as, among other things external
>> references need to be satisfied.
>
> You clearly don't know what LIBRARY means in the context of *nix.
>

Oh, I do. It looks like better than you do.

>>
>> But some people are SO DENSE.
>
> Irony, thy name is Jerry.
>

ROFLMAO! Now you start with the ad hominem attacks. Just like a troll
who runs out of legitimate arguments.

[Jerry Stuckle]

No, libraries are NOT object files on *nix. But you don't understand
the difference.

It's like saying object files are just C code. No, the source code is
not the same as the object file - although the source code is used to
*create* the object file.

[Jerry Stuckle]

You're the one who called it a standard.

> In the *nix world, each different processor ISA has an ABI that covers
> things like calling conventions, register usage, stack framing, etc.
> All reasonable compilers for *nix for that target will follow that ABI
> for their basic function calls and data (i.e., C-like functions and
> data). The conventions will also cover any necessary data tables or
> relocation information. When generating externally linkable object
> files (as distinct from purely internally linkable ones, which might be
> used for link-time optimisation in compilers), the compiler and/or
> assembler and/or linker will follow those conventions and formats. When
> these object files are combined into libraries, the object file format
> is preserved and some indexing information is added to the archive
> (following the ABI). In this way, libraries and object files from
> different compilers can be used together.
>

Sure, the have the same calling conventions, register usage, etc. I
never argued that. But the object files do not necessarily have to all
follow the same format. And object files are not just placed into
library files - there is a significant amount of work which is required
besides just copying a.o+b.o+c.o into d.a. The formats are NOT the same
(although they may be similar in gcc).

> Note that not everything from object files or libraries is directly
> usable by different compilers. Of particular relevance for this group,
> with C++ you get name mangling, class layouts, and so on. That is why
> most compiled languages have some sort of interface for creating and
> calling external "C" functions, because those form the standard.
>

I didn't say anything about name mangling, class layouts, or anything
else along those lines. I am specifically talking about object file
formats. You seem to think that object files must have the same format
as library files. That is where you are wrong - there is no such
requirement (although gcc may do it that way).

> Also note that many compilers in the *nix world don't generate object
> files or executable files - they generate assembly files that are
> assembled by the /system/ assembler, and the object files are linked by
> the /system/ linker. They all work together.
>

ALERT! ALERT! RED HERRING ALERT! This is a whole different story. If
they all generate assembler files, then the object files are all created
by the same assembler.

Please learn to stay on subject.

>
> On Windows, it's a different matter - there is no standard for static
> linking (only for dynamic linked libraries).
>

Wrong again. Statically linked libraries are also standard. And that's
a good thing, because if you don't want to run through a lot of
gyrations loading the dynamic library in your code, you need to link the
associated static library (which contains pointers to the dynamic
library entry points) into your program.

>
> So if by "your standard", you mean the *nix ABI's for different targets,
> then yes, those are /real/ standards. Microsoft, Windows, and many
> tools on Windows don't follow those standards, and have their own ABI's.
> That does not make the standards any less real - it just makes Windows
> a poorer choice for a development platform, especially if you want to
> combine code from different sources and different tools.
>

You're the one who said they were 32-bit intel, 64-bit intel, etc.
standards, which means they should be applicable to any 32-bit intel OS,
64-bit intel os, etc.

So I guess they really aren't "standard".

But Windows does fine with linking libraries from multiple different
compilers. But once again you show how little you know.

>>
>>> I am not convinced that static libraries created by different compilers
>>> such as Watcom and Borland tools on Windows /are/ compatible - I
>>> certainly won't take your word alone on it. But I have not tried mixing
>>> such libraries, so neither can I say that it is not the case.
>>>
>>
>> They definitely are. I've used development libraries on Windows which
>> were created by manufacturers. I don't necessarily know which compiler
>> was used - but I've used the libraries with different compilers.
>
> Usually when I have dealt with development libraries on Windows, they
> are delivered in DLL format - /dynamic/ libraries, not static libraries.
> Dynamic libraries follow a fixed format on Windows.
>

Yes, and they have a static library with them to satisfy your linker.
And those also follow a fixed format.

>>
>>>>
>>>> And why can't you use a Linux object file on a Windows machine, and vice
>>>> versa?
>>>
>>> They have a different object file format, and different ABIs, obviously.
>>> But you would have a fair chance of getting object file compatibility
>>> between Linux and FreeBSD or Solaris on the same target cpu.
>>>
>>
>> But you said it was a 32-bit intel and 64-bit intel standard. If that
>> were the case, they would be compatible. So obviously that is not true.
>>
>
> No, I said no such thing.
>
> There is a *nix standard for 32-bit x86 ABI and one for 64-bit x86 ABI
> (AMD was the main author, not Intel). Non *nix systems on these targets
> may not follow the same ABI - in particular, Windows does not.
>

That was not your original statement.

>>>>
>>>> If what you say were true, none of the above would be correct. But it
>>>> can easily be demonstrated.
>>>>
>>>
>>
>

[Jerry Stuckle]

On 4/27/2016 9:42 AM, Scott Lurndal wrote:
> Jerry Stuckle <jstu...@attglobal.net> writes:
>> On 4/26/2016 12:41 PM, Scott Lurndal wrote:
>>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>>> On 4/26/2016 10:18 AM, Scott Lurndal wrote:
>>>
>>>>
>>>>> In both cases, the object file format is defined by the gABI and psABI
>>>>> for the processor family.
>>>>>
>>>>
>>>> Then why aren't object files compatible across compilers and operating
>>>> systems? If it were generated with gcc on Linux, I should be able to
>>>> link it in using a Microsoft compiler on Windows.
>>>
>>> Last I checked, Windows isn't Unix. gABI/psABI are Unix.
>>>
>>> As it happens, the gnu binutils _will_, with effort, handle the
>>> Microsoft PECOFF object format (which was the old, inefficient,
>>> unix object format until superceded by the superior ELF format).
>>> Microsoft has chosen not to support ELF. That's their problem.
>>>
>>
>> But they're supposed to be 32-bit and 64-bit intel standards - not *nix
>> standards.
>
> No, they're Unix standards. Always have been.
>

That's not what you claimed above.

> You can't possibly expect object files to be interoperable
> between different operating systems, do you? That's never
> been the case in the history of computing.
>

Why not? You claimed they were.

> If microsoft can't be bothered to create a standard for their
> operating system, that's not their problem.
>

Oh, Windows has standards, and libraries created by one compiler are
completely compatible with libraries created by another compiler. But
you also have shown your ignorance even on basic compilation and library
usage on Windows.

>>
>> And what other compilers (non-gcc based, that is) have you used on *nix?
>
> V6 C
> V7 C
> PCC (w/ cfront 2.1)
> SVR4 ccs
> Diab Data C++ and F77
> Portland Compiler Group compilers (C, C++, F77)
> Intel compiler (C++, F77)
> Gnu compiler (C, C++, F77, ADA)
> Clang (C++)
>
> All of which created compatible, interoperable and interlinkable object files.
>

I'm not familiar with all of these. but at least two of them are gcc
derivatives. And you're saying you can take an object file created with
Portland and link it with a program created by Diab?

[Scott Lurndal]

Jerry Stuckle <jstu...@attglobal.net> writes:
>On 4/27/2016 9:43 AM, Scott Lurndal wrote:
>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>
>>> I never argued about libraries being usable across compilers - they have
>>> to be. My comment was restricted to object files.
>>
>> You continue, perhaps willfully, to misunderstand that libraries _are_
>> object files on *nix. Period.
>>
>
>No, libraries are NOT object files on *nix. But you don't understand
>the difference.

You can say that as many times as you wish. Doesn't make it true.

All ELF files are object files of one form or another, whether
relocatable or not. Even the final executable is an object file,
with some (but not all) interobject references resolved.

Believe that I've been writing unix /unix-like operating systems for
a long, long time and am well aware of how they work. I also sat on
the Xopen/Open Group base standards committee for close to a decade as well
as on the Unix International committee that specified the DWARF
section of the object file standard.

And yes, I've linked together objects generated by all the compilers
listed in other posts.

[Jerry Stuckle]

On 4/27/2016 1:37 PM, Scott Lurndal wrote:
> Jerry Stuckle <jstu...@attglobal.net> writes:
>> On 4/27/2016 9:43 AM, Scott Lurndal wrote:
>>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>>
>>>> I never argued about libraries being usable across compilers - they have
>>>> to be. My comment was restricted to object files.
>>>
>>> You continue, perhaps willfully, to misunderstand that libraries _are_
>>> object files on *nix. Period.
>>>
>>
>> No, libraries are NOT object files on *nix. But you don't understand
>> the difference.
>
> You can say that as many times as you wish. Doesn't make it true.
>

And you can say they are the same as many times as you wish. Doesn't

make it true.

> All ELF files are object files of one form or another, whether
> relocatable or not. Even the final executable is an object file,
> with some (but not all) interobject references resolved.
>

Sure. And they are the output of compiled programs - which means they
are the same as the source code. Except they aren't.

> Believe that I've been writing unix /unix-like operating systems for
> a long, long time and am well aware of how they work. I also sat on
> the Xopen/Open Group base standards committee for close to a decade as well
> as on the Unix International committee that specified the DWARF
> section of the object file standard.
>

Believe I've been working with unix for probably a lot longer than you
have - back around 1979 (although not continuously since that time). As
for being on the standards committees - what do you want - an award?
They say nothing about your competence. In fact, I've seen several
people on these committees I wouldn't hire if they paid me to work for me.

> And yes, I've linked together objects generated by all the compilers
> listed in other posts.
>

Then there are a lot of programmers in the world who would like to see
how you did it. Millions of programmers haven't been able to do so.

But then you're the great and powerful OZ. Nothing is impossible for you.

[Gareth Owen]

Jerry Stuckle <jstu...@attglobal.net> writes:

> And you were able to link Sun CC object files with DEC Alpha CC programs?

No because they were different architectures. Nobody ever suggested
that. It was merely asser

But I could link SunCC .o objects with native gcc .o objects on the Sun
machine.

And I could link DEC Fortran .o objects with native gcc objects on the
DEC machine.

> If so, the rest of the world would love to know how you did it.

Glad to see even you are no longer what you originally asserted.

[Gareth Owen]

Jerry Stuckle <jstu...@attglobal.net> writes:

> Yes, the format of the object files IN THE LIBRARY are standard.
> That does not mean they were not changed when being inserted into the
> library.

So your assertion is that building .a files by running "ar" on Unix .o
files fundamentally changes the layout of those files, rather than being
mostly concatentation?

That assertion is false.

[Robert Wessel]

On Wed, 27 Apr 2016 11:51:04 -0400, Jerry Stuckle
<jstu...@attglobal.net> wrote:

>
>> In the *nix world, each different processor ISA has an ABI that covers
>> things like calling conventions, register usage, stack framing, etc.
>> All reasonable compilers for *nix for that target will follow that ABI
>> for their basic function calls and data (i.e., C-like functions and
>> data). The conventions will also cover any necessary data tables or
>> relocation information. When generating externally linkable object
>> files (as distinct from purely internally linkable ones, which might be
>> used for link-time optimisation in compilers), the compiler and/or
>> assembler and/or linker will follow those conventions and formats. When
>> these object files are combined into libraries, the object file format
>> is preserved and some indexing information is added to the archive
>> (following the ABI). In this way, libraries and object files from
>> different compilers can be used together.
>>
>
>Sure, the have the same calling conventions, register usage, etc. I
>never argued that. But the object files do not necessarily have to all
>follow the same format. And object files are not just placed into
>library files - there is a significant amount of work which is required
>besides just copying a.o+b.o+c.o into d.a. The formats are NOT the same
>(although they may be similar in gcc).

But they are. A *nix .a file is just a bunch of .o's run through ar,
the predecessor of tar. There is no processing done to the contents
of those, although a (minimal) header is added to each file in the
archive (name, size, timestamp, a few other things), and a tiny header
for the entire archive file. In fact you create a .a library with
something like:

ar rcs lib.a obj1.o obj2.o obj3.o

The .la format from libtool is different.

[David Brown]

On 26/04/16 22:38, Jerry Stuckle wrote:
> On 4/26/2016 4:22 PM, David Brown wrote:
>> On 26/04/16 16:39, Jerry Stuckle wrote:

>>> On 4/26/2016 10:18 AM, Scott Lurndal wrote:
>>>> Jerry Stuckle <jstu...@attglobal.net> writes:

>>>>> On 4/25/2016 8:37 PM, Ian Collins wrote:
>>>>>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>>>

>>>>>>> A .a file is an OS standard format and can be used with many
>>>>>>> linkers and
>>>>>>> languages. A .o file is dependent on the compiler, and may or may
>>>>>>> not
>>>>>>> be compatible with other compilers.
>>>>>>
>>>>>> UNIX .a files (and Windows .lib files) are a simple archive of object

>>>>>> files. The format of the archive may be standard, but the format
>>>>>> of the

>>>>>> archived object files is not. A reasonable analogy would be a
>>>>>> physical
>>>>>> library: the library layout is standard, but English books are
>>>>>> still in
>>>>>> English and French books are in French.
>>>>>>
>>>>>

>>>>> Ah, but the format of the objects in the library are standard.
>>>>> Otherwise you would not be able to call the system libraries from C,
>>>>> PASCAL, FORTRAN, or any of the other languages.
>>>>

>>>> Your understanding of linkage (static or at runtime) on unix systems
>>>> seems to be somewhat lacking.
>>>>
>>>
>>> Not at all. I was probably working with them before you were born.
>>>
>>>> The only thing in an archive library are regular object files. The
>>>> linker
>>>> simply extracts each and attempts to resolve any unresolved symbols
>>>> from each in turn.
>>>>
>>>
>>> Yes, that is true. The linker then writes the library in an *OS
>>> standard* format.
>>>
>>> But the object file may or may not be compatible with other compilers.
>>> gcc is NOT the only compiler in this world!
>>>
>>>> A shared object, on the other hand, is a set of object files linked
>>>> into a new object file - one that includes a global offset table(s) and
>>>> procedure linkage table(s) designed to enable run-time linkage between
>>>> an executable and the shared object.
>>>>
>>>
>>> Are you talking about a shared object - or a shared library?

>>>
>>>> In both cases, the object file format is defined by the gABI and psABI
>>>> for the processor family.
>>>>
>>>
>>> Then why aren't object files compatible across compilers and operating
>>> systems? If it were generated with gcc on Linux, I should be able to
>>> link it in using a Microsoft compiler on Windows.
>>>
>>>>>

>>>>> You can make the entry point names and calling conventions
>>>>> non-standard.
>>>>> But if you define the functions with the PASCAL calling convention,
>>>>> they are available in any language and any compiler.
>>>>

>>>> WTF?
>>>>
>>>
>>> That is correct. The PASCAL calling convention is common to all
>>> compiled languages, including FORTRAN, COBOL and others. Even C
>>> compilers have ways of defining the PASCAL calling convention. OTOH,
>>> the C calling convention is only usable by a few languages, the most
>>> common being C and C++.
>>>
>>> That's why system libraries use the PASCAL calling convention - on all
>>> OS's.
>>>
>>
>> System libraries on all OS's use PASCAL calling convention, do they? I
>> am sure a lot of *nix developers will be surprised to hear about that.
>>
>> You might also want to re-write the entire Wikipedia page on x86 calling
>> conventions:
>>
>> <https://en.wikipedia.org/wiki/X86_calling_conventions>
>>
>
> There is the truth, and there is Wikipedia. SOMETIMES they coincide.
>
> PASCAL, FORTRAN, etc. use an entirely different calling convention than
> C. They push left to right, and the called function pops the stack. C
> pushes right to left, and the caller pops the stack. The two are not
> compatible. C can use the PASCAL calling convention; PASCAL cannot use
> the C calling convention.

Please point me to the part of the C standard that explains how it
supports "PASCAL calling convention". In fact, feel free to show me
where it refers to any sort of calling conventions at all.

You might find that /some/ C compilers support what you refer to as
"PASCAL calling convention". In particular, some C compilers for
Windows will support it - because that was the calling convention used
by 16-bit Windows APIs. Similarly, 32-bit C compilers for Windows will
support "stdcall", because that is the convention used for 32-bit
Windows API. gcc also provides support for a range of calling
conventions on x86 even for *nix targets - it's flexible that way. But
it would not surprise me if *nix only compilers such as Sun's compiler
only support their native calling convention.

As for the calling conventions Pascal can use, there has only been one
serious Pascal compiler - Delphi (for Windows, with a brief foray into
the Linux world), and it supports a range of calling conventions
including "cdecl".


>
> stdcall is just a variation of the PASCAL calling convention.

>
>>
>>>>>
>>>>> You cannot say the same with object files, even with the PASCAL calling
>>>>> convention. There is no standard format, and every compiler is free to
>>>>> define it's own.
>>>>

>>>> This is incorrect:
>>>>
>>>> https://refspecs.linuxfoundation.org/elf/gabi41.pdf (chapter 4)
>>>> http://www.x86-64.org/documentation/abi.pdf (chapter 4)
>>>>
>>>
>>> Then please explain why I can't do the above.
>>>
>>
>
> No explanation?
>

I have no idea why you can't do whatever it was you couldn't do "the
above" - I've forgotten what you are referring to here. My first guess
is that since you say you can't do "the above", and you seem to get
almost everything wrong (until you change your mind without admitting
it), you probably /could/ do "the above". My second guess is that just
because /you/ can't do it, does not mean other people can't do it. But
maybe, by sheer fluke, you are right and "the above" cannot be done.

What is certain, however, is that there is no point in my going back in
the thread to figure out what "the above" is, and trying to explain
things to you - experience shows it is more efficient to assume you are
wrong, and unable and unwilling to think or learn from anything anybody
else says.

This is your queue to make comments about teaching pigs to sing because
you think it is such a clever and witty remark that we will all bow to
your obvious knowledge and experience (after all, you worked for IBM!).

[Richard]

[Please do not mail me a copy of your followup]

Gareth Owen <gwo...@gmail.com> spake the secret code
<87shy8n...@gmail.com> thusly:

>Jerry Stuckle <jstu...@attglobal.net> writes:
>
>> How many compilers other than gcc have you used on *nix? gcc is not the
>> only one (and never has been).
>

>Sun CC (multiple versions), clang, gcc, DEC Alpha CC, DEC f77 and f95.

I'm surprised not to see MIPSpro C++/FORTRAN compilers in there :)
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Jerry Stuckle]

It's not required by the C standard - but it is required by the OS for
language-neutral libraries.

> You might find that /some/ C compilers support what you refer to as
> "PASCAL calling convention". In particular, some C compilers for
> Windows will support it - because that was the calling convention used
> by 16-bit Windows APIs. Similarly, 32-bit C compilers for Windows will
> support "stdcall", because that is the convention used for 32-bit
> Windows API. gcc also provides support for a range of calling
> conventions on x86 even for *nix targets - it's flexible that way. But
> it would not surprise me if *nix only compilers such as Sun's compiler
> only support their native calling convention.
>

That's because the OS libraries use it for its libraries. That way
those libraries can be called by any language. And although I hate to
use Wikipedia as a reference, it is somewhat accurate in this case:
https://en.wikipedia.org/wiki/X86_calling_conventions

> As for the calling conventions Pascal can use, there has only been one
> serious Pascal compiler - Delphi (for Windows, with a brief foray into
> the Linux world), and it supports a range of calling conventions
> including "cdecl".
>

Wrong again. There have been a number of "serious" Pascal compilers. I
was using one even back in 1982 - long before Delphi. Even UCSD had a
Pascal compiler for CPC in the late 70's. It never caught on big, but
was used by a lot of companies (and taught in the universities) in the
70's and 80's. But companies went away from it for a number of (valid)
reasons.

>
>>
>> stdcall is just a variation of the PASCAL calling convention.
>>
>>>
>>>>>>
>>>>>> You cannot say the same with object files, even with the PASCAL
>>>>>> calling
>>>>>> convention. There is no standard format, and every compiler is
>>>>>> free to
>>>>>> define it's own.
>>>>>
>>>>> This is incorrect:
>>>>>
>>>>> https://refspecs.linuxfoundation.org/elf/gabi41.pdf (chapter 4)
>>>>> http://www.x86-64.org/documentation/abi.pdf (chapter 4)
>>>>>
>>>>
>>>> Then please explain why I can't do the above.
>>>>
>>>
>>
>> No explanation?
>>
>
> I have no idea why you can't do whatever it was you couldn't do "the
> above" - I've forgotten what you are referring to here. My first guess
> is that since you say you can't do "the above", and you seem to get
> almost everything wrong (until you change your mind without admitting
> it), you probably /could/ do "the above". My second guess is that just
> because /you/ can't do it, does not mean other people can't do it. But
> maybe, by sheer fluke, you are right and "the above" cannot be done.
>

Nope, you have a habit of skipping answers which conflict with your
limited knowledge, and then claim you don't know what someone is talking
about.

> What is certain, however, is that there is no point in my going back in
> the thread to figure out what "the above" is, and trying to explain
> things to you - experience shows it is more efficient to assume you are
> wrong, and unable and unwilling to think or learn from anything anybody
> else says.
>

Of course not. It would conflict with your limited knowledge.

> This is your queue to make comments about teaching pigs to sing because
> you think it is such a clever and witty remark that we will all bow to
> your obvious knowledge and experience (after all, you worked for IBM!).
>

Did you ever figure out how to determine at compile time whether a
program was being built on a big endian or a little endian machine?

I thought not. So much for your "expertise".

[Jerry Stuckle]

On 4/27/2016 2:44 PM, Gareth Owen wrote:
> Jerry Stuckle <jstu...@attglobal.net> writes:
>
>> And you were able to link Sun CC object files with DEC Alpha CC programs?
>
> No because they were different architectures. Nobody ever suggested
> that. It was merely asser
>

So that wasn't an answer to my question, was it. Just another red herring.

> But I could link SunCC .o objects with native gcc .o objects on the Sun
> machine.
>
> And I could link DEC Fortran .o objects with native gcc objects on the
> DEC machine.
>
>> If so, the rest of the world would love to know how you did it.
>
> Glad to see even you are no longer what you originally asserted.
>

No change on this end at all. But you just keep throwing out red
herrings as "proof". It doesn't work.

[Jerry Stuckle]

Wrong answer, Gareth. There is much more that needs to be done than
just concatenating files. Otherwise, why would you even need ar?

[Jerry Stuckle]

Yes, but it is those *few other things* and the fact they are placed in
a standard format that is important. .o files need not be in the same
format, and a different compiler may very well have an equivalent to ar
for their files. Nothing prevents it - in fact, compilers generally
*do* have utilities such as ar included.

[Gareth Owen]

Jerry Stuckle <jstu...@attglobal.net> writes:

> On 4/27/2016 2:44 PM, Gareth Owen wrote:
>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>
>>> And you were able to link Sun CC object files with DEC Alpha CC programs?
>>
>> No because they were different architectures. Nobody ever suggested
>> that. It was merely asser
>>
>
> So that wasn't an answer to my question, was it. Just another red herring.

Huh?

[Gareth Owen]

Jerry Stuckle <jstu...@attglobal.net> writes:

> On 4/27/2016 2:47 PM, Gareth Owen wrote:
>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>
>>> Yes, the format of the object files IN THE LIBRARY are standard.
>>> That does not mean they were not changed when being inserted into the
>>> library.
>>
>> So your assertion is that building .a files by running "ar" on Unix .o
>> files fundamentally changes the layout of those files, rather than being
>> mostly concatentation?
>>
>> That assertion is false.
>>
>
> Wrong answer, Gareth. There is much more that needs to be done than
> just concatenating files. Otherwise, why would you even need ar?

It's concatenating with the addition of headers for locating the objects
within the archive. There is no change to the structure of the objects.

But I don't need to convince you.
I can confirm my beliefs with a simple experiment:

gowen@felix:~$ cat foo.c

int foo(int x, int y)
{
return x-y;
}

gowen@felix:~$ cc -c foo.c -o foo.o

gowen@felix:~$ ar rcs foo.a foo.o

gowen@felix:~$ ls -l foo.[ao]
-rw-rw-r-- 1 gowen gowen 1380 Apr 27 20:52 foo.a
-rw-rw-r-- 1 gowen gowen 1240 Apr 27 20:52 foo.o

gowen@felix:~$ cat foo.o | md5sum
adb30c5f32e1dccb926beee7faca54a5 -

gowen@felix:~$ tail -c 1240 foo.a | md5sum
adb30c5f32e1dccb926beee7faca54a5 -

So, that'll be 140 bytes of header, followed by the object file,
unmodified in its entirety.

[Christian Gollwitzer]

Am 27.04.16 um 21:45 schrieb Jerry Stuckle:

> On 4/27/2016 2:47 PM, Gareth Owen wrote:
>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>
>>> Yes, the format of the object files IN THE LIBRARY are standard.
>>> That does not mean they were not changed when being inserted into the
>>> library.
>>
>> So your assertion is that building .a files by running "ar" on Unix .o
>> files fundamentally changes the layout of those files, rather than being
>> mostly concatentation?
>>
>> That assertion is false.
>>
>
> Wrong answer, Gareth. There is much more that needs to be done than
> just concatenating files. Otherwise, why would you even need ar?
>

If you doubt that, look into the source code of ar. ar can even compile
any old file, it doesn't need to be a valido object file in any sense.
If you have some Linux handy, try:

Apfelkiste:artest chris$ echo This is file one > f1.txt
Apfelkiste:artest chris$ echo "rubbischöäü" >f2.txt
Apfelkiste:artest chris$ ar cr mylibfile.a *.txt
Apfelkiste:artest chris$ ls -lh
total 24
-rw-r--r-- 1 chris staff 17B 27 Apr 22:00 f1.txt
-rw-r--r-- 1 chris staff 15B 27 Apr 22:00 f2.txt
-rw-r--r-- 1 chris staff 162B 27 Apr 22:00 mylibfile.a
Apfelkiste:artest chris$ cat mylibfile.a
!<arch>
f1.txt 1461787213 501 20 100644 17 `
This is file one

f2.txt 1461787222 501 20 100644 15 `
rubbischöäü

As you can clearly see, the ar file format is extremely simple. All this
is valid for the Unix world only, which is why Scott is constantly
talking about "*nix"

Christian

[Robert Wessel]

On Wed, 27 Apr 2016 15:47:35 -0400, Jerry Stuckle

The (complete) list of the "few other things" is (in addition to the
file name, timestamp and size): owner ID, group ID, file mode and a
magic value of 0x60, 0x0a. There's nothing in a standard .a the
relates to the contents being object files. There are a few minor
variants of the ar format, mostly different extensions for handling
long filenames.

>Nothing prevents it - in fact, compilers generally
>*do* have utilities such as ar included.

In neither *nix or Windows is it necessary for the "standard" for
object files and libraries to be followed, so long as the resulting
executable ends up in the format expected by the loader (and even that
can be worked around to some extent if you want to provide a stub
loader). But if you don't, you end up not being able to use all of
the various tools and that can normally interoperate because they use
the same object file format. Again, more common on Windows.

[Christian Gollwitzer]

Am 27.04.16 um 19:42 schrieb Jerry Stuckle:

It's true that you can't link two object files of arbitrary compilers,
noone said that. But on Unix, *contemporary* compilers produce
compatible object files. On Linux you can have gcc, clang, Intel C++ and
tcc (the simple compiler), and they all are compatible with each other.
If you search long enough, you'll find some compiler with an
incompatible format, say a gcc with a.out backend would do. But the ones
I list above are the important players today, and those are compatible.

Christian

[Gareth Owen]

Christian Gollwitzer <auri...@gmx.de> writes:

> If you search long enough, you'll find some compiler with an
> incompatible format, say a gcc with a.out backend would do.

And even then, if you had an incompatible .o file, running "ar" on it
would not, as Jerry seems to suggest, magically fix up those
incompatibilities.

[Ian Collins]

On 04/28/16 00:32, Jerry Stuckle wrote:
>
> Yes, the format of the object files IN THE LIBRARY are standard. That
> does not mean they were not changed when being inserted into the

> library. In fact, they have to be as, among other things external
> references need to be satisfied.

It looks like the night shift has already disproved this.

> But some people are SO DENSE.

and you have ably demonstrated this...

--
Ian Collins

[Richard]

[Please do not mail me a copy of your followup]

Ian Collins <ian-...@hotmail.com> spake the secret code
<docl9a...@mid.individual.net> thusly:

>On 04/28/16 00:32, Jerry Stuckle wrote:
>> But some people are SO DENSE.
>
>and you have ably demonstrated this...

Reading through the hilarious replies to Jerry Stuckle on this thread
have only confirmed my judgement to *plonk* him some time ago...

[Ian Collins]

On 04/28/16 09:50, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Ian Collins <ian-...@hotmail.com> spake the secret code
> <docl9a...@mid.individual.net> thusly:
>
>> On 04/28/16 00:32, Jerry Stuckle wrote:
>>> But some people are SO DENSE.
>>
>> and you have ably demonstrated this...
>
> Reading through the hilarious replies to Jerry Stuckle on this thread
> have only confirmed my judgement to *plonk* him some time ago...

Then you miss out on the fun :)

--
Ian Collins

[Jerry Stuckle]

On 4/27/2016 3:48 PM, Gareth Owen wrote:
> Jerry Stuckle <jstu...@attglobal.net> writes:
>
>> On 4/27/2016 2:44 PM, Gareth Owen wrote:
>>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>>
>>>> And you were able to link Sun CC object files with DEC Alpha CC programs?
>>>
>>> No because they were different architectures. Nobody ever suggested
>>> that. It was merely asser
>>>
>>
>> So that wasn't an answer to my question, was it. Just another red herring.
>
> Huh?
>

Yea, right.

[Jerry Stuckle]

On 4/27/2016 4:00 PM, Gareth Owen wrote:
> Jerry Stuckle <jstu...@attglobal.net> writes:
>
>> On 4/27/2016 2:47 PM, Gareth Owen wrote:
>>> Jerry Stuckle <jstu...@attglobal.net> writes:
>>>
>>>> Yes, the format of the object files IN THE LIBRARY are standard.
>>>> That does not mean they were not changed when being inserted into the
>>>> library.
>>>
>>> So your assertion is that building .a files by running "ar" on Unix .o
>>> files fundamentally changes the layout of those files, rather than being
>>> mostly concatentation?
>>>
>>> That assertion is false.
>>>
>>
>> Wrong answer, Gareth. There is much more that needs to be done than
>> just concatenating files. Otherwise, why would you even need ar?
>
> It's concatenating with the addition of headers for locating the objects
> within the archive. There is no change to the structure of the objects.
>

When you use the gcc compiler and tools, that is.

> But I don't need to convince you.
> I can confirm my beliefs with a simple experiment:
>
> gowen@felix:~$ cat foo.c
>
> int foo(int x, int y)
> {
> return x-y;
> }
>
> gowen@felix:~$ cc -c foo.c -o foo.o
>
> gowen@felix:~$ ar rcs foo.a foo.o
>
> gowen@felix:~$ ls -l foo.[ao]
> -rw-rw-r-- 1 gowen gowen 1380 Apr 27 20:52 foo.a
> -rw-rw-r-- 1 gowen gowen 1240 Apr 27 20:52 foo.o
>
> gowen@felix:~$ cat foo.o | md5sum
> adb30c5f32e1dccb926beee7faca54a5 -
>
> gowen@felix:~$ tail -c 1240 foo.a | md5sum
> adb30c5f32e1dccb926beee7faca54a5 -
>
> So, that'll be 140 bytes of header, followed by the object file,
> unmodified in its entirety.
>

Yup, when you use the gcc compiler and tools.

[Jerry Stuckle]

On 4/27/2016 4:20 PM, Ian Collins wrote:
> On 04/28/16 00:32, Jerry Stuckle wrote:
>>
>> Yes, the format of the object files IN THE LIBRARY are standard. That
>> does not mean they were not changed when being inserted into the
>> library. In fact, they have to be as, among other things external
>> references need to be satisfied.
>
> It looks like the night shift has already disproved this.
>

Yup, a shift you obviously have no inkling of.

>> But some people are SO DENSE.
>
> and you have ably demonstrated this...
>

Yes, you definitely have.

[Jerry Stuckle]

Ah, but people have said that any .o files from any compiler are
compatible - see all of the posts in this thread.

And "important players" is a matter of opinion. A compiler is quite
important if you need to use it for a specific instance.

[Jerry Stuckle]

It does if you use the ar from the appropriate toolkit.

[Jerry Stuckle]

Which is exactly what I have been saying, but people have been arguing.
.o files don't necessarily need to be compatible, as long as the library
and executable files which are generated are compatible.

Object file formats do NOT need to be anywhere near the same as library
(static or dynamic) file formats, as long as there are tools which
convert them to OS-dependent standard formats.

[Öö Tiib]

Jerry, you go too far here in that denial. The 'ar' is Unix utility
(pretty much like 'tar') and not some sort of gcc tool.

[Ian Collins]

On 04/28/16 13:12, Jerry Stuckle wrote:
> On 4/27/2016 4:20 PM, Gareth Owen wrote:
>> Christian Gollwitzer <auri...@gmx.de> writes:
>>
>>> If you search long enough, you'll find some compiler with an
>>> incompatible format, say a gcc with a.out backend would do.
>>
>> And even then, if you had an incompatible .o file, running "ar" on it
>> would not, as Jerry seems to suggest, magically fix up those
>> incompatibilities.
>>
>
> It does if you use the ar from the appropriate toolkit.

The only "toolkit" ar comes from is the operating system.

--
Ian Collins

[Ian Collins]

http://pubs.opengroup.org/onlinepubs/9699919799/

--
Ian Collins

[Gareth Owen]

Jerry Stuckle <jstu...@attglobal.net> writes:

> Which is exactly what I have been saying, but people have been arguing.
> .o files don't necessarily need to be compatible, as long as the library
> and executable files which are generated are compatible.
>
> Object file formats do NOT need to be anywhere near the same as library
> (static or dynamic) file formats, as long as there are tools which
> convert them to OS-dependent standard formats.

They do not *have* to be -- no-one ever said they had to be, because we
all now that on Windows, they are not.

On Unix, they *are*, and you -- despite your claims of great experience
-- have yet to state a single unix platform / compiler toolchain on
which this is not the case. Nor have you named a single toolchain on
which 'ar' performs any non-trivial modification of the object format.

So put up or shut up - from your vast claimed experience -- on what Unix
platform did 'ar' make such transformations, and what was the nature of
those transformations?

Name a platform.

[Gareth Owen]

Jerry Stuckle <jstu...@attglobal.net> writes:

> Ah, but people have said that any .o files from any compiler are
> compatible - see all of the posts in this thread.

On which Unix platform is this not true?

> And "important players" is a matter of opinion. A compiler is quite
> important if you need to use it for a specific instance.

Which Unix compiler - important or otherwise - produces .o files
incompatible from the native compiler for that platform?

Name the compiler.

[David Brown]

On /windows/, Pascal-like calling conventions are used for the Win16 and
Win32 APIs. Thus on /windows/, it is the calling convention used by
/dynamic/ libraries, and programming languages and their compilers that
want to directly call functions in /dynamic/ libraries must support it.
And we have already established that on /windows/, there is no standard
for static libraries or object code formats, with every tool picking
their own methods.

On *nix, C like calling conventions are the standard, and are used by
dynamic libraries, static libraries and object code. After all, the OS
kernel is written in C, the standard libraries are written in C, and a
fair percentage of the applications are written in C. Why would you
possibly imagine that the ABI would specify something other than C
calling conventions for libraries? How would printf work? (Variable
argument functions are easily handled with C calling conventions, but
not with Pascal conventions.)

>
>> You might find that /some/ C compilers support what you refer to as
>> "PASCAL calling convention". In particular, some C compilers for
>> Windows will support it - because that was the calling convention used
>> by 16-bit Windows APIs. Similarly, 32-bit C compilers for Windows will
>> support "stdcall", because that is the convention used for 32-bit
>> Windows API. gcc also provides support for a range of calling
>> conventions on x86 even for *nix targets - it's flexible that way. But
>> it would not surprise me if *nix only compilers such as Sun's compiler
>> only support their native calling convention.
>>
>
> That's because the OS libraries use it for its libraries. That way
> those libraries can be called by any language. And although I hate to
> use Wikipedia as a reference, it is somewhat accurate in this case:
> https://en.wikipedia.org/wiki/X86_calling_conventions

If you try reading that page, you will perhaps notice that there is no
such thing as "the OS" - there are many operating systems, and each may
have its own calling conventions for its APIs and standard libraries.
*nix systems (including Linux) use a single C calling convention for the
API and within object files. On Windows, there is one calling
convention ("stdcall") for the main APIs, but there are a variety of
other conventions in common use, and different tools use different
conventions by default.

This is why people have been discussing *nix systems, where these things
are specified and different tools all cooperate, rather than the Windows
world (and its DOS predecessor) where there is a jumble of local
conventions, often designed specifically for vendor lock-in rather than
cooperation.

>
>> As for the calling conventions Pascal can use, there has only been one
>> serious Pascal compiler - Delphi (for Windows, with a brief foray into
>> the Linux world), and it supports a range of calling conventions
>> including "cdecl".
>>
>
> Wrong again. There have been a number of "serious" Pascal compilers. I
> was using one even back in 1982 - long before Delphi. Even UCSD had a
> Pascal compiler for CPC in the late 70's. It never caught on big, but
> was used by a lot of companies (and taught in the universities) in the
> 70's and 80's. But companies went away from it for a number of (valid)
> reasons.

Yes, there have been other Pascals. But the users of Delphi and its
predecessors Borland Pascal and Turbo Pascal probably outweigh the
combined number of users for every other Pascal by a factor of a hundred.

And any Pascal implementation that is capable of accessing external
library code directly (rather than through wrappers provided by the
implementation) will have to support the calling conventions of the
target OS. On Windows, that means "stdcall" - on *nix, that means C
calling conventions. I don't know what calling conventions were used on
UCSD P-code systems - I was perhaps 9 or 10 when I used that on a VAX,
and did not get far beyond a "Hello, world" program.

>
>>
>>>
>>> stdcall is just a variation of the PASCAL calling convention.
>>>
>>>>
>>>>>>>
>>>>>>> You cannot say the same with object files, even with the PASCAL
>>>>>>> calling
>>>>>>> convention. There is no standard format, and every compiler is
>>>>>>> free to
>>>>>>> define it's own.
>>>>>>
>>>>>> This is incorrect:
>>>>>>
>>>>>> https://refspecs.linuxfoundation.org/elf/gabi41.pdf (chapter 4)
>>>>>> http://www.x86-64.org/documentation/abi.pdf (chapter 4)
>>>>>>
>>>>>
>>>>> Then please explain why I can't do the above.
>>>>>
>>>>
>>>
>>> No explanation?
>>>
>>
>> I have no idea why you can't do whatever it was you couldn't do "the
>> above" - I've forgotten what you are referring to here. My first guess
>> is that since you say you can't do "the above", and you seem to get
>> almost everything wrong (until you change your mind without admitting
>> it), you probably /could/ do "the above". My second guess is that just
>> because /you/ can't do it, does not mean other people can't do it. But
>> maybe, by sheer fluke, you are right and "the above" cannot be done.
>>
>
> Nope, you have a habit of skipping answers which conflict with your
> limited knowledge, and then claim you don't know what someone is talking
> about.

The only thing I can guess you meant was:

"""
Then why aren't object files compatible across compilers and operating
systems? If it were generated with gcc on Linux, I should be able to
link it in using a Microsoft compiler on Windows.
"""

But that has already been answered by others.

>
>> What is certain, however, is that there is no point in my going back in
>> the thread to figure out what "the above" is, and trying to explain
>> things to you - experience shows it is more efficient to assume you are
>> wrong, and unable and unwilling to think or learn from anything anybody
>> else says.
>>
>
> Of course not. It would conflict with your limited knowledge.

Assuming I have guessed the correct question, Scott's answer does not
"conflict with my limited knowledge" - it matches perfectly with what I
know.

(And yes, my knowledge /is/ limited, as is everybody's. But the
difference between you and everyone else in this thread is that we all
/know/ that our knowledge is limited, and are happy to look up
references, ask questions, state our uncertainties or correct our
mistakes. You, on the other hand, seem quite happy to pontificate with
a total confidence even when your claims are pure fantasy, and everyone
around you is laughing. I am sure you would make an excellent poker
player, but I am very glad I don't have to deal with you professionally.)

>
>> This is your queue to make comments about teaching pigs to sing because
>> you think it is such a clever and witty remark that we will all bow to
>> your obvious knowledge and experience (after all, you worked for IBM!).
>>
>
> Did you ever figure out how to determine at compile time whether a
> program was being built on a big endian or a little endian machine?

Um, what /exactly/ does that have to do with the topic under discussion
here?

There is no implementation-independent way to do this in C or C++. I
have never claimed otherwise. There are many implementation-dependent
ways - most compilers that target multiple platforms have pre-defined
macros that can be tested, and there are libraries (such as from boost)
that combine a range of these tests for convenience.

With C++11 or C++14 constexpr functions, it is possible that there is a
way to do it - but that would only give you limited capabilities. In
particular, to be really useful, you need the endianness to be testable
in the preprocessor.

>
> I thought not. So much for your "expertise".
>

If you can post a completely implementation-independent method of
determining the endianness of a target at compile time, using nothing
but the features required in one of the C or C++ standards (pick any one
you like), I will happily admit to being wrong in this case. The result
must be a "constant expression" - legally usable for things like
template instantiation. It is not sufficient to give an expression that
a compiler can often optimise away at compile time. Bonus points if it
is testable in the pre-processor.

You have raised this challenge - now it is up to you. If you can post
such code, your standing on Usenet will increase significantly.
Certainly I will publicise your success in c.l.c and c.l.c++, and it
will be seen even by the many people who have killfiled you. If not,
then your reputation - low as it is - will drop further.

[Christian Gollwitzer]

Am 28.04.16 um 10:13 schrieb David Brown:

> If you can post a completely implementation-independent method of
> determining the endianness of a target at compile time, using nothing
> but the features required in one of the C or C++ standards (pick any one
> you like), I will happily admit to being wrong in this case. The result
> must be a "constant expression" - legally usable for things like
> template instantiation. It is not sufficient to give an expression that
> a compiler can often optimise away at compile time. Bonus points if it
> is testable in the pre-processor.
>
> You have raised this challenge - now it is up to you. If you can post
> such code, your standing on Usenet will increase significantly.

Be careful with such a challenge. He might fight the referee. After
posting a near shot to the solution, he will then refrain to admit that
he is wrong.

For instance, a practical test would be

const int dummy = 1;
bool little_endian = *(reinterpret_cast<char *> (&dummy));

Of course, this test is not covered by any standard, so it fails your
challenge, but still will give the answer that most people want to know
on platforms, where endianness is a reasonable question to ask - because
what people really want to know IMHO, is the binary serialization of
native datatypes, when you access it from a char array, in order to do
binary I/O. Otherwise there is no need to care about memory layout at
all. Probably any program which has the need to query endianness will
never have a chance to run on exotic platforms where sizeof(int) ==
sizeof(char), or two's complement isn't used etc.

Christian

[Öö Tiib]

On Thursday, 28 April 2016 11:34:23 UTC+3, Christian Gollwitzer wrote:
> Am 28.04.16 um 10:13 schrieb David Brown:
> > If you can post a completely implementation-independent method of
> > determining the endianness of a target at compile time, using nothing
> > but the features required in one of the C or C++ standards (pick any one
> > you like), I will happily admit to being wrong in this case. The result
> > must be a "constant expression" - legally usable for things like
> > template instantiation. It is not sufficient to give an expression that
> > a compiler can often optimise away at compile time. Bonus points if it
> > is testable in the pre-processor.
> >
> > You have raised this challenge - now it is up to you. If you can post
> > such code, your standing on Usenet will increase significantly.
>
> Be careful with such a challenge. He might fight the referee. After
> posting a near shot to the solution, he will then refrain to admit that
> he is wrong.
>
> For instance, a practical test would be
>
> const int dummy = 1;
> bool little_endian = *(reinterpret_cast<char *> (&dummy));

Read challenge carefully.
That code fails the challenge because 'little_endian' is not compile
time constant. Compile time would be something like that:

// FAIL, does compile nowhere
constexpr int dummy = 1;
constexpr bool little_endian = *(reinterpret_cast<char *> (&dummy));

> Of course, this test is not covered by any standard, so it fails your
> challenge, but still will give the answer that most people want to know
> on platforms, where endianness is a reasonable question to ask - because
> what people really want to know IMHO, is the binary serialization of
> native datatypes, when you access it from a char array, in order to do
> binary I/O.

Yes, read more carefully and try to express yourself with shorter sentences.

[David Brown]

As has been pointed out by Öö, this is not determined at compile time.
It's easy to determine endianness at run time in this manner (and it is
possible to make it more robust in the face of awkward platforms, such
as by using "unsigned long long" rather than "int" - though I am not
sure if this is valid for every platform).

Sometimes knowing endianness at runtime (especially if the compiler can
optimise the test) is good enough - but often it is not.

[Scott Lurndal]

Jerry Stuckle <jstu...@attglobal.net> writes:
>On 4/27/2016 1:37 PM, Scott Lurndal wrote:

>

>Believe I've been working with unix for probably a lot longer than you
>have - back around 1979 (although not continuously since that time)

1977.

[Scott Lurndal]

Jerry Stuckle <jstu...@attglobal.net> writes:
>On 4/27/2016 2:47 PM, Gareth Owen wrote:

>>
>> So your assertion is that building .a files by running "ar" on Unix .o
>> files fundamentally changes the layout of those files, rather than being
>> mostly concatentation?
>>
>> That assertion is false.
>>
>
>Wrong answer, Gareth. There is much more that needs to be done than
>just concatenating files. Otherwise, why would you even need ar?

Use the source, luke.

http://ftp.gnu.org/gnu/binutils/binutils-2.26.tar.gz

[Jerry Stuckle]

Which does not mean that other tools can't include their own versions of
library creation tools.

[Jerry Stuckle]

Which does not prohibit another toolkit from having their own version.

I find it interesting that Linux programmers, who spend virtually all
their time with one OS and one compiler, think the entire world works
that way.

It doesn't, as people who work on multiple OS's and with multiple
compilers understand.

[Jerry Stuckle]

Very interesting, since Unix had very limited usage in 1977 - mainly in
the educational world. Not even AT&T was using it very much for production.

[Jerry Stuckle]

Functions like printf are part of the C library, so of course they use C
calling conventions. You don't call them from PASCAL or COBOL, for
instance.

But non-C derived languages such as FORTRAN and COBOL do not use C
calling conventions.

And BTW - Windows is written in C, also. So are the Windows libraries.
But the calling convention into the system libraries is not C.

Yes, there are many different OS's. But if you want to be able to use
languages such as Fortran and Cobol, the OS libraries need to use
calling conventions supported by those languages.

>>
>>> As for the calling conventions Pascal can use, there has only been one
>>> serious Pascal compiler - Delphi (for Windows, with a brief foray into
>>> the Linux world), and it supports a range of calling conventions
>>> including "cdecl".
>>>
>>
>> Wrong again. There have been a number of "serious" Pascal compilers. I
>> was using one even back in 1982 - long before Delphi. Even UCSD had a
>> Pascal compiler for CPC in the late 70's. It never caught on big, but
>> was used by a lot of companies (and taught in the universities) in the
>> 70's and 80's. But companies went away from it for a number of (valid)
>> reasons.
>
> Yes, there have been other Pascals. But the users of Delphi and its
> predecessors Borland Pascal and Turbo Pascal probably outweigh the
> combined number of users for every other Pascal by a factor of a hundred.
>

Once again, your ignorance shows. For one thing, there were millions of
students around the world using UCSD Pascal in the late 70's and early
80's - ling before Delphi, Borland Pascal, and so on. It was a common
language taught in many universities.

But beyond that, large and medium companies (including IBM) used Pascal
extensively in the 1980's. But they were using enterprise grade
products, not Delphi.

> And any Pascal implementation that is capable of accessing external
> library code directly (rather than through wrappers provided by the
> implementation) will have to support the calling conventions of the
> target OS. On Windows, that means "stdcall" - on *nix, that means C
> calling conventions. I don't know what calling conventions were used on
> UCSD P-code systems - I was perhaps 9 or 10 when I used that on a VAX,
> and did not get far beyond a "Hello, world" program.
>

The calling conventions were similar, for those machines which had a
hardware stack. For those without one, values were placed in a
"parameter passing area" and the address of that area placed in a register.

No, the difference is your "knowledge", AFAICT, is based pretty much on
one set of tools on one OS. And you think the rest of the world works
that way.

>
>>
>>> This is your queue to make comments about teaching pigs to sing because
>>> you think it is such a clever and witty remark that we will all bow to
>>> your obvious knowledge and experience (after all, you worked for IBM!).
>>>
>>
>> Did you ever figure out how to determine at compile time whether a
>> program was being built on a big endian or a little endian machine?
>
> Um, what /exactly/ does that have to do with the topic under discussion
> here?
>
> There is no implementation-independent way to do this in C or C++. I
> have never claimed otherwise. There are many implementation-dependent
> ways - most compilers that target multiple platforms have pre-defined
> macros that can be tested, and there are libraries (such as from boost)
> that combine a range of these tests for convenience.
>
> With C++11 or C++14 constexpr functions, it is possible that there is a
> way to do it - but that would only give you limited capabilities. In
> particular, to be really useful, you need the endianness to be testable
> in the preprocessor.
>

Just a question - a problem similar to what consultants have to solve on
a regular basis. Just seeing if you really knew what you were talking
about. I see you don't.

>>
>> I thought not. So much for your "expertise".
>>
>
> If you can post a completely implementation-independent method of
> determining the endianness of a target at compile time, using nothing
> but the features required in one of the C or C++ standards (pick any one
> you like), I will happily admit to being wrong in this case. The result
> must be a "constant expression" - legally usable for things like
> template instantiation. It is not sufficient to give an expression that
> a compiler can often optimise away at compile time. Bonus points if it
> is testable in the pre-processor.
>
> You have raised this challenge - now it is up to you. If you can post
> such code, your standing on Usenet will increase significantly.
> Certainly I will publicise your success in c.l.c and c.l.c++, and it
> will be seen even by the many people who have killfiled you. If not,
> then your reputation - low as it is - will drop further.
>

Yes, I raised the challenge. It's up to you to solve it. I have
(actually did several years ago). Come on, David, give it a go.

Or do you need someone to hand feed you everything?

[Ian Collins]

On 04/29/16 07:29, Jerry Stuckle wrote:
> On 4/28/2016 12:21 AM, Ian Collins wrote:
>> On 04/28/16 13:12, Jerry Stuckle wrote:
>>> On 4/27/2016 4:20 PM, Gareth Owen wrote:
>>>> Christian Gollwitzer <auri...@gmx.de> writes:
>>>>
>>>>> If you search long enough, you'll find some compiler with an
>>>>> incompatible format, say a gcc with a.out backend would do.
>>>>
>>>> And even then, if you had an incompatible .o file, running "ar" on it
>>>> would not, as Jerry seems to suggest, magically fix up those
>>>> incompatibilities.
>>>>
>>>
>>> It does if you use the ar from the appropriate toolkit.
>>
>> The only "toolkit" ar comes from is the operating system.
>>
>
> Which does not prohibit another toolkit from having their own version.

Name one.

> I find it interesting that Linux programmers, who spend virtually all
> their time with one OS and one compiler, think the entire world works
> that way.

I'm not a Linux programmer.

--
Ian Collins

[Paavo Helde]

On 28.04.2016 22:48, Jerry Stuckle wrote:
> Just a question - a problem similar to what consultants have to solve on
> a regular basis.

I think we really do have a highly-paid consultant here! And he
routinely solves the unsolvable problems! Why don't we just sit all back
in awe and watchen das blinkenlights?

As for solving the endianness problem, the practical solution (as
opposed to "complete, portable and standard-conforming solution") is
indeed really simple:

#include <boost/detail/endian.hpp>

#if defined(BOOST_LITTLE_ENDIAN)
const bool bigEndian = false;
#elif defined(BOOST_BIG_ENDIAN)
const bool bigEndian = true;
#else
#error Unsupported platform.
#endif

[Christian Gollwitzer]

Am 28.04.16 um 11:33 schrieb David Brown:

> On 28/04/16 10:34, Christian Gollwitzer wrote:
>> For instance, a practical test would be
>>
>> const int dummy = 1;
>> bool little_endian = *(reinterpret_cast<char *> (&dummy));
>>

>> Christian
>
> As has been pointed out by Öö, this is not determined at compile time.

Yes I understand that part. I was not trying advertise this as a
solution to the challenge, rather I'm expecting that J. posts something
like this and then refuses to accept the criticism.

Indeed he has posted, but in an even more non-answering way.

> It's easy to determine endianness at run time in this manner (and it is
> possible to make it more robust in the face of awkward platforms, such
> as by using "unsigned long long" rather than "int" - though I am not
> sure if this is valid for every platform).
>
> Sometimes knowing endianness at runtime (especially if the compiler can
> optimise the test) is good enough - but often it is not.

OK I only see two practical solutions, practical in a sense that they
are widely applied:

* Use one of the pre-made header files which guess the endianness from
compiler-specific macros

* Use a separate pass, e.g. run autoconf to determine the endianness at
runtime and then pass a macro to the compiler

I've seen both methods in library code. None of them solves your
challenge, though.


Christian

[David Brown]

On 28/04/16 21:48, Jerry Stuckle wrote:
> On 4/28/2016 4:13 AM, David Brown wrote:
>> On 27/04/16 21:42, Jerry Stuckle wrote:
>>> On 4/27/2016 3:23 PM, David Brown wrote:
>>>> On 26/04/16 22:38, Jerry Stuckle wrote:

<snip>

>
> But non-C derived languages such as FORTRAN and COBOL do not use C
> calling conventions.

Languages can use whatever calling conventions they want for their own
code, and whatever calling convention the system uses for its libraries
(especially shared libraries and its main APIs) for calling external
functions. So Fortran on Windows will provide some way of calling
"stdcall" functions, and Fortran on *nix will provide some way of
calling "cdecl" functions.

>
> And BTW - Windows is written in C, also. So are the Windows libraries.
> But the calling convention into the system libraries is not C.

The calling convention of Windows system libraries and DLL's is not C
(or "cdecl"), because historically Win32 comes from Win16, which in turn
comes from DOS - and DOS was mainly written in assembler. Different
parts of Windows through the ages have been written in different
languages, with a gradual tendency to move from DOS through C then C++,
then various dotnet languages including VB and C#. The kernel itself is
most likely to be mainly C these days, but I am not privy to MS's
secrets here. However, historically MS's OS kernels were in assembler -
and as things gradually moved to higher level languages, the calling
convention had to remain the same as before in order to keep
compatibility and to allow the mixture to work. Thus MS Windows ended
up with a Pascal-like calling convention - because it was used in
assembly for DOS.

>> Yes, there have been other Pascals. But the users of Delphi and its
>> predecessors Borland Pascal and Turbo Pascal probably outweigh the
>> combined number of users for every other Pascal by a factor of a hundred.
>>
>
> Once again, your ignorance shows. For one thing, there were millions of
> students around the world using UCSD Pascal in the late 70's and early
> 80's - ling before Delphi, Borland Pascal, and so on. It was a common
> language taught in many universities.

People learned it at university, then forgot it afterwards - unless they
used Borland's tools on PC's. In terms of numbers, the people who
learned Pascal at university dwarfed the number of people who used it on
anything non-PC for actual work - and the number of people who used it
on PC's dwarfed those that worked with it on anything else.

>
> But beyond that, large and medium companies (including IBM) used Pascal
> extensively in the 1980's. But they were using enterprise grade
> products, not Delphi.
>

<snip>

>>>>>>>
>>>>>>> Then please explain why I can't do the above.
>>>>>>>
>>>>>>
>>>>>
>>>>> No explanation?
>>>>>
>>>>
>>>> I have no idea why you can't do whatever it was you couldn't do "the
>>>> above" - I've forgotten what you are referring to here. My first guess
>>>> is that since you say you can't do "the above", and you seem to get
>>>> almost everything wrong (until you change your mind without admitting
>>>> it), you probably /could/ do "the above". My second guess is that just
>>>> because /you/ can't do it, does not mean other people can't do it. But
>>>> maybe, by sheer fluke, you are right and "the above" cannot be done.
>>>>
>>>
>>> Nope, you have a habit of skipping answers which conflict with your
>>> limited knowledge, and then claim you don't know what someone is talking
>>> about.
>>
>> The only thing I can guess you meant was:
>>
>> """
>> Then why aren't object files compatible across compilers and operating
>> systems? If it were generated with gcc on Linux, I should be able to
>> link it in using a Microsoft compiler on Windows.
>> """
>>
>> But that has already been answered by others.
>>

Can I assume my guess was correct?

>>
>>>
>>>> What is certain, however, is that there is no point in my going back in
>>>> the thread to figure out what "the above" is, and trying to explain
>>>> things to you - experience shows it is more efficient to assume you are
>>>> wrong, and unable and unwilling to think or learn from anything anybody
>>>> else says.
>>>>
>>>
>>> Of course not. It would conflict with your limited knowledge.
>>
>> Assuming I have guessed the correct question, Scott's answer does not
>> "conflict with my limited knowledge" - it matches perfectly with what I
>> know.
>>
>> (And yes, my knowledge /is/ limited, as is everybody's. But the
>> difference between you and everyone else in this thread is that we all
>> /know/ that our knowledge is limited, and are happy to look up
>> references, ask questions, state our uncertainties or correct our
>> mistakes. You, on the other hand, seem quite happy to pontificate with
>> a total confidence even when your claims are pure fantasy, and everyone
>> around you is laughing. I am sure you would make an excellent poker
>> player, but I am very glad I don't have to deal with you professionally.)
>>
>
> No, the difference is your "knowledge", AFAICT, is based pretty much on
> one set of tools on one OS. And you think the rest of the world works
> that way.
>

That's interesting. And which OS do you think is the limit of my
knowledge? And which set of tools? I believe I have worked seriously
with perhaps 5 different host OS's over the years, not including
numerous home computers from the days before PC's were common place.
And I have used a number of different target OS's on systems from 8-bit
to 64-bit, and perhaps a dozen or fifteen different C compilers over the
years.

I have almost no experience with "big iron", so I don't extrapolate to
such systems.

I suspect that you, on the other hand, have a smattering of surface
knowledge about a number of different systems - and you extrapolate
wildly from there.

This, I think, is rather conclusive evidence that you have invented this
challenge to make yourself sound like an expert - but you cannot solve
it yourself.

Now, if Ian, Scott, Gareth or Öö in this thread had raised this
challenge and claimed that they had a solution, I'd believe them -
because they have a reputation for honesty and skill as developers.
You, on the other hand, have the opposite reputation - so without
concrete proof from you in terms of code that solves this challenge,
everyone will confidently assume that you either have no idea how to do
it, or you believe you do but you are mistaken.

No one needs to assume anything about /me/ in this case, because I have
made it perfectly clear that I don't believe it can be done, and
certainly don't know of any method. I have also made it clear that I
will be happy to be proven wrong here.

[Paavo Helde]

On 29.04.2016 0:00, Christian Gollwitzer wrote:
> Am 28.04.16 um 11:33 schrieb David Brown:
>> On 28/04/16 10:34, Christian Gollwitzer wrote:
>>> For instance, a practical test would be
>>>
>>> const int dummy = 1;
>>> bool little_endian = *(reinterpret_cast<char *> (&dummy));
>>>
>>> Christian
>>
>> As has been pointed out by Öö, this is not determined at compile time.

And would probably not work with a cross-compiler even if it
(mistakenly) allowed reinterpret_cast in a constexpr function.

> * Use a separate pass, e.g. run autoconf to determine the endianness at
> runtime and then pass a macro to the compiler

This does not work with a cross-compiler either.

Cheers
Paavo

[Jerry Stuckle]

On 4/28/2016 4:11 PM, Ian Collins wrote:
> On 04/29/16 07:29, Jerry Stuckle wrote:
>> On 4/28/2016 12:21 AM, Ian Collins wrote:
>>> On 04/28/16 13:12, Jerry Stuckle wrote:
>>>> On 4/27/2016 4:20 PM, Gareth Owen wrote:
>>>>> Christian Gollwitzer <auri...@gmx.de> writes:
>>>>>
>>>>>> If you search long enough, you'll find some compiler with an
>>>>>> incompatible format, say a gcc with a.out backend would do.
>>>>>
>>>>> And even then, if you had an incompatible .o file, running "ar" on it
>>>>> would not, as Jerry seems to suggest, magically fix up those
>>>>> incompatibilities.
>>>>>
>>>>
>>>> It does if you use the ar from the appropriate toolkit.
>>>
>>> The only "toolkit" ar comes from is the operating system.
>>>
>>
>> Which does not prohibit another toolkit from having their own version.
>
> Name one.
>

One of these days when I get around to it, I'll get ahold of one of my
past customers and see what they use. I don't remember right now, but
it wasn't gcc. However, it's not important enough for me to give a damn.

>> I find it interesting that Linux programmers, who spend virtually all
>> their time with one OS and one compiler, think the entire world works
>> that way.
>
> I'm not a Linux programmer.
>

We know that...

[Jerry Stuckle]

Not at all. But you are sooo stoopid it isn't even funny. And you can
assume whatever you want. It won't make anything true, and neither will
your repeating it as many times as you want.

No wonder you're an employee. You'd never make it as a consultant.

And BTW - I don't give a damn what YOU think about me. You aren't
paying the bills. And your opinion is completely worthless to me. I've
learned your type aren't worth it.

So I'll give you one more chance to prove you can think. But I know
you'll once again claim it "can't be done".