Binding Libev with Digitalmars' D on windows

Marc Lehmann schmorp at schmorp.de
Wed Jun 18 13:24:14 CEST 2008


On Wed, Jun 18, 2008 at 10:44:15AM +0200, Malek Hadj-Ali <malek at lcde.net> 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
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list