Mail Archives: cygwin/2008/08/08/02:27:06
Clarification:
> .dlls *statically linked the same* CAN communicate in "all" ways.
> This is the simple world folks generally stay within.
Compiled and statically linked the same.
There are multiple factors.
There is which compiler you use. That actually tends not to matter.
Unless the headers use language extensions not supported.
Or if the compilers actually output different formats, that the linkers
did/did not understand. That is the case for the debug info presumably,
but not for the code.
Actually, there is a reason you can't always mix gcc+link or cl+ld.
That is because "__ImageBase" has a different name between the two linkers.
So if you use that symbol, your source is stuck with a particular compiler and linker.
Unfortunate. This is why, e.g. MS link can't use Cygwin libc.a or such, because
it has a use of the GNU/Cygwin symbol analogous to __ImageBase but
differently named.
There is which headers to you use. Ideally they'd be "the same".
But they aren't, and that is "the problem" (or just how things are).
The static .libs you use. With in any one invocation of the linker, you can
only use either Cygwin libc.a, or Microsoft msvcrt.lib (or libcmt.lib, ignored).
IF the headers were "the same", then you could mix .objs within the static
link that were compiled with either headers.
As well, there is what happens at runtime.
Given the varying headers, there is an analogous lack of interop there too.
Granted, though I kind of said the opposite before.
Folks can still traffic in int and such, but if they pass around FILE*,
trouble is likely. Really, it's about trafficing in types for which you
agree to the definition, for which you used the same headers.
And for opaque types, assuming sizes match (e.g. FILE*), which are
fed down to the same underlying layers.
- Jay
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -