Alexandre Julliard wrote:
Francois Gouget fgouget@free.fr writes:
I am not sure but I suspect the compiler generates indirect accesses for these. I'm not sure what gcc does for variables exported from another library. It seems like it has to be doing something similar. So if we could get access to that indirection we may be able to make things work.
Yes, it would be possible to resolve imports directly through the ELF tables and avoid our own separate import mechanism; basically this would be a PE-aware ld.so. It's quite a bit of work though, and portability is an issue. In any case it's for after 1.0 IMO.
Portability to NetBSD shouldn't be an issue, as they seem to have already implemented it :-) See http://chiharu.haun.org/peace/ http://groups.google.com/groups?selm=20020516061929.5DA943C110%40gabi-n.hauN... et seq. http://www.freebsd.org/cgi/man.cgi?query=compat_pecoff&manpath=NetBSD+1....
- Dan
Dan Kegel dank@kegel.com writes:
Alexandre Julliard wrote:
Yes, it would be possible to resolve imports directly through the ELF tables and avoid our own separate import mechanism; basically this would be a PE-aware ld.so. It's quite a bit of work though, and portability is an issue. In any case it's for after 1.0 IMO.
Portability to NetBSD shouldn't be an issue, as they seem to have already implemented it :-) See http://chiharu.haun.org/peace/
As far as I can tell, this is only a PE loader, so you need to cross-compile everything as PE dlls. What we would want for Wine is an ELF loader that can also load PE and seamlessly link binaries of both types together.
Alexandre Julliard wrote:
Dan Kegel dank@kegel.com writes:
Alexandre Julliard wrote:
Yes, it would be possible to resolve imports directly through the ELF tables and avoid our own separate import mechanism; basically this would be a PE-aware ld.so. It's quite a bit of work though, and portability is an issue. In any case it's for after 1.0 IMO.
Portability to NetBSD shouldn't be an issue, as they seem to have already implemented it :-) See http://chiharu.haun.org/peace/
As far as I can tell, this is only a PE loader, so you need to cross-compile everything as PE dlls. What we would want for Wine is an ELF loader that can also load PE and seamlessly link binaries of both types together.
Wouldn't it suffice to compile the Wine DLLs as PE? Then you wouldn't need to link binaries of different types together. - Dan
Dan Kegel dank@kegel.com writes:
Wouldn't it suffice to compile the Wine DLLs as PE? Then you wouldn't need to link binaries of different types together.
But then you wouldn't be able to use ELF libraries from Wine DLLs, which means you would need to recompile all the system libraries as PE too.
Alexandre Julliard wrote:
Dan Kegel dank@kegel.com writes:
Wouldn't it suffice to compile the Wine DLLs as PE? Then you wouldn't need to link binaries of different types together.
But then you wouldn't be able to use ELF libraries from Wine DLLs, which means you would need to recompile all the system libraries as PE too.
Oh. (Hey, that might be an advantage... then you could limit which system libraries wine programs used by just not recompiling them :-) - Dan
As far as I can tell, this is only a PE loader, so you need to cross-compile everything as PE dlls. What we would want for Wine is an ELF loader that can also load PE and seamlessly link binaries of both types together.
I've not read the URL above, but have looked at the netbsd ld.elf_so, making it do something subtly different with other object formats shouldn't be too hard - it of only boring (system) code.
You might want to make the wine binary use a non-standard ELF interpreter, the name of the program used to do all the library loading and symbol fixupnis a property of the program being run, not of the system.
Do if you need a pe_open (cf dlopen) it shouldn't be too hard to sort out.
Although the different OS will have different requirements on the ELF interpreter, it is the ELF object format that requires it.
In particular the rules for looking up symbols are easily changed.
David
-
Alexandre Julliard -
Dan Kegel -
David Laight