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

["Igor Zlatkovic" <izlatkovic daenet de>]

> 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.

Okay.

> As an interesting side note, MSVC's behaviour (for functions only) is
> quite interesting:

MS C compiler has an interresting behaviour in regard to a lot more than just functions :-)

> 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.

Sad, but true.

> 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.

Tears flow down my cheeks. Additionally, at least when Using MS compiler, if you have no .def file and don't mark your functions as exportable by using __declspec(), they are not exported. No fixup possible, you simply cannot call any of those functions from the client code in that case.

> 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).

Okay.

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

Okay.

> 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.

Okay. Now I begin to apperciate my decision not to use Cygwin :-) I have installed and checked that thing about a year and a half ago. Back then, I removed it again and decided to install real Unix (Linux). I did and I liked it, so I installed another Unix (Solaris). Now, my needs would be covered by the two, but the less I use Windows, the more anger I cash from my boss and he makes a hell of a coffee when he is angry :-)

> 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).

Does that mean that the best for Cygwin would be to have LIBXXX_PUBLIC decorating every public function prototype, throughout the library? In all three libraries? I have nothing against this, I am used to it, all of my portable code here has such prototypes. However, I think that Unix developers would not exactly welcome this, and they are a great majority around libxml.

Ciao
Igor