Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #73795 > unrolled thread

object file compatiblity

Back to article view | Back to comp.lang.c

Contents

  object file compatiblity paul.anton.letnes@gmail.com - 2015-10-25 14:11 -0700
    Re: object file compatiblity Ian Collins <ian-news@hotmail.com> - 2015-10-26 10:43 +1300
    Re: object file compatiblity James Kuyper <jameskuyper@verizon.net> - 2015-10-25 17:49 -0400
      Re: object file compatiblity Philipp Klaus Krause <pkk@spth.de> - 2015-10-25 22:53 +0100
        Re: object file compatiblity James Kuyper <jameskuyper@verizon.net> - 2015-10-25 18:29 -0400
      Re: object file compatiblity Keith Thompson <kst-u@mib.org> - 2015-10-25 15:00 -0700
      Re: object file compatiblity paul.anton.letnes@gmail.com - 2015-10-26 00:15 -0700
    Re: object file compatiblity Noob <root@127.0.0.1> - 2015-10-25 23:20 +0100
      Re: object file compatiblity paul.anton.letnes@gmail.com - 2015-10-26 00:21 -0700
    Re: object file compatiblity glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 03:14 +0000
      Re: object file compatiblity paul.anton.letnes@gmail.com - 2015-10-26 00:23 -0700
        Re: object file compatiblity Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-26 13:49 +0000
    Re: object file compatiblity Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-26 02:31 -0700
      Re: object file compatiblity Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-26 16:59 +0000
    Re: object file compatiblity "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-26 07:40 -0700

#73795 — object file compatiblity

Hi!

Disclaimer: I've programmed very little pure C in my life, and don't consider myself a C programmer. You probably don't, either.

I've got an object file that is difficult to recreate from source in my C/Fortran mixed-language project. This object file is generated from a C source file, but it's not written by me - build system nor source code. It's compiled by MSVC from visual studio 2013. Is this object file (.obj) compatible for linking with Visual Studio 2010/2012/2015 compiled code? What if I create a static library (.lib) containing this single object file?

What I've got in mind is checking the object file into git and linking it in with the rest of the project which is compiled from source every time. Colleagues might use other versions of MSVC/Visual Studio, though, so that's something I need to understand.

I'd appreciate any pointers to documentation that explains this in more detail.

Cheers
Paul

[toc] | [next] | [standalone]

#73799

paul.anton.letnes@gmail.com wrote:
> Hi!
>
> Disclaimer: I've programmed very little pure C in my life, and don't
> consider myself a C programmer. You probably don't, either.
>
> I've got an object file that is difficult to recreate from source in
> my C/Fortran mixed-language project. This object file is generated
> from a C source file, but it's not written by me - build system nor
> source code. It's compiled by MSVC from visual studio 2013. Is this
> object file (.obj) compatible for linking with Visual Studio
> 2010/2012/2015 compiled code? What if I create a static library
> (.lib) containing this single object file?
>
> What I've got in mind is checking the object file into git and
> linking it in with the rest of the project which is compiled from
> source every time. Colleagues might use other versions of MSVC/Visual
> Studio, though, so that's something I need to understand.
>
> I'd appreciate any pointers to documentation that explains this in
> more detail.

There isn't really a generic C answer to this question, the answer would 
be platform specific.  In general, with a reasonably long list of ifs it 
might work :)

The ifs would include the level of optimisation used, compiler options 
that may change the layout of data, platform ABI stability and so forth.

If the file does link, test it to death.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#73801

On 10/25/2015 05:11 PM, paul.anton.letnes@gmail.com wrote:
> Hi!
> 
> Disclaimer: I've programmed very little pure C in my life, and don't
> consider myself a C programmer. You probably don't, either.

Considering that you posted your question to comp.lang.c, I find it odd
that you think that probable. I learned C in 1979, and I've programmed
in pure C for roughly 25 of the years since that time.

Your actual question is specific to MSVC, which I haven't used since
1994, so I can't answer that question. I'm just commenting on your odd
initial comment.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#73803

On 25.10.2015 22:49, James Kuyper wrote:
> On 10/25/2015 05:11 PM, paul.anton.letnes@gmail.com wrote:
>> Hi!
>>
>> Disclaimer: I've programmed very little pure C in my life, and don't
>> consider myself a C programmer. You probably don't, either.
> 
> Considering that you posted your question to comp.lang.c, I find it odd
> that you think that probable. I learned C in 1979, and I've programmed
> in pure C for roughly 25 of the years since that time.

His sentence could be read to mean that you probably don't consider him
a C programmer, and that might well be the intended meaning.

Philipp

