On Wed, Jun 18, 2008 at 10:44:15AM +0200, Malek Hadj-Ali <[EMAIL PROTECTED]>
wrote:
> I'm afraid I don't really understand why the suggested change would
> break the ABI.
the change would *change* the existing ABI, obviously, because the struct
stat would change inside libev, but not the caller. changing the ABI
breaks programs who don't know that they need non-standard configuration
options.
I have thought about some possible workarounds for this, but nothing really
seems nice enough:
- provide compile flags to other environments (e.g. using pkgconfig).
* this doesn't work when you combine multiple packages that might disagree
i think the right fix would be for os distributions to select 64 bit file
api's as the default compilation environment. having to add hacks to each
and every program doesn't work well.
- autodetect the availability of 64 bit structs regardless of the environment
(e..g use struct stat64).
* i found this to be very hard, as the existance of struct stat64 doesn't
seem to be detectable easily as it isn't standardised.
- provide our own struct stat
I would favour this most, as it would allow me to use ev_tstamp for file
times.
* problem is, i'd need a 64 bit type in the header file, something that
isn't easily detectable as well.
- use #ifdef __linux and outright assume struct stat64 etc. exists
hey, this would probably silence most/all complaints.
* it's kind of cheating.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
