On Thu, 11 Oct 2001 lawson_whitney@juno.com wrote: [...]
why does it make a configure script that can find -lwine, but can not find -lntdll - ? They are both in /usr/local/lib
... checking whether we can build a Linux dll... yes checking whether we need to define __i386__... no checking for g++ -fpermissive option... yes checking for g++ -fno-for-scope option... yes checking for windef.h header... /usr/local/include/wine checking for -lwine... checking for libntdll.so... configure: error: Could not find the Wine dlls (libntdll.so)
As you see on the '-lwine' line, there is no path. This means that gcc found the wine library in one of the well-known places. When I tested this /usr/local/lib was not one of them. One had to explicitly add a -L/usr/local/lib. At that time I also checked and LD_LIBRARY_PATH and /etc/ld.so.conf had no bearing on this. When the time comes to find the ntdll library we do a file search, we don't rely on gcc's magical abilities. The reason here is that winebuild also does a file search so we must be able to tell it exactly where to find that library. Since we don't know where libwine comes from, the seed for this search is a hard-coded list of paths: /lib:/lib/dlls:/usr/lib:/usr/lib/dlls And as you can see /usr/local/lib is not part of them.
I redid the test and now gcc does automagically find libraries that are in /usr/local/lib. So I guess I should update the above list to include that too.
I am sending a patch to wine-patches to fix that (and also a bug in the tool search path that I just noticed).
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service