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