[toc] | [prev] | [next] | [standalone]

#73812

On 10/25/2015 05:53 PM, Philipp Klaus Krause wrote:
> On 25.10.2015 22:49, James Kuyper wrote:
>> On 10/25/2015 05:11 PM, paul.anton.letnes@gmail.com wrote:
>>> Hi!
>>>
>>> Disclaimer: I've programmed very little pure C in my life, and don't
>>> consider myself a C programmer. You probably don't, either.
>>
>> Considering that you posted your question to comp.lang.c, I find it odd
>> that you think that probable. I learned C in 1979, and I've programmed
>> in pure C for roughly 25 of the years since that time.
> 
> His sentence could be read to mean that you probably don't consider him
> a C programmer, and that might well be the intended meaning.

Ah - that makes more sense!

I've seen people posting to this forum implying that C is all but dead,
and that almost nobody writes in C anymore, so why are we losers still
talking about it here?  I just assumed he was expressing a similar idea.

[toc] | [prev] | [next] | [standalone]

#73807

James Kuyper <jameskuyper@verizon.net> writes:
> On 10/25/2015 05:11 PM, paul.anton.letnes@gmail.com wrote:
>> Disclaimer: I've programmed very little pure C in my life, and don't
>> consider myself a C programmer. You probably don't, either.
>
> Considering that you posted your question to comp.lang.c, I find it odd
> that you think that probable. I learned C in 1979, and I've programmed
> in pure C for roughly 25 of the years since that time.

Perhaps he meant that we probably don't consider him to be a C
programmer?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#73825

On Sunday, October 25, 2015 at 10:50:08 PM UTC+1, James Kuyper wrote:
> On 10/25/2015 05:11 PM, paul.anton.letnes@.com wrote:
> > Hi!
> > 
> > Disclaimer: I've programmed very little pure C in my life, and don't
> > consider myself a C programmer. You probably don't, either.
> 
> Considering that you posted your question to comp.lang.c, I find it odd
> that you think that probable. I learned C in 1979, and I've programmed
> in pure C for roughly 25 of the years since that time.
> 
> Your actual question is specific to MSVC, which I haven't used since
> 1994, so I can't answer that question. I'm just commenting on your odd
> initial comment.
> -- 
> James Kuyper

As others have alluded to, the meaning was that you will not consider me a C programmer. Glad to hear that there are experienced C programmers here.

Cheers
Paul

[toc] | [prev] | [next] | [standalone]

#73811

On 25/10/2015 22:11, paul.anton.letnes wrote:

> I've got an object file that is difficult to recreate from source in
> my C/Fortran mixed-language project. This object file is generated
> from a C source file, but it's not written by me - build system nor
> source code. It's compiled by MSVC from visual studio 2013. Is this
> object file (.obj) compatible for linking with Visual Studio
> 2010/2012/2015 compiled code? What if I create a static library
> (.lib) containing this single object file?
> 
> What I've got in mind is checking the object file into git and
> linking it in with the rest of the project which is compiled from
> source every time. Colleagues might use other versions of MSVC/Visual
> Studio, though, so that's something I need to understand.
> 
> I'd appreciate any pointers to documentation that explains this in
> more detail.

A related discussion:
https://programmers.stackexchange.com/questions/235706/are-c-object-files-created-with-different-compilers-binary-compatible

Regards.

[toc] | [prev] | [next] | [standalone]

#73826

On Sunday, October 25, 2015 at 11:21:01 PM UTC+1, Noob wrote:
> On 25/10/2015 22:11, paul.anton.letnes wrote:
> 
> > I've got an object file that is difficult to recreate from source in
> > my C/Fortran mixed-language project. This object file is generated
> > from a C source file, but it's not written by me - build system nor
> > source code. It's compiled by MSVC from visual studio 2013. Is this
> > object file (.obj) compatible for linking with Visual Studio
> > 2010/2012/2015 compiled code? What if I create a static library
> > (.lib) containing this single object file?
> > 
> > What I've got in mind is checking the object file into git and
> > linking it in with the rest of the project which is compiled from
> > source every time. Colleagues might use other versions of MSVC/Visual
> > Studio, though, so that's something I need to understand.
> > 
> > I'd appreciate any pointers to documentation that explains this in
> > more detail.
> 
> A related discussion:
> https://programmers.stackexchange.com/questions/235706/are-c-object-files-created-with-different-compilers-binary-compatible
> 
> Regards.

I did read that, but thanks!

Paul

[toc] | [prev] | [next] | [standalone]

#73818

paul.anton.letnes@gmail.com wrote:

(snip disclaimer)

