Mail Archives: cygwin-developers/1999/01/19/19:31:06
It is becoming clear to me that we may have to break with binary
compatibility B21. Geoff's recent changes to the mount table, and my
changes to termios and sigmask lead me to believe that we should be
"going for broke" with the next release. There are also some changes
I'd like to make to the user_data structure.
I may hold off until we do an internal release here just to get one more
release that uses 'cygwin1.dll' but I think that we will soon be seeing
a 'cygwin2.dll'.
That means that it's time to vote for your favorite binary
incompatibility issues.
Geoff and I seem to vaguely recall some sort of incompatibility with
statfs or something like that. Does anyone remember what that was?
Mumit had also provided a list a while ago. Additions are welcome:
> - change all __imp__ to _imp__ ; or, better yet, use dllimport
> attribute. It actually may not break binary incompatibility, but
> then again it may. It may sound to be a waste of effort, but it's
> important for future possible compatibility with native compilers
> and tools.
I'd like to use dllimport and dllexport but for that to be feasible it
means that we'll have to still conditionalize the code for older revs of
the compiler -- at least for a few months. Is there any way to detect
if the gcc being used understands dllimport/dllexport?
> - change the DLL entry point to be something more reasonable that
> _cygwin_dll_entry! Let's use MSVC compatible names. While we're
> at it, let's add a different default entry point for GUI apps,
> which could be the same as the console one for now. In the future,
> we could then use information set in the GUI entry routine to
> for example issue error messages via windows so that they don't
> get lost.
Could someone produce a patch for this?
> - We can also now add an extra parameter to support Cygwin DLLs from
> non-Cygwin apps without having to maintain two different entry
> points. DJ's last patch had something like that, and so did one of
> my original changes that I had sent just after b20 (but not the
> final one that's in b20.1).
Is this ok, then?
> - Perhaps dump the dlltool's backward compatibility hack of producing
> __imp__ (old style) import entries. This causes the import libraries
> to be twice as large, and when you deal with import libs of 8-10M,
> it does make a difference. This is low priority of course.
If this is the default then it should certainly be made optional.
>I'm sure I'm forgetting lots of things. I do know that we should take
>the issue of breaking binary compatibility seriously and try to do as
>much now so that we don't have do this in the near future. It's a
>thankless job; just wait till the mailing list goes nuts complaining
>about everything under the sun.
Hmm. Maybe I should unsubscribe everyone from the mailing list right
after the B21 announcement... That should solve that problem.
-chris
- Raw text -