On Wed, May 13, 2009 at 02:32:13AM +0200, "[email protected]" <[email protected]> wrote:
>> to follow it, so it makes sense to ship pyev with a matching libev
>> version (of course there's always a better approach, but I'll stick
>> with the easiest for the time being).
>
> For libev, might be usefull to provide a way to determine the version &
> features of the library,
The API/ABI version is exported both in the header file and at runtime.
> create ev.h from ev.h.in and set version number & lfs flags.
How do you ensure then that the (then hardcoded) version number reflects
the actual version number?
The version number cannot be hardcoded in the header file, only in the
library itself. The header contains the API version number only.
Also, creating ev.h.in from ev.h is out of the question (for libev), as
that would make it very hard to embed libev. The gain is already small
(afaics, only gnu/linux insists on 32 bit interfaces to be the default).
> Usually the soname version string can be used to let glibc automatically
> determine the compatibility of linked libraries.
Another reason why hardcoding the version number in the header is a big
no-no.
> I'm not sure if libev uses soname correctly though.
Not sure what "correct" usage is supposed to be (there are many competing
models, and I doubt there exists such a thing as "correct" usage of soname
- glib uses a different scheme than traditional gnu/linux libs etc.), but
the versioning is documented.
> But for LFS, python uses lfs if sizeof(off_t) > sizeof(long) &&
> exists(long long).
The problem is that a) sizeof cannot be checked at compiletime and b)
libev cannot force compilation flags (which it would have to do to get the
"right" struct stat).
pyev can, of course, but it has to actually compile it for that to work.
> If there was a way to determine whether libev was build with lfs support
> (as mentioned before) , one could simply ifdef the stat bindings.
Unfortunately, there is no portable way to do that. Even if, there is no
portable way to guess the actual name of the struct stat to use.
The problem here is not geting LFS into some compiled version of libev - the
problem is that libev cannot enforce a non-default ABI on every user of the
library.
The header file would have to provide a struct stat that is capable of 64
bits, even when the app is not using LFS.
One way to do that would be to roll our own struct stat, for that, we would
only need a 64 bit type in the header file, which also cannot be done easily.
(However, I am thinking of just using long long and __int64 or so, that
might actually be portable enough, although long long isn't available in
some c++ compilers, which is troubling me).
> I guess this _feature_ only works when using the same libev version for
> python as for the application, if struct layouts change.
The major version number should change on incompatible layout changes,
which means that for shared libraries, the module couldn't load, and for
static librraies, any rutime check that is done would fail.
--
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