> I've got an object file that is difficult to recreate from source 
> in my C/Fortran mixed-language project. This object file is 
> generated from a C source file, but it's not written by me - 
> build system nor source code. 

Since this is comp.lang.c, and I don't know the actual details,
this answer will be a little bit generic.

When doing mixed language programming in general, there are a few
things you have to watch.

First, the data types have to match. Newer Fortran versions have
the C interoprability feature, which means each compiler has a
matching C compiler where the data types match.

Also, the calling sequence has to match. That is, the way arguments
are passed, and related details.  In the case of the 8086 and
decendants there used to be two calling methods called STDCALL
and CDECL. 

STDCALL was commonly used with Pascal and Fortran, which don't have
calls with a variable number of arguments. The 8086 has a RET n
instruction which before returning pops some bytes of the stack.
This works if you know exactly how many bytes of arguments are
on the stack.

For C, CDECL was commonly used, where the caller pops the arguments.

More recently, there have been many more argument passing conventions,
including ones that keep some in registers, instead of the stack.

In any case, they have to match between caller and callee.

Past that, you get into fine details. Fortran CHARACTER variables
normally pass a length, but there are different ways of doing that.
C uses call by value, so in most cases you need to expect a pointer
in the C program.

And if it isn't obvious enough, there are 16, 32, and 64 bit
conventions, which you have to match.

If you have the right C compiler, even without the original source,
you can test calls between the two. Or you can just look up the
documentation for the calling conventions of both compilers.

-- glen

[toc] | [prev] | [next] | [standalone]

#73827

On Monday, October 26, 2015 at 4:14:46 AM UTC+1, glen herrmannsfeldt wrote:
> paul.anton.letnes@.com wrote:
> 
> (snip disclaimer)
> 
> > I've got an object file that is difficult to recreate from source 
> > in my C/Fortran mixed-language project. This object file is 
> > generated from a C source file, but it's not written by me - 
> > build system nor source code. 
> 
> Since this is comp.lang.c, and I don't know the actual details,
> this answer will be a little bit generic.
> 
> When doing mixed language programming in general, there are a few
> things you have to watch.
> 
> First, the data types have to match. Newer Fortran versions have
> the C interoprability feature, which means each compiler has a
> matching C compiler where the data types match.
> 
> Also, the calling sequence has to match. That is, the way arguments
> are passed, and related details.  In the case of the 8086 and
> decendants there used to be two calling methods called STDCALL
> and CDECL. 
> 
> STDCALL was commonly used with Pascal and Fortran, which don't have
> calls with a variable number of arguments. The 8086 has a RET n
> instruction which before returning pops some bytes of the stack.
> This works if you know exactly how many bytes of arguments are
> on the stack.
> 
> For C, CDECL was commonly used, where the caller pops the arguments.
> 
> More recently, there have been many more argument passing conventions,
> including ones that keep some in registers, instead of the stack.
> 
> In any case, they have to match between caller and callee.
> 
> Past that, you get into fine details. Fortran CHARACTER variables
> normally pass a length, but there are different ways of doing that.
> C uses call by value, so in most cases you need to expect a pointer
> in the C program.
> 
> And if it isn't obvious enough, there are 16, 32, and 64 bit
> conventions, which you have to match.
> 
> If you have the right C compiler, even without the original source,
> you can test calls between the two. Or you can just look up the
> documentation for the calling conventions of both compilers.
> 
> -- glen

Glen,

thanks for your advice. The C/Fortran interop question is, as far as I know, not relevant here - the reason being that the object file in question is called by other C libraries before those are again called by Fortran. Not saying that the code in question doesn't have issues in that interface, but it shouldn't be relevant for the current discussion.

For more details: My question is limited to compatibility between different versions of MSVC, no other compilers. And can anyone comment on whether I'd be in a better state with a static library? I suppose those are better for compatibility across compiler versions than raw object files?

Cheers
Paul

[toc] | [prev] | [next] | [standalone]

#73854

On Mon, 2015-10-26, paul.anton.letnes@gmail.com wrote:
...
>> paul.anton.letnes@.com wrote:
>> 
>> (snip disclaimer)
>> 
>> > I've got an object file that is difficult to recreate from source 
>> > in my C/Fortran mixed-language project. This object file is 
>> > generated from a C source file, but it's not written by me - 
>> > build system nor source code. 
...
> For more details: My question is limited to compatibility between
> different versions of MSVC, no other compilers. And can anyone
> comment on whether I'd be in a better state with a static library? I
> suppose those are better for compatibility across compiler versions
> than raw object files?

My experience is with Unix (and AmigaDOS) only, but a static library
tends to be just a container for 1--more object files. Nicer to handle
than a dozen object files, but they don't really help with /your/
problem.

IME (again, on Unix) a compiler's object code tends to be pretty
stable.  You don't want every little compiler flag to create
incompatabilities.  I don't /think/ you'll run into too many problems.
So things like struct layout and function calling conventions tend to
stay the same for a long time.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#73830

On Sunday, October 25, 2015 at 9:12:08 PM UTC, paul.ant...@gmail.com wrote:
> Hi!
> 
> Disclaimer: I've programmed very little pure C in my life, and don't consider myself a C programmer. You probably don't, either.
> 
> I've got an object file that is difficult to recreate from source in my C/Fortran mixed-language 
> project. This object file is generated from a C source file, but it's not written by me - build 
> system nor source code. It's compiled by MSVC from visual studio 2013. Is this object file
>  (.obj) compatible for linking with Visual Studio 2010/2012/2015 compiled code? What if 
> I create a static library (.lib) containing this single object file?
> 
Microsoft are pretty good on binary backwards compatibility.

You've got more chance with the lib. An obj file is a an intermediate that the compiler produces
for the linker, and it's understandable that this might break between versions. MS would be more reluctant to break a lib.
However we're currently transitioning from 32 bit to 64 bit systems, from single threaded
environments to multi-threaded, and from inherently insecure raw machine code to more
managed code. You can't always retain binary compatibility under such circumstances. You
might, for example, need to require your users to set their compilers to the appropriate mode.
if that's not acceptable for other reasons, the system might fail.

[toc] | [prev] | [next] | [standalone]

#73873

On Mon, 2015-10-26, Malcolm McLean wrote:
> On Sunday, October 25, 2015 at 9:12:08 PM UTC, paul.ant...@gmail.com wrote:
>> Hi!
>> 
>> Disclaimer: I've programmed very little pure C in my life, and don't consider myself a C programmer. You probably don't, either.
>> 
>> I've got an object file that is difficult to recreate from source
>> in my C/Fortran mixed-language project. This object file is
>> generated from a C source file, but it's not written by me - build
>> system nor source code. It's compiled by MSVC from visual studio
>> 2013. Is this object file (.obj) compatible for linking with Visual
>> Studio 2010/2012/2015 compiled code? What if I create a static
>> library (.lib) containing this single object file?
>> 
> Microsoft are pretty good on binary backwards compatibility.

That matches what I've heard.

> You've got more chance with the lib. An obj file is a an
> intermediate that the compiler produces for the linker, and it's
> understandable that this might break between versions. MS would be
> more reluctant to break a lib.

I think you're wrong here ... note that he's talking about static
libraries, and I'm /fairly/ sure they are the same in the Wonderful
World of Microsoft as everywhere else: just a collection of object
files, possibly with an index to speed up linking.

With shared (dynamic) libraries, there's much more magic involved.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#73858

On Sunday, October 25, 2015 at 5:12:08 PM UTC-4, paul.ant...@gmail.com wrote:
> Hi!
> 
> Disclaimer: I've programmed very little pure C in my life, and don't
> consider myself a C programmer. You probably don't, either.

What an odd thing to say to members of a comp.lang.c group.  While
there probably aren't many of us who routinely write only in C code
for our professional lives, most of us do write a lot of C code in
our professional lives.  It's why we're here.

> I've got an object file that is difficult to recreate from source in my C/Fortran mixed-language project. This object file is generated from a C source file, but it's not written by me - build system nor source code. It's compiled by MSVC from visual studio 2013. Is this object file (.obj) compatible for linking with Visual Studio 2010/2012/2015 compiled code? What if I create a static library (.lib) containing this single object file?

It's probably quicker to try it than to post here asking for help.
Microsoft is always changing things between versions, so worst case
you'd probably need a VS 2013 or later linker to link it.  However,
those are free to obtain through their Visual Studio Express versions.

> What I've got in mind is checking the object file into git and linking it in with the rest of the project which is compiled from source every time. Colleagues might use other versions of MSVC/Visual Studio, though, so that's something I need to understand.

Try it.  The VS2010 and other linker form will tell you if there are
errors.  If there are no errors reported, then run the program.  If
it works then you have your answer.

I typically use .obj files generated from GCC alongside VS2008 and later.
They work without issue, but I have to specify a compatible output form
to get it to work.  But, GCC allows for compound literal constants in a
particular way that MSVC does not, and I need that in one of my projects.

> I'd appreciate any pointers to documentation that explains this in more detail.

Just try it.  Worst case it will fail.  Best case you'll have your
answer.  And it's likely you could've already had your answer if you'd
tried it before posting this question.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web