Re: [xslt] [PATCH] Updated cygwin support patch

["Robert Collins" <robert collins itdomain com au>]

===
----- Original Message -----
> From: "Igor Zlatkovic" <izlatkovic@daenet.de>
> To: <xslt@gnome.org>
> Sent: Thursday, January 17, 2002 7:31 PM
> Subject: RE: [xslt] [PATCH] Updated cygwin support patch
>

> Hi there.
>
> About this:
>
>   -void exsltCommonRegister (void);
>   +void LIBEXSLT_PUBLIC exsltCommonRegister (void);
>
> This LIBEXSLT_PUBLIC macro is not needed in a function prototype, only
in a public
> variable declaration.

Cygwin doesn't compile with .def files, so it needs the declaration for
function prototypes. For functions, if it's not supplied, then very
recent binutils _can_ link without it. This involves a minor violation
of the PE spec, so I try to avoid it.

As an interesting side note, MSVC's behaviour (for functions only) is
quite interesting:
If there is no .def in the compilation, and
The headers are not decorated with __declspec()
then the generated code is for a normal function call, not a dll
imported call.
At link time, the linker inserts a stub function, which makes a long jmp
to the address from the IAT in the .dll. This is not very efficient
(think trashing your CPU cache). (There is a MSDN article/technote on
this IIRC). Also, using the declspec (dllimport) should result in the
use of import thunks, rather than per caller fixups, which is again more
efficient.

> Are you sure Cygwin needs it? If not, then please, please, remove it.
Having this
> does no harm, but it encourages others to lead endless discussions
about putting more
> in a function prototype, such as the calling convention.

I.e. FASTCALL. Well the compiler needs enough information about the
calling convention in the calling code to maintain register maps and
emit pre/post code. I've no particular feeling about where this should
go, but with gcc we have no option: Its the prototype or not at all.

> Are you really sure that Cygwin needs this __declspec(*) stuff? I was
convinced its GCC
> can make functional shared and static libraries in the Unix fashion,
without needing MS
> proprietary declaration specificators. Give me some light there.

Sorry to disappoint you, the Cygwin gcc+binutils is still a Win32 PE
target. It's limited by the platform. (Even though some rather elegant
hacks have made it considerably more unix-like).

It doesn't support unresolved symbols.
In the general case it requires declspec for dll imports and exports.

The libtool support to do all the dll importing and exporting works, but
is incomplete. The missing part is handling complex types (i.e. exported
pointers, structs and larger than 32bit ints, and floats). The presence
of any one of these will cause the link to fail.

However, we _can_ remove it from the function prototypes and have
current binutils auto-resolve it. It does involve that PE specification
violation I mentioned, but it will work. (It won't remove the need
for -DLIBEXSLT_STATIC though).

Rob