29 Aug
2004
29 Aug
'04
7:15 p.m.
Shachar Shemesh <wine-patches(a)shemesh.biz> writes:
After much talk, the patch seems ready for commit.
Since there are many
systems with slightly older glibc that have the header but do not have
the implementation in glibc, or that have a stub implementation that is
guaranteed to fail, we are calling the kernel functions directly. This
also allows compiling on older systems than the code actually ships to.
Accordingly, the autoconf checks for epoll_create in glibc were dropped.
That's wrong; if the libc function exists you should use it, direct
system calls should only be used as a fallback. And when using system
calls you must not depend on the libc header, you have to define the
structures yourself.
--
Alexandre Julliard
julliard(a)winehq.org
30 Aug
30 Aug
6:23 a.m.
New subject: wineserver epoll
Alexandre Julliard wrote:
Shachar Shemesh <wine-patches(a)shemesh.biz>
writes:
The problem is that on many platforms, the functions are defined in
glibc, but stubbed out to always fail. It seems a waste to lose these
platforms.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
After much talk, the patch seems ready for commit.
Since there are many
systems with slightly older glibc that have the header but do not have
the implementation in glibc, or that have a stub implementation that is
guaranteed to fail, we are calling the kernel functions directly. This
also allows compiling on older systems than the code actually ships to.
Accordingly, the autoconf checks for epoll_create in glibc were dropped.
That's wrong; if the libc function exists you should use it, direct
system calls should only be used as a fallback. And when using system
calls you must not depend on the libc header, you have to define the
structures yourself.
12:55 p.m.
New subject: wineserver epoll
Alexandre Julliard wrote:
Shachar Shemesh <wine-patches(a)shemesh.biz>
writes:
But what to do if the library functions exist during compilation, and do
not during runtime? Merely linking with them will cause wineserver not
to load, claiming that it requires "GLIBC version 3.2.3". Some wine uses
(crossover office being one of them) require you to compile once and run
almost everywhere, which run counter to this behavior.
After much talk, the patch seems ready for commit.
Since there are many
systems with slightly older glibc that have the header but do not have
the implementation in glibc, or that have a stub implementation that is
guaranteed to fail, we are calling the kernel functions directly. This
also allows compiling on older systems than the code actually ships to.
Accordingly, the autoconf checks for epoll_create in glibc were dropped.
That's wrong; if the libc function exists you should use it, direct
system calls should only be used as a fallback.
And when using system
calls you must not depend on the libc header, you have to define the
structures yourself.
Just yank the definitions from the header? I can do that, the license is
compatible. However, I think it's pointless. Most systems will have that
header, and for those who don't, we will have a fallback. What's wrong
with using the header if it's there?
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
3:24 p.m.
New subject: wineserver epoll
Shachar Shemesh <wine-devel(a)shemesh.biz> writes:
But what to do if the library functions exist during
compilation, and
do not during runtime? Merely linking with them will cause wineserver
not to load, claiming that it requires "GLIBC version 3.2.3". Some
wine uses (crossover office being one of them) require you to compile
once and run almost everywhere, which run counter to this behavior.
Building with a recent glibc and running on an older one is not
supported by glibc, and it won't work for many reasons having nothing
to do with epoll. Crossover runs everywhere because it is built
against a very old glibc.
Just yank the definitions from the header? I can do
that, the license
is compatible. However, I think it's pointless. Most systems will have
that header, and for those who don't, we will have a fallback. What's
wrong with using the header if it's there?
The libc definitions must be used with the libc function, and the
kernel definitions with the system call. There is no guarantee at all
that they will remain identical (check the 64-bit file support for an
example of how that can happen).
--
Alexandre Julliard
julliard(a)winehq.org
31 Aug
31 Aug
8:14 a.m.
New subject: wineserver epoll
Building with a recent glibc and running on an older
one is not
supported by glibc, and it won't work for many reasons having nothing
to do with epoll. Crossover runs everywhere because it is built
against a very old glibc.
To clarify, it is possible to build against a new glibc and have it run
on older libcs, but the process is far from intuitive and requires
special tools, header overrides etc. We do this in autopackage, and it
works, but it's quite tricky to get right.
So I guess Shachar could use dlopen, or possibly the epoll functions are
weak symbols - quite a lot of glibc functions are these days. In that
case you can just mark them with the weak attribute and that's no problem.
8:48 a.m.
New subject: wineserver epoll
Mike Hearn wrote:
Details, please. How do I do that?
Shachar
Building with
a recent glibc and running on an older one is not
supported by glibc, and it won't work for many reasons having nothing
to do with epoll. Crossover runs everywhere because it is built
against a very old glibc.
To clarify, it is possible to build against a new glibc and have it
run on older libcs, but the process is far from intuitive and requires
special tools, header overrides etc. We do this in autopackage, and it
works, but it's quite tricky to get right.
So I guess Shachar could use dlopen, or possibly the epoll functions
are weak symbols - quite a lot of glibc functions are these days. In
that case you can just mark them with the weak attribute and that's no
problem.
9:19 a.m.
New subject: wineserver epoll
Details, please. How do I do that?
readelf -aW /lib/libc.so.6 | grep epoll
if the symbols are declared WEAK then you can do this (assuming AJ agrees).
#pragma weak epoll_whatever
should do the trick.
In the resulting binary "readelf -aW mybinary | grep epoll" should
should you the weak linkage. At runtime:
if (epoll_foobar)
{
... it's safe to use
}
11:12 a.m.
New subject: wineserver epoll
On Tue, Aug 31, 2004 at 11:48:16AM +0300, Shachar Shemesh wrote:
Mike Hearn wrote:
Details, please. How do I do that?
Guys, pretty pretty please, just use the glibc function, add a regular
configure check and use it if it does not return -ENOSYS.
All this confusing handling of dlopening etc etc is way overblown.
Ciao, Marcus
Building
with a recent glibc and running on an older one is not
supported by glibc, and it won't work for many reasons having nothing
to do with epoll. Crossover runs everywhere because it is built
against a very old glibc.
To clarify, it is possible to build against a new glibc and have it
run on older libcs, but the process is far from intuitive and requires
special tools, header overrides etc. We do this in autopackage, and it
works, but it's quite tricky to get right.
So I guess Shachar could use dlopen, or possibly the epoll functions
are weak symbols - quite a lot of glibc functions are these days. In
that case you can just mark them with the weak attribute and that's no
problem.
7201
days inactive
7203
days old
7 comments
5 participants
participants (5)
-
Alexandre Julliard -
Marcus Meissner -
Mike Hearn -
Shachar Shemesh -
Shachar Shemesh