winemaker

[Francois Gouget]

On Thu, 11 Oct 2001 lawson_whitney at 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 at free.fr        http://fgouget.free.fr/
               RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt
                IP over Avian Carriers with Quality of Service