slight trouble running winetests under windows
I'm trying to get some of the wine tests compiling and running under windows, oleaut32 test specifically. I've got the project file built and everything opens fine under visual studio 6. The only issue is that during linking of the oleaut32 tests _IID_IFont is undefined. Oddly enough if I switch from a non-mfc project to a mfc project, compile, run into errors and then switch back to a non-mfc project things work fine, no more symbol errors about IID_IFont. I even tried cleaning things out and removing the output directory entirely and the test still compiles once the non-mfc->mfc->non-mfc change has been performed. I can't seem to see what difference going into mfc and back should have on the project, it seems like we are missing something from our .dsp project or something. I can't seem to identify changes in the .dsp or .dsw files either... Has anyone else seen this? Thanks, Chris
On Tuesday 13 January 2004 05:47, Chris Morgan wrote:
I'm trying to get some of the wine tests compiling and running under windows, oleaut32 test specifically. I've got the project file built and everything opens fine under visual studio 6. The only issue is that during linking of the oleaut32 tests _IID_IFont is undefined. Oddly enough if I
I get these linking errors too when compiling with MinGW. I solve these by manually adding -luuid. The dsound test needs -luuid and -ldxguid to link. There has been some discussion in the past as to how to solve this. I proposed a number of changes to Wine's build system to fix this but they were rejected. Let's see if I can sum up the issues. In Wine uuids are put in a lib called libwine_uuid. It's called like that because a libuuid already exists. Second thing is that in MinGW and MSVC there are two separate libraries with uuids, uuid and dxguid, whereas in Wine they're all in one. -Hans
On Tue, 13 Jan 2004, Hans Leidekker wrote: [...]
Let's see if I can sum up the issues. In Wine uuids are put in a lib called libwine_uuid. It's called like that because a libuuid already exists. Second thing is that in MinGW and MSVC there are two separate libraries with uuids, uuid and dxguid, whereas in Wine they're all in one.
I think we should split the GUIDS into two libraries in Wine: libwine_uuid and libwine_dxguid, though it probably would not help with this particular problem. However this should let msvcmaker generate the right set of import libraries (currently it hard-codes the list of .lib files to link to, including uuid.lib but not dxguid.lib). For MinGW it would be harder though. This is using the crosstest target in the regular makefiles, right? Maybe a `echo $LIBS | sed s/libwine_/lib/` ? What was your proposal already? Do you know why it was rejected? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"
On Tue, 13 Jan 2004, Francois Gouget wrote:
this particular problem. However this should let msvcmaker generate the right set of import libraries (currently it hard-codes the list of .lib files to link to, including uuid.lib but not dxguid.lib).
For MinGW it would be harder though. This is using the crosstest target in the regular makefiles, right? Maybe a `echo $LIBS | sed s/libwine_/lib/` ?
The way it should work is the following: -- winemaker generates MinGW compatible Makefiles. In it, it uses -luuid and -ldxguid to link to these things. -- on MinGW, this will work just fine -- under Wine, winegcc will translate this into -lwine_uuid and -lwine_dxguid respectively. It already does so for -luuid, we just need to do it for dxguid as well. -- Dimi.
On Tue, 13 Jan 2004, Dimitrie O. Paun wrote:
On Tue, 13 Jan 2004, Francois Gouget wrote:
this particular problem. However this should let msvcmaker generate the right set of import libraries (currently it hard-codes the list of .lib files to link to, including uuid.lib but not dxguid.lib).
For MinGW it would be harder though. This is using the crosstest target in the regular makefiles, right? Maybe a `echo $LIBS | sed s/libwine_/lib/` ?
The way it should work is the following: -- winemaker generates MinGW compatible Makefiles. In it, it uses -luuid and -ldxguid to link to these things.
That's a completely separate issue. winemaker is not involved for compiling the Wine conformance tests with MinGW. I don't think there's any reason to involve it either. As far as converting Windows projects to Winelib/MinGW projects, winemaker would have nothing special to do for uuid and dxguid (though since winegcc is not usable yet, for now it should prefix them with 'wine_'). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.
"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes:
The way it should work is the following: -- winemaker generates MinGW compatible Makefiles. In it, it uses -luuid and -ldxguid to link to these things. -- on MinGW, this will work just fine -- under Wine, winegcc will translate this into -lwine_uuid and -lwine_dxguid respectively. It already does so for -luuid, we just need to do it for dxguid as well.
The current problem is that Wine itself is not built with winegcc so this doesn't help. A possibility could be to rename the library to libuuid but install it in /usr/lib/wine to avoid conflicts. This will require winegcc and winemaker to set the correct library path, but they already have to do that for import libs anyway. -- Alexandre Julliard julliard(a)winehq.com
On Tue, 13 Jan 2004, Alexandre Julliard wrote:
The current problem is that Wine itself is not built with winegcc so this doesn't help.
Right. For some reason I've read winetest and understook winemaker :) Sorry for the confusion. But we could build the tests with winegcc right now, no? And programs/* as well. We can't deal with DLLs in winegcc, I'm a lazy bum, I admit :/
A possibility could be to rename the library to libuuid but install it in /usr/lib/wine to avoid conflicts. This will require winegcc and winemaker to set the correct library path, but they already have to do that for import libs anyway.
Yes, we can do that, but it introduces a _little_ inconsistency. Even though you could argue it's not a big deal since this is a static lib, so ld is not concerned with it. Anyway is good. -- Dimi.
"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes:
Right. For some reason I've read winetest and understook winemaker :) Sorry for the confusion. But we could build the tests with winegcc right now, no? And programs/* as well. We can't deal with DLLs in winegcc, I'm a lazy bum, I admit :/
The main problem is that winegcc only knows about gcc, and we want Wine to build with other compilers too. So no, we can't use it yet. -- Alexandre Julliard julliard(a)winehq.com
On January 13, 2004 08:06 pm, Alexandre Julliard wrote:
The main problem is that winegcc only knows about gcc, and we want Wine to build with other compilers too. So no, we can't use it yet.
Good point. Situation is not too bad though. Wine source is not gcc specific, so we can invoke whatever compiler ./configure detected. It's true, we're currently passing -fshort-wchar and -fPIC which are gcc specific, but we cat easily test for these things in ./configure, and add them only if the compiler supports them. To summarize, here are the gcc-specific dependencies that I see: winegcc -fshort-wchar -fPIC winewrap -Wl,-Bsymbolic,-z,defs,-init,__wine_spec_init,-fini,__wine_spec_fini -shared -fPIC It is easy to just use what ./configure figures out instead. I know, if we do that winegcc will be forced to use the same compiler that was used to build Wine. It's a bummer, but also kinda theoretical problem for now, as all binaries are build with gcc. I think we can worry about this issue when it does become a real problem. -- Dimi.
On Tue, 13 Jan 2004 11:33:25 -0800, Alexandre Julliard wrote:
The current problem is that Wine itself is not built with winegcc so this doesn't help. A possibility could be to rename the library to libuuid but install it in /usr/lib/wine to avoid conflicts. This will require winegcc and winemaker to set the correct library path, but they already have to do that for import libs anyway.
Would having two DSOs with the same SONAME that are actually different break prelink in any way?
Mike Hearn <mike(a)theoretic.com> writes:
On Tue, 13 Jan 2004 11:33:25 -0800, Alexandre Julliard wrote:
The current problem is that Wine itself is not built with winegcc so this doesn't help. A possibility could be to rename the library to libuuid but install it in /usr/lib/wine to avoid conflicts. This will require winegcc and winemaker to set the correct library path, but they already have to do that for import libs anyway.
Would having two DSOs with the same SONAME that are actually different break prelink in any way?
libuuid is a static lib not a DSO. -- Alexandre Julliard julliard(a)winehq.com
On Tuesday 13 January 2004 20:33, Alexandre Julliard wrote:
this doesn't help. A possibility could be to rename the library to libuuid but install it in /usr/lib/wine to avoid conflicts. This will require winegcc and winemaker to set the correct library path, but they already have to do that for import libs anyway.
Looks like a solution to me. What about dxguid? Should we split uuid up by creating a seperate directory with Makefile etc. or will a symlink to libuuid do? -Hans
Hans Leidekker <hans(a)it.vu.nl> writes:
Looks like a solution to me. What about dxguid? Should we split uuid up by creating a seperate directory with Makefile etc. or will a symlink to libuuid do?
I think we should create a separate library. I'm also wondering if we shouldn't move them to dlls/, these are more like import libs than normal Unix libs. -- Alexandre Julliard julliard(a)winehq.com
On Wednesday 14 January 2004 22:52, Alexandre Julliard wrote:
Looks like a solution to me. What about dxguid? Should we split uuid up by creating a seperate directory with Makefile etc. or will a symlink to libuuid do?
I think we should create a separate library. I'm also wondering if we shouldn't move them to dlls/, these are more like import libs than normal Unix libs.
I explored that possibility some time ago. Moving to dlls/ implies using a spec file, because I don't think we want to use anything other than a standard Makefile under dlls/, right? This puzzled me since uuids are not functions and although spec syntax allows specification of data entry points ('extern'), winebuild doesn't support importing them. Using the standard Makefile will also give us a DSO which we don't need. -Hans
Hans Leidekker <hans(a)it.vu.nl> writes:
I explored that possibility some time ago. Moving to dlls/ implies using a spec file, because I don't think we want to use anything other than a standard Makefile under dlls/, right? This puzzled me since uuids are not functions and although spec syntax allows specification of data entry points ('extern'), winebuild doesn't support importing them. Using the standard Makefile will also give us a DSO which we don't need.
No, we wouldn't want to use a standard Makefile (note that we are not using one now in libs/ either, a static lib is special either way), so there's a bit of work involved to make this work right. I'll try to find the time to do it. -- Alexandre Julliard julliard(a)winehq.com
participants (7)
-
Alexandre Julliard -
Chris Morgan -
Dimitrie O. Paun -
Dimitrie O. Paun -
Francois Gouget -
Hans Leidekker -
Mike Hearn