http://bugs.winehq.org/show_bug.cgi?id=25377
--- Comment #17 from Emerson Prado emerson.prado.eng@gmail.com 2010-12-06 14:15:12 CST --- (In reply to comment #16)
it sounds like it's not the interface-specific bind patches since the address shown is 0.0.0.0 (INADDR_ANY)
Sorry, in fact, some of the addressess are 0.0.0.0, but there are at least other two different ones (loopback and someone from my LAN). That doesn't change throughout patches.
When you originally patched and installed (make && make install) how did you launch Wine?
~/.wine/drive_c/Arquivos de Programas/Filemaker/Filemaker Pro 11/wine Filemaker Pro.exe
if you could try going back to just the first two patches and see if that fixes it for you then that would be greatly appreciated.
I tested it unpatched, with first two patches and fully patched. Only the fully patched version could find remote servers automatically.
you can tell what terminals are using which Wine by running "which wine".
/usr/local/bin/wine
The first two versions I tried (1.0 from Debian repo and 1.1 from Lamaresh repo) were uninstalled thru apt-get remove and autoclean/autoremove. 1.2, from the RPM at Sourceforge, was removed thru Synaptic. Always uninstalling prior to installing the following major version. I also rm -(r)f everything concerning Wine I could locate.
Something interesting that I could repeat: applying the remaining patches in a source already compiled with the first two gives an error in the fourth one - one hunk from the first file fails to be patched. We can retry and choose to ignore the hunks already patched, but that ends in a fatal error during make. That is, if we already compiled from source with the two first patches applied, we have to start over from the unpatched source (expanding the tarball again).