Good day!
I like winemaker, but it frustrates me.
Given a standard wine installation (from source in /oof/wine, ./configure, make depend && make, make install) and a little winelib program with a handmade .spec file in subdirectory wlp, and the command
winemaker --nosource-fix --console --nogenerated-specs \ --single-target toj2 wlp
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)
The Winelib program is responsible to bring you this letter, but I had to hand-hack some scripts to get it to compile.
Well, it may take me a while, but you or I will solve it.
Regards,
Lawson ---oof---
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
On Thu, 11 Oct 2001, Francois Gouget wrote:
I redid the test and now gcc does automagically find libraries that are in /usr/local/lib.
Or ld does, anyway. I wonder when it started doing that?
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).
Good, thanks. Now it ./configures and makes fine, but "make install" is so wrong I must have screwed something up. I will check before I run off any more about it.
-- 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
Lawson ---oof---
________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.
On Fri, 12 Oct 2001 lawson_whitney@juno.com wrote: [...]
Good, thanks. Now it ./configures and makes fine, but "make install" is so wrong I must have screwed something up. I will check before I run off any more about it.
Hmm, I never really tested "make install". It's something that was in the original makefile I started from and that I mostly kept around. Should work though. Make sure that it is not copying the symbolic links but creates real files in the $prefix/bin directory... Also, you will need a proper 'install' program. In full-fledged autoconf setups they have an install-sh script because they don't trust the system tool. I felt it was not worth the overhead in winemaker as the install procedure is very likely to need customization anyway.
Well, let me know what you find.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ $live{free} || die "";
On Fri, 12 Oct 2001, Francois Gouget wrote:
Hmm, I never really tested "make install". It's something that was in the original makefile I started from and that I mostly kept around.
How are Winelib programs meant to be installed, then? Am I missing something obvious?
Should work though. Make sure that it is not copying the symbolic links but creates real files in the $prefix/bin directory...
for i in ; do (cd $i; make install) || exit 1; done /bin/sh: -c: line 1: syntax error near unexpected token `;' /bin/sh: -c: line 1: `for i in ; do (cd $i; make install) || exit 1; done' make: *** [install] Error 2
This should not be hard to fix, I think:
install:: for i in $(SUBDIRS); do (cd $$i; $(MAKE) install) || exit 1; done for i in $(EXES); do $(INSTALL_PROGRAM) $$i $(bindir); done for i in $(EXES:%=%.so) $(DLLS); do $(INSTALL_PROGRAM) $$i $(libdir); done
Just leave out the first line if there are no SUBDIRS, no? And the same for uninstall. Now, however, make has made a symbolic link to /usr/local/bin/wine for each of EXES, which seems right, so they can be run from where they were built, so the next line makes a copy of the wine executable in the name of each executable, and we install the .so file in libdir. AFAICT, wine will be looking for it in bindir. I thought perhaps I had misled winemaker into thinking it was making a dll, but I did tell it quite clearly --console:
winemaker --nosource-fix --console --nogenerated-specs --single-target toj2 wlp
Also, you will need a proper 'install' program. In full-fledged autoconf setups they have an install-sh script because they don't trust the system tool. I felt it was not worth the overhead in winemaker as the install procedure is very likely to need customization anyway.
True. As long as ./configure works, it is not to onerous to fix a few lines of Makefile.in. Indeed, that is how I installed the version of toj2 I am sending this with. I think, though, the subdirs line could be conditional, and maybe libdir for bindir is a mistake. I don't want to make things more difficult for those who are doing truly hairy and difficult tasks with winemaker just to make everything perfectly smooth for my little app. I can't think of a case where you would want to install EXES into bindir, either, instead of somethng like:
install:: for i in $(EXES); do cd $(bindir) && $(RM) -f $$i && $(LN_S) wine $$i; done for i in $(EXES:%=%.so) $(DLLS); do $(INSTALL_PROGRAM) $$i $(bindir); done
Well, let me know what you find.
Winemaker is a terrific help, and thank you for it.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ $live{free} || die "";
Lawson
panic: detected rogue system administrator!! ---cut here
On Fri, 12 Oct 2001 lawson_whitney@juno.com wrote:
On Fri, 12 Oct 2001, Francois Gouget wrote:
Hmm, I never really tested "make install". It's something that was in the original makefile I started from and that I mostly kept around.
How are Winelib programs meant to be installed, then? Am I missing something obvious?
I don't have Wine installed on my system. I just have Wine CVS source trees here and there. So when I compile a foo Winelib application I get a symbolic link to: /home/fgouget/wine/wine. I think it would be wrong to 'install' this foo application in /usr/local/bin and have it be a symlink to '/home/fgouget/wine/wine'! This is why install copies foo so that what you get is a copy of the wine executable.
OTOH it could be argued that since if Wine is not installed on the system, then it is impossible to install a Winelib application: the Wine libraries and dlls would all be missing anyway. Conversely, if you do have Wine installed on the system, then you should compile your Winelib application against that Wine and then installing the Winelib application as a symlink to '/usr/local/bin/wine' may not be so bad.
I believe that Alexandre's position is that Winelib applications should not be symlinks but scripts that call wine. This would have the nice effect of fixing all these issues. It would also create an opportunity to set PATH, LD_LIBRARY_PATH, WINEPREFIX and whatever other environment variable may need to be set/overriden.
Now, on to the more specific bugs that you have found.
Should work though. Make sure that it is not copying the symbolic links but creates real files in the $prefix/bin directory...
for i in ; do (cd $i; make install) || exit 1; done /bin/sh: -c: line 1: syntax error near unexpected token `;' /bin/sh: -c: line 1: `for i in ; do (cd $i; make install) || exit 1; done' make: *** [install] Error 2
This could also affect all other for loops. I have a solution for this.
install:: for i in $(SUBDIRS); do (cd $$i; $(MAKE) install) || exit 1; done for i in $(EXES); do $(INSTALL_PROGRAM) $$i $(bindir); done for i in $(EXES:%=%.so) $(DLLS); do $(INSTALL_PROGRAM) $$i $(libdir); done
[...]
wine executable in the name of each executable, and we install the .so file in libdir. AFAICT, wine will be looking for it in bindir. I
That was a mistake.
Ok, I am sending a patch to wine-patches fixing all this.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
On Fri, 12 Oct 2001, Francois Gouget wrote:
I don't have Wine installed on my system. I just have Wine CVS source trees here and there. So when I compile a foo Winelib application I get a symbolic link to: /home/fgouget/wine/wine. I think it would be wrong to 'install' this foo application in /usr/local/bin and have it be a symlink to '/home/fgouget/wine/wine'! This is why install copies foo so that what you get is a copy of the wine executable.
That makes sense, if you have space in your wine cellar.
OTOH it could be argued that since if Wine is not installed on the system, then it is impossible to install a Winelib application: the Wine libraries and dlls would all be missing anyway. Conversely, if you do have Wine installed on the system, then you should compile your Winelib application against that Wine and then installing the Winelib application as a symlink to '/usr/local/bin/wine' may not be so bad.
The Wine executable is so tiny anymore it isn't all that big a deal if we have a few extra copies.
I believe that Alexandre's position is that Winelib applications should not be symlinks but scripts that call wine. This would have the nice effect of fixing all these issues. It would also create an opportunity to set PATH, LD_LIBRARY_PATH, WINEPREFIX and whatever other environment variable may need to be set/overriden.
Right. It shifts some peripheral issues so they are definitely not his problem. It is hard for me to disagree with Alexandre, except on the very rare occasion when I am right.
Well, would it be appropriate for winemaker to generate a rudimentary script? Or would you rather leave that to the individual Winelib developer?
Now, on to the more specific bugs that you have found.
This could also affect all other for loops. I have a solution for this.
I couldn't see how this would make a difference, but there is a lot I don't know...
_list=""; for i in $_list); do (cd $i; make install) || exit 1; done /bin/sh: -c: line 1: syntax error near unexpected token `;' /bin/sh: -c: line 1: `_list=""; for i in $_list); do (cd $i; make install) || exit 1; done' make: *** [install] Error 2
I guess that must be an old autoconf. Everything else I think should be pretty well up to date.
Autoconf version 2.13
Ok, I am sending a patch to wine-patches fixing all this.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
Thanks. The Winelib part of the app is in pretty good shape, but I don't want to try to make a configure.in for the rest of it. I will though, I guess.
Lawson ---oof---
-
Francois Gouget -
lawson_whitney＠juno.com