On 6 Jan 2005, Alexandre Julliard wrote:
I'm not sure I follow you, if your .so files have been built correctly they shouldn't contain undefined references to Windows APIs. Could you please show an example of the situation that causes a problem?
On Thu, 6 Jan 2005, Dimitrie O. Paun wrote:
Of course, there is the bigger problem of why you need these in there. In fact, in the beginning of winegcc, we used to pass them to winebuild, but we've stopped long time ago.
Hmm, okay - it seems that I am going down the wrong road.
I have a project with ca. 10 libraries with source, 2 binaery only dll, and 3-4 projects that uses all of these libraries. I have a goal of replacing/porting one of the binaery only dlls. This perticula dll is use all over the place. When replaceing one functionallity at a time from the dll, I want it to be link at one place only (otherwise some libraries would use the real dll, other my reemplentation). Therefor the libraries are just created by gcc -shared -o foo.so *.o, and the handling the symbols are first done when linking to one of the 3-4 projects. Which brings me back to the questions; at the linking time some symbols in the shared libraries might use symbols in the dll, that are not dealt with (used in the project I am compiling).
Does that make sense?
There is might be the road of building the libraries static, which winegcc seems to parse to winebuild.
Peter