Re: getting started
Dimitrie O. Paun wrote: Compiling stuff with visual studio is a first step. But it should be very simple to do a Makefile for the examples, how many files do you have in one example? Here is an example Makefile that you can use under mingw: (let me know if it doesn't work, I just typed it inline here, no testing) Well I know at least the basics of Makefiles already, on linux anyhow. I'm thinking I can easily come up with one for each of the sample programs in my books. I guess I was confused by the suggestion to use the Makefiles from my book, thinking that there would be something special about them. I'm not very familiar with windows development, so it's an honest mistake. It seems studio doesn't even use makefiles though. By the way, I feel terrible about it, hehe, but I went out and got visual c++. So I guess I'll be testing any executables I produce with it as well as going the other route with mingw. So now unless I have any unforseen problems, you probably won't hear from me for a while until I find something that doesn't work. Thanks for taking the time to help me get started.
[Fwd: Re: getting started]
Dimitrie O. Paun wrote: Compiling under the SDK using MS tools gives us little value. We already know that works. If you don't want to spend the cash on MSVC (and not make MS any richer :)), and are willing to invest some time into it, I suggest the following path: 1. Get the latest mingw 2.0 distribution from http://www.mingw.org 2. Modify the makefiles that come in the book to work with GNU make, and the mingw tool chain. Make sure you use forward slashes (/)! :) 3. Build on Windows with your newly created Makefiles, and verify that everthing runs under Windows just fine. 4. If you feel like it, document what steps you took to convert the makefiles. Maybe we'll put that on the Winelib page, to help others in the future. 5. Take the exact same Makefiles you used under Windows, change 3 lines in them (CC=winegcc, CXX=wineg++, WINDRES=wrc), and try to compile under Linux. Use the latest Wine tree, and you should have native Linux apps. If you get errors in this step, they are Wine error, please report them, and let's try to fix them. This is the real value of this exercise. 6. Once everything builds, run the apps, and make sure they run fine. If they have problems, and you feel brave, let the debugging begin! Welcome to the team! Well I've gotten MinGW and sorta learned my way around it. But now, my problem is that neither of my windows programming books has makefiles of any sort. All they have is C++ code. So maybe I should go with my original plan of compiling stuff with visual studio and seeing if it runs under wine. Or do you have any other suggestions?
Re: [Fwd: Re: getting started]
Glen Kaukola wrote: Well I've gotten MinGW and sorta learned my way around it. But now, my problem is that neither of my windows programming books has makefiles of any sort. All they have is C++ code. So maybe I should go with my original plan of compiling stuff with visual studio and seeing if it runs under wine. Or do you have any other suggestions? Your plan's fine -- but you should also go ahead and learn Make, and test the code in the books using MinGW and Makefiles. Knowledge is power. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com
Re: getting started
On January 10, 2003 01:14 am, Glen Kaukola wrote: All they have is C++ code. So maybe I should go with my original plan of compiling stuff with visual studio and seeing if it runs under wine. Or do you have any other suggestions? Compiling stuff with visual studio is a first step. But it should be very simple to do a Makefile for the examples, how many files do you have in one example? Here is an example Makefile that you can use under mingw: (let me know if it doesn't work, I just typed it inline here, no testing) --- cut here CC = gcc# change this to winegcc under Wine CXX = g++ # change this to wineg++ under Wine RC = windres# change this to wrc under Wine # There six lines will change between examples TARGET = sample1.exe #name of the executable SRCS = file1.cpp file2.cpp ... RSRC = res1.rc res2.rc ... # If you need to add defines, add them to CPPFLAGS # CPPFLAGS, INCDIRS, LIBDIRS, and LIBS may change between examples CPPFLAGS = # add stuff here like -D_WIN32_IE=0x0400 CFLAGS = -mno-cygwin -W -Wall -g -gstabs+ -fno-exceptions -fno-rtti LDFLAGS = -mno-cygwin -mwindows INCDIRS = # add stuff there like -I../include LIBDIRS = # add stuff like -L../lib LIBS = -lcomctl32 # we'll need to add more libs in here for sure OBJ = $(SRCS:.c=.o) $(RSRC:.c=.o) %.o : %.rc $(RC) $(CPPFLAGS) $ $@ %.o : %.cpp $(CXX) $(CFLAGS) $(CPPFLAGS) $(INCDIRS) -c -o $@ $ %.o : %.c $(CC) $(CFLAGS) $(CPPFLAGS) $(INCDIRS) -c -o $@ $ $(TARGET): $(OBJS) $(CXX) $(LDFLAGS) $(LIBDIRS) $(LIBS) -o $@ $(OBJS) # A few nice targets all:$(TARGET) clean: rm -f $(TARGET) $(OBJS) --- cut here It's not hard, just look in the .dsp project to see what you need to put in these variables. -- Dimi.
Re: getting started
On January 7, 2003 03:03 am, Glen Kaukola wrote: So what I'm wondering now is what I should be using to compile my applications on windows. One of the books I have says all I need is the win32 sdk and I can compile apps. The closest thing I can find on msdn is the microsoft platform sdk, or perhaps the .net sdk. I've installed the microsoft platform sdk core but it doesn't seem to contain nmake.exe like the book I have talks about. So maybe I just need more pieces of the sdk? Or maybe I've installed the wrong thing entirely? Compiling under the SDK using MS tools gives us little value. We already know that works. If you don't want to spend the cash on MSVC (and not make MS any richer :)), and are willing to invest some time into it, I suggest the following path: 1. Get the latest mingw 2.0 distribution from http://www.mingw.org 2. Modify the makefiles that come in the book to work with GNU make, and the mingw tool chain. Make sure you use forward slashes (/)! :) 3. Build on Windows with your newly created Makefiles, and verify that everthing runs under Windows just fine. 4. If you feel like it, document what steps you took to convert the makefiles. Maybe we'll put that on the Winelib page, to help others in the future. 5. Take the exact same Makefiles you used under Windows, change 3 lines in them (CC=winegcc, CXX=wineg++, WINDRES=wrc), and try to compile under Linux. Use the latest Wine tree, and you should have native Linux apps. If you get errors in this step, they are Wine error, please report them, and let's try to fix them. This is the real value of this exercise. 6. Once everything builds, run the apps, and make sure they run fine. If they have problems, and you feel brave, let the debugging begin! Welcome to the team! -- Dimi.
Re: getting started
On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: [...] Compiling under the SDK using MS tools gives us little value. We already know that works. If you don't want to spend the cash on MSVC (and not make MS any richer :)), and are willing to invest some time into it, I suggest the following path: 1. Get the latest mingw 2.0 distribution from http://www.mingw.org 2. Modify the makefiles that come in the book to work with GNU make, and the mingw tool chain. Make sure you use forward slashes (/)! :) 3. Build on Windows with your newly created Makefiles, and verify that everthing runs under Windows just fine. 4. If you feel like it, document what steps you took to convert the makefiles. Maybe we'll put that on the Winelib page, to help others in the future. 5. Take the exact same Makefiles you used under Windows, change 3 lines in them (CC=winegcc, CXX=wineg++, WINDRES=wrc), and try to compile under Linux. Use the latest Wine tree, and you should have native Linux apps. If you get errors in this step, they are Wine error, please report them, and let's try to fix them. This is the real value of this exercise. 6. Once everything builds, run the apps, and make sure they run fine. If they have problems, and you feel brave, let the debugging begin! Or: 1. get the sources to a Linux machine 2. run winemaker on the sources to generate Makefiles 3. use the Makefiles to compile the examples using Winelib In this step you may find that winemaker made some mistakes about how to generate the Makefiles. You can either fix the makefiles (the simplest option), or try to improve winemaker. I bet the examples come with .dsp and .dsw files and improving winemaker to understand these would greatly improve its accuracy. 4. fix the compilation and link errors thus improving Winelib. 5. once everything, builds run the apps, and make sure they run fine. If they have problems, and you feel brave, let the debugging begin! This is pretty much what I have done with three programming books. However I have not had time to work on this for a long time and the Winelib compilation procedure has changed so much that probably nothing compiles anymore... But you are welcome to have a look at what I did and see if there is something salvageable: http://fgouget.free.fr/wine/booktesting-en.shtml Welcome to the team! Yep. The more the merrier. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.
Re: getting started
On January 7, 2003 03:39 am, Francois Gouget wrote: 1. get the sources to a Linux machine 2. run winemaker on the sources to generate Makefiles We should modify winemaker to use winegcc. There's now a lot of (bad) duplication between winemaker, and winegcc, like wrapper support, linking, etc. Moreover, having winegcc handle the linking details automatically, we (1) shield the users from all that nastiness, and (2) retain more freedom on changing things in the build process. More importantly, we should generate Makefiles that work as is on mingw as well. This would increase their usefulness considerably. My Perl knowledge approaches zero asymptotically, so I can't quite do this myself, but I am willing to help on it with what's needed. -- Dimi.
Re: getting started
On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: On January 7, 2003 03:39 am, Francois Gouget wrote: 1. get the sources to a Linux machine 2. run winemaker on the sources to generate Makefiles We should modify winemaker to use winegcc. There's now a lot of (bad) duplication between winemaker, and winegcc, like wrapper support, linking, etc. Actually there is not all that much duplication and I think winemaker and winegcc have different purposes: * winegcc co The assumption is that the user already has Mingw makefiles that work. So their goal is simply to emulate the tools that come with the Mingw environment. * winemaker The assumption is that you have a Windows application (complete with CR/LF), most likely based on Visual C++ and thus with no suitable makefiles. So winemaker's goal is to quickly generate suitable Makefiles that will build Winelib applications/dlls from what it's given and fix the simple issues in the source (CR/LF, #pragmas). The backend is somewhat secondary. Currently the Makefiles are modelled after the Makefiles used to build the programs in Wine. From there we can go into two directions for the backend: 1. make the Makefiles more similar to those of the Wine programs. Alexandre told me he wanted the winemaker Makefiles to match and reuse more stuff from Wine. Part of this goal was to move lots of autoconf stuff to a .m4 file and to use that in both Wine and Winemaker generated stuff. There is some work to do there to make this feasible because Winemaker has to deal with the possibility that there may be multiple .exe/.dlls to build from a single Makefile (so you cannot define a single 'MODULE=' variable at the top of the Makefile) whereas this is never the case in Wine. 2. we can modify Winemaker to generate Mingw makefiles (does that rule out using autoconf?) and assume that a 3 line change will turn them into Winelib makefiles (or the other way around). Actually, has anyone written a .dsp to Mingw makefile converter? Potentially we could do both: * modify the makefiles in programs/* to use winegcc co * turn these Makefiles into Mingw makefiles * make it so as much of this as possible can be shared with Winemaker * have Winemaker generate Mingw compatible makefiles based on the model above Moreover, having winegcc handle the linking details automatically, we (1) shield the users from all that nastiness, and (2) retain more freedom on changing things in the build process. The user is already somewhat shielded from these issues since he does not have to write the Makefiles. However each time the build process changes the Makefiles break so if winegcc co can help with that it would be nice. [...] My Perl knowledge approaches zero asymptotically, so I can't quite do this myself, but I am willing to help on it with what's needed. The problem for me is time :-( -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...
Re: getting started
On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: On January 7, 2003 02:25 pm, Francois Gouget wrote: * winemaker The assumption is that you have a Windows application (complete with CR/LF), most likely based on Visual C++ and thus with no suitable makefiles. So winemaker's goal is to quickly generate suitable Makefiles that will build Winelib applications/dlls from what it's given and fix the simple issues in the source (CR/LF, #pragmas). The backend is somewhat secondary. This touches on an issue that I'd like to avoid discussing now -- it deserves a separate thread. But just to note that the things you've mentioned are not mutually exclusive: [...] -- Having the make files portable between Wine/Linux/MinGW can only be a good thing, right? I think our views are not incompatible and even that we basically agree. However there is a difference in emphasis. I'm more interested in improving the front-end, especially by adding support for dsp file which I think would improve the usefulness of winemaker tremendously (so that's what I would work on if I had time). You are more interested in the backend and in making it compatible with MinGW. However since I probably won't have time to make significant changes to winemaker in the near future my preferences are moot. Call for help: Please if you are interested in working on either aspect let us know (me or Dimitrie) and we will try to help you each with the part we are more familiar with. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Utilisateur (nom commun) : Mot utilisé par les informaticiens en lieu et place d'idiot.
Re: getting started
On January 8, 2003 01:18 am, David Fraser wrote: Me! Do we have a task list for this? Depends on what you want to work on :) If you want to adapt winemaker to better integrate with winegcc, I'm your man! g -- Dimi.
Re: getting started
Francois Gouget wrote: On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: On January 7, 2003 02:25 pm, Francois Gouget wrote: * winemaker The assumption is that you have a Windows application (complete with CR/LF), most likely based on Visual C++ and thus with no suitable makefiles. So winemaker's goal is to quickly generate suitable Makefiles that will build Winelib applications/dlls from what it's given and fix the simple issues in the source (CR/LF, #pragmas). The backend is somewhat secondary. This touches on an issue that I'd like to avoid discussing now -- it deserves a separate thread. But just to note that the things you've mentioned are not mutually exclusive: [...] -- Having the make files portable between Wine/Linux/MinGW can only be a good thing, right? I think our views are not incompatible and even that we basically agree. However there is a difference in emphasis. I'm more interested in improving the front-end, especially by adding support for dsp file which I think would improve the usefulness of winemaker tremendously (so that's what I would work on if I had time). You are more interested in the backend and in making it compatible with MinGW. However since I probably won't have time to make significant changes to winemaker in the near future my preferences are moot. Call for help: Please if you are interested in working on either aspect let us know (me or Dimitrie) and we will try to help you each with the part we are more familiar with. Me! Do we have a task list for this? David
Re: Getting Started
On 2001.12.09 17:15 Oliver Sampson wrote: [SNIP] ot Why is the default behavior for the list to have replies go only to the sender and not to the list? /ot Because that would be ridiculous. The only way to really accomplish that is to add a Reply-To which means that it then becomes impossible to easily reply directly to the author. If you don't add it then all you need to do is hit Reply All which will cause it to send it To: the original author, and Cc: it to the list. So assuming you have your mail filters setup such that mail which went through the list goes into the wine-devel mailbox and other mail is processed as usual then you will get two copies: one directly to you in your inbox and one in the list. Personally I prefer this because I can then reply directly to any pertinent things before I go reading the rest of the list. Like this: MAILDIR=$HOME/mail/incoming :0:wine/announce.lock * ^Sender:.*[EMAIL PROTECTED] wine/announce :0:wine/cvs.lock * ^Sender:.*[EMAIL PROTECTED] wine/cvs :0:wine/devel.lock * ^Sender:.*[EMAIL PROTECTED] wine/devel :0:wine/patches.lock * ^Sender:.*[EMAIL PROTECTED] wine/patches That is part of my .procmailrc file which will filter on the sender line (mail that has gone through the list servers). Note that I do not filter on To or CC line as is stated on the website because then anyone who sent mail directly to me but also cced it to the list, well, it goes into the list, which defeats the whole benefit of getting two copies of the mail. Hmm, come to think of it, maybe someone should put those lines up on the WineHQ website as an alternative method, or in place of the current method. IIRC the website is in CVS, would someone want me to send a patch for this? -Dave
Re: Getting Started
On 2001.12.10 16:57 Oliver Sampson wrote: On Mon, 10 Dec 2001 16:30:04 -0500, David Elliott [EMAIL PROTECTED] wrote: On 2001.12.09 17:15 Oliver Sampson wrote: [SNIP] ot Why is the default behavior for the list to have replies go only to the sender and not to the list? /ot Because that would be ridiculous. The only way to really accomplish that is to add a Reply-To which means that it then becomes impossible to easily reply directly to the author. Well, it's not rediculous. And it's not rediculous when you consider that *every other* list (save one) to which I'm subscribed has the list as the default reply-to. The assumption is that if it's important enough to be asked in public, then the answer should be public also. Why should the assumed answer be private? I'm in a habit of replying to mail, not replying-all to mail, and when I reply to mail on this list, I find that I end up sending it twice. (My assumption is that I'm a typical listserv subscriber.) Rarely, do I want to send an email off-list. Do you (and the majority of the members here) send so many off-list emails in response to on-list emails that having the default reply-to for the list, not be the list itself? Hey, it was just a question. Nah, more like a religious issue actually. I really despise the Reply-To munging on some lists and much prefer the way that it is done on this list (which I believe is also how the Linux Kernel list works, last time I was subscribed to it). The way I see it the reply-to header causes the mail client to do silly things and not including it allows more flexibility in the way messages are replied to. But believe me, when I first joined the list I was in your shoes until I realized that Reply-All is really the way to go. If you think about it, it makes sense: Reply - i.e. Reply to the sender Reply All - i.e. Reply to everyone (which is usually the sender and the list). Furthermore, if you include a reply-to header then: Reply - Replies to the list, not the sender Reply All - Replies to the list twice, once because it replaces the senders address with the reply to, and another time because the list was a receipient of the message. It also breaks anyone who actually uses a reply-to header for a legitimate reason. This argument has been discussed before way back when on this list (or was it LKML?, I think it was this one). Almost the exact arguments I am giving above were presented. Believe me, I used to think like you did until I heard this argument, so maybe that'll set it in for ya. [BIG SNIP] I find filtering on the List-Id: field to be the most accurate and unambiguous. List-Id: Wine Developer's List wine-devel.winehq.com Hmm, Dunno how in the hell I missed that... maybe at one point that wasn't there so the only unique thing I could come up with was Sender:. Anyway, this is the end of this thread by far, please send any responses directly using the Reply button as opposed to the Reply All button. :-P -Dave
Re: Getting Started
So, it's solved. How did I solve it? Uh, I read the directions. Rather than do a ./configuremake install as I listed below, I did a ./tools/wineinstall. Worked fine. WTF? I guess I'll have a bit of a closer look at the wineinstall script, and see what the difference was. Anyhow, I'm up and running with a reasonably fresh copy of wine. So, what's the normal update process? cvs update; make depend; make; make install? or wineinstall? ot Why is the default behavior for the list to have replies go only to the sender and not to the list? /ot Thanks, Oliver On Sat, 08 Dec 2001 16:59:19 +0100, Rein Klazes [EMAIL PROTECTED] wrote: On Sat, 08 Dec 2001 16:33:53 +0100, you wrote: I checked out my /etc/ld.so.conf and /usr/lib is listed in there. libntdll.so is in my /usr/lib, but when ever I run wine from what I've made, I get the message that libntdll.so can't be found: wine: error while loading shared libraries: libntdll.so: cannot open shared object file: No such file or directory Hmm, and you did run ldconfig ? Umm. no. Not explicitly, but I noticed that it's the last thing called during the 'make install'. When I run it (as root, of course) it returns no errors, leading me to believe all is okay. However, I'm still getting the libntdll error. Let's assume that I know nothing and I've read the wine web page enough to download a cvs image. After I update my directory, it's a matter of autoconf ./configure make depend make make install. Is there anything missing in that sequence of steps? Afterwards, I should be able to type 'wine ...' and be on my way, right? You are doing a standard wine install. This installs the wine executables in /usr/local/bin and the libs in /usr/local/lib (do a ./configure --help to see how those can be changed). That means that you must have: - either /usr/local/lib configured in /etc/ld.so.conf or it is specified in the LD_LIBRARY_PATH - /usr/local/bin must be part of the PATH. - wine executables in /usr/bin and /usr/lib are part of another wine install, probably the one from the rpm. It is best to remove them. Also interesting, but every so slightly possibly could be related is that even though I'm using the Dec 3 cvs update, (for the rpm that I can get to run) when I type wine --version, it gives me 200011108, which was the original wine package I had installed. Even though I removed it (rpm -e) something from it appears to be remaining. That is normal. --version is not updated between the offcial snapshots. Rein. Oliver Sampson [EMAIL PROTECTED] http://www.oliversampson.com
Re: Getting Started
On Sun, Dec 09, 2001 at 11:15:46PM +0100, Oliver Sampson wrote: So, it's solved. How did I solve it? Uh, I read the directions. Rather than do a ./configuremake install as I listed below, I did a ./tools/wineinstall. Worked fine. WTF? I guess I'll have a bit of a closer look at the wineinstall script, and see what the difference was. Hmm, strange. So, what's the normal update process? cvs update; make depend; make; make install? Well, yeah. But cvs update make depend all is faster ;) (provided you do have your wine setup prepared appropriately) ot Why is the default behavior for the list to have replies go only to the sender and not to the list? /ot Hmm, dunno. I'm not the #1 expert here. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: Getting Started
On Sun, 9 Dec 2001 23:34:53 +0100, Andreas Mohr [EMAIL PROTECTED] wrote: So, what's the normal update process? cvs update; make depend; make; make install? Well, yeah. But cvs update make depend all is faster ;) (provided you do have your wine setup prepared appropriately) And do I dare ask what that might be? Thanks, Oliver Sampson [EMAIL PROTECTED] http://www.oliversampson.com
Re: Getting Started
On Fri, 7 Dec 2001 18:31:03 +0100, Andreas Mohr [EMAIL PROTECTED] wrote: On Fri, Dec 07, 2001 at 06:06:36PM +0100, Oliver Sampson wrote: Howdy, I'm trying to get started with Wine development, and I figured the best way would be to CVS the code and install it. I CVSed the code, configured, did a 'make depend', 'make', and a 'make install'. When I try to run wine, I get a message that libntdll.so wasn't found. So I found it in /usr/lib/libntdll.so. is there something in the initial setup config that didn't work correctly? Make sure /etc/ld.so.conf contains the path. See www.winehq.com/Trouble/ for details. I went to the modifyable FAQ and saw an entry for libntdll.so, but I didn't see any assistance to the problem. Is this a hint for me to add an answer for when I get this resolved? I checked out my /etc/ld.so.conf and /usr/lib is listed in there. libntdll.so is in my /usr/lib, but when ever I run wine from what I've made, I get the message that libntdll.so can't be found: wine: error while loading shared libraries: libntdll.so: cannot open shared object file: No such file or directory I tried setting the LD_LIBRARY_PATH as suggested in the other post, but that didn't seem to help either. Thanks, Oliver FWIW, I can rpm the wine-cvs-unstripped rpm just fine, and it works well. (The install process and the program.) Any ideas how to get this working from my cvs directory? Simply *don't* do make install, but rather create symlinks in global dirs or add to PATH. Ask whenever you need help with development ! Good luck ! Oliver Sampson [EMAIL PROTECTED] http://www.oliversampson.com
Re: Getting Started
On Sat, Dec 08, 2001 at 01:20:53PM +0100, Oliver Sampson wrote: On Fri, 7 Dec 2001 18:31:03 +0100, Andreas Mohr [EMAIL PROTECTED] wrote: On Fri, Dec 07, 2001 at 06:06:36PM +0100, Oliver Sampson wrote: When I try to run wine, I get a message that libntdll.so wasn't found. So I found it in /usr/lib/libntdll.so. is there something in the initial setup config that didn't work correctly? Make sure /etc/ld.so.conf contains the path. See www.winehq.com/Trouble/ for details. I went to the modifyable FAQ and saw an entry for libntdll.so, but I didn't see any assistance to the problem. Is this a hint for me to add an answer for when I get this resolved? Err, yes ;-) I checked out my /etc/ld.so.conf and /usr/lib is listed in there. libntdll.so is in my /usr/lib, but when ever I run wine from what I've made, I get the message that libntdll.so can't be found: wine: error while loading shared libraries: libntdll.so: cannot open shared object file: No such file or directory Hmm, and you did run ldconfig ? -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: Getting Started
On Sat, 8 Dec 2001 14:40:17 +0100, Andreas Mohr [EMAIL PROTECTED] wrote: On Sat, Dec 08, 2001 at 01:20:53PM +0100, Oliver Sampson wrote: On Fri, 7 Dec 2001 18:31:03 +0100, Andreas Mohr [EMAIL PROTECTED] wrote: On Fri, Dec 07, 2001 at 06:06:36PM +0100, Oliver Sampson wrote: When I try to run wine, I get a message that libntdll.so wasn't found. So I found it in /usr/lib/libntdll.so. is there something in the initial setup config that didn't work correctly? Make sure /etc/ld.so.conf contains the path. See www.winehq.com/Trouble/ for details. I went to the modifyable FAQ and saw an entry for libntdll.so, but I didn't see any assistance to the problem. Is this a hint for me to add an answer for when I get this resolved? Err, yes ;-) I thought so. No problem--I'll take care of it when I solve this. However. I checked out my /etc/ld.so.conf and /usr/lib is listed in there. libntdll.so is in my /usr/lib, but when ever I run wine from what I've made, I get the message that libntdll.so can't be found: wine: error while loading shared libraries: libntdll.so: cannot open shared object file: No such file or directory Hmm, and you did run ldconfig ? Umm. no. Not explicitly, but I noticed that it's the last thing called during the 'make install'. When I run it (as root, of course) it returns no errors, leading me to believe all is okay. However, I'm still getting the libntdll error. Let's assume that I know nothing and I've read the wine web page enough to download a cvs image. After I update my directory, it's a matter of autoconf ./configure make depend make make install. Is there anything missing in that sequence of steps? Afterwards, I should be able to type 'wine ...' and be on my way, right? Also interesting, but every so slightly possibly could be related is that even though I'm using the Dec 3 cvs update, (for the rpm that I can get to run) when I type wine --version, it gives me 200011108, which was the original wine package I had installed. Even though I removed it (rpm -e) something from it appears to be remaining. Oliver Sampson [EMAIL PROTECTED] http://www.oliversampson.com
Re: Getting Started
On Sat, Dec 08, 2001 at 04:33:53PM +0100, Oliver Sampson wrote: On Sat, 8 Dec 2001 14:40:17 +0100, Andreas Mohr [EMAIL PROTECTED] wrote: On Sat, Dec 08, 2001 at 01:20:53PM +0100, Oliver Sampson wrote: I checked out my /etc/ld.so.conf and /usr/lib is listed in there. libntdll.so is in my /usr/lib, but when ever I run wine from what I've made, I get the message that libntdll.so can't be found: wine: error while loading shared libraries: libntdll.so: cannot open shared object file: No such file or directory Hmm, and you did run ldconfig ? Umm. no. Not explicitly, but I noticed that it's the last thing called during the 'make install'. When I run it (as root, of course) it returns no errors, leading me to believe all is okay. However, I'm still getting the libntdll error. Let's assume that I know nothing and I've read the wine web page enough to download a cvs image. After I update my directory, it's a matter of autoconf ./configure make depend make make install. NOT autoconf. That shouldn't be needed. Is there anything missing in that sequence of steps? Afterwards, I should be able to type 'wine ...' and be on my way, right? yep. Also interesting, but every so slightly possibly could be related is that even though I'm using the Dec 3 cvs update, (for the rpm that I can get to run) when I type wine --version, it gives me 200011108, which was the original wine package I had installed. Even though I removed it (rpm -e) something from it appears to be remaining. Uh oh. That's exactly what I suspected. Try www.winehq.com/Trouble/, total cleanup -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: Getting Started
On Sat, 08 Dec 2001 16:33:53 +0100, you wrote: I checked out my /etc/ld.so.conf and /usr/lib is listed in there. libntdll.so is in my /usr/lib, but when ever I run wine from what I've made, I get the message that libntdll.so can't be found: wine: error while loading shared libraries: libntdll.so: cannot open shared object file: No such file or directory Hmm, and you did run ldconfig ? Umm. no. Not explicitly, but I noticed that it's the last thing called during the 'make install'. When I run it (as root, of course) it returns no errors, leading me to believe all is okay. However, I'm still getting the libntdll error. Let's assume that I know nothing and I've read the wine web page enough to download a cvs image. After I update my directory, it's a matter of autoconf ./configure make depend make make install. Is there anything missing in that sequence of steps? Afterwards, I should be able to type 'wine ...' and be on my way, right? You are doing a standard wine install. This installs the wine executables in /usr/local/bin and the libs in /usr/local/lib (do a ./configure --help to see how those can be changed). That means that you must have: - either /usr/local/lib configured in /etc/ld.so.conf or it is specified in the LD_LIBRARY_PATH - /usr/local/bin must be part of the PATH. - wine executables in /usr/bin and /usr/lib are part of another wine install, probably the one from the rpm. It is best to remove them. Also interesting, but every so slightly possibly could be related is that even though I'm using the Dec 3 cvs update, (for the rpm that I can get to run) when I type wine --version, it gives me 200011108, which was the original wine package I had installed. Even though I removed it (rpm -e) something from it appears to be remaining. That is normal. --version is not updated between the offcial snapshots. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Getting Started
On Fri, Dec 07, 2001 at 06:06:36PM +0100, Oliver Sampson wrote: Howdy, I'm trying to get started with Wine development, and I figured the best way would be to CVS the code and install it. I CVSed the code, configured, did a 'make depend', 'make', and a 'make install'. When I try to run wine, I get a message that libntdll.so wasn't found. So I found it in /usr/lib/libntdll.so. is there something in the initial setup config that didn't work correctly? Make sure /etc/ld.so.conf contains the path. See www.winehq.com/Trouble/ for details. FWIW, I can rpm the wine-cvs-unstripped rpm just fine, and it works well. (The install process and the program.) Any ideas how to get this working from my cvs directory? Simply *don't* do make install, but rather create symlinks in global dirs or add to PATH. Ask whenever you need help with development ! Good luck ! -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: Getting Started
On Fri, 7 Dec 2001, Andreas Mohr wrote: On Fri, Dec 07, 2001 at 06:06:36PM +0100, Oliver Sampson wrote: [...] Any ideas how to get this working from my cvs directory? Simply *don't* do make install, but rather create symlinks in global dirs or add to PATH. Or add to LD_LIBRARY_PATH rather than creating global symlinks. I have a script that I source which sets PATH and LD_LIBRARY_PATH properly for the wine CVS tree that I pass in parameter. At the core it does: LD_LIBRARY_PATH=$WINE_ROOT:$WINE_ROOT/dlls PATH=$WINE_ROOT:$WINE_ROOT/server:$WINE_ROOT/tools:$PATH export WINE_ROOT LD_LIBRARY_PATH PATH (note: you could also add debugger and tools to the PATH) -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy
Re: Getting Started
Many thanks for the ideas. I'll get right on them. Oliver On Fri, 7 Dec 2001 09:50:16 -0800 (PST), Francois Gouget [EMAIL PROTECTED] wrote: On Fri, 7 Dec 2001, Andreas Mohr wrote: On Fri, Dec 07, 2001 at 06:06:36PM +0100, Oliver Sampson wrote: [...] Any ideas how to get this working from my cvs directory? Simply *don't* do make install, but rather create symlinks in global dirs or add to PATH. Or add to LD_LIBRARY_PATH rather than creating global symlinks. I have a script that I source which sets PATH and LD_LIBRARY_PATH properly for the wine CVS tree that I pass in parameter. At the core it does: LD_LIBRARY_PATH=$WINE_ROOT:$WINE_ROOT/dlls PATH=$WINE_ROOT:$WINE_ROOT/server:$WINE_ROOT/tools:$PATH export WINE_ROOT LD_LIBRARY_PATH PATH (note: you could also add debugger and tools to the PATH) Oliver Sampson [EMAIL PROTECTED] http://www.oliversampson.com
