Mail Archives: cygwin/2002/07/03/14:03:34
Nicholas Wourms wrote:
> --- Charles Wilson <cwilson AT ece DOT gatech DOT edu> wrote:
> [SNIP]
>
>>However, the correct answer is NOT, IMO, to willy-nilly export
>>everything in libc/libm from cygwin1.dll -- even if dll size were not an
>>issue.
>>
>
> Why? Can you please explain your reasoning? Other then the fact that
> conflicts might occur, in which case we should cull out conflicting
> function symbols. But as to additional, non-conflicting functionality,
> why be so resistant?
1) because they might not work on cygwin. The need testing *on our
platform* BEFORE they are exported from the DLL.
2) deep conflicts: a new function might not itself conflict with
something on the cygwin platform, but it might REQUIRE another function
or feature in newlib that DOES conflict with a cygwin implementation.
Here's one: suppose that somebody added a null "/proc" interface handler
to newlib (in the stdio routines?), so that programs which expect /proc
could work -- even on a non-glibc linux kernel that was compiled without
/proc support (common on embedded platforms).
This would conflict with cygwin's /proc implementation...
3) When I say "willy nilly" that's what I mean. We should NOT
automatically export everything the newlib people add. Rather, the
default stance should be "we will add the export and '#define in' the
declarations at user request or developer need" -- but by default, new
additions in newlib are left OUT of the cygwin headers and cygwin1.dll.
The problem here is that functions are added to newlib (and not to
cygwin1.dll) -- but the newlib headers ASSUME that the functions are
always available. E.g. mismatch.
I've nothing against adding new stuff -- I just think it should be OUR
decision, not newlib's -- and it should be done ACTIVELY with TESTING,
and not by ACCIDENT.
4) As Chris pointed out, backwards compatibility. Look at the problems
you had with the shm exports and db. Every time a new symbol is
exported from cygwin1.dll, we raise the possibility that the the new
"foo" package will ONLY work with the new cygwin1.dll, and can't work
with the old cygiwn1.dll -- even if the OLD 'foo' package worked
perfectly well with the old cygwin1.dll, and the new 'foo' package
does't REALLY use the new exports from the new cygwin1.dll
e.g. we break backwards compatibility for NO good reason. Unless we
really REALLY need the new symbols in cygwin1.dll for some other reason.
E.g. we should make an informed decision, aware of the consequences --
not blindly or willy-nilly adding new symbols.
5) Another backwards compatibilty point: once a new symbol is added to
cygwin1.dll it can NEVER be removed. If it was a mistake, too bad. If
we remove the 'bad' symbol later, then we break EVERY compiled
application -- we'd have to bump the cygwin1.dll DLLNUM to '2' :
cygwin2.dll -- and we REALLY don't want to do that just because we made
a MISTAKE in adding a new symbol.
Adding symbols is a BIG deal -- not to be done cavalierly.
>>Unfortunately, I don't know what the "correct" answer is, short
>>of a "cleanup squad" that provides the newlib people with the
>>appropriate #ifndef __CYGWIN__ patches -- since the newlib folks are no
>>longer being very careful about that issue on their own.
>>
>>
>
> Or maybe it should be the case that we try to stay more in sync with their
> additions, deciding at the time they are added if they should be exported.
> If not, then gaurd against the detection.
Yeah -- and in the past, it seemed that newly added newlib symbols WERE
guarded against accidental detection in the headers (#ifndef __CYGWIN__)
and of course, we have to take active steps to export them (add to
cygwin.din)
So, newly added symbols (in newlib) didn't cause breakage -- and once in
a while, folks would pop up and say "hey, newlib has this new function
and we should export it from the DLL" -- and lo, it would be added to
cygwin.din and the header guards removed. Yippee.
That's the way it should be done -- but it requires manpower.
> Again, other then the potential for conflicts (which can be delt with),
> what is your reasoning? I put forth the stance that we should flesh out
> the cygwin dll, let's use the tools that are at our disposal. Either
> that, or make some sort of separate thing which would allow us access to
> these functions.
Covered above.
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -