From: <zm...@ma...> - 2008-03-29 03:27:33
|
Hi, I have a mac development environment set up with mingw, parallels, and winxp, to compile windows directx apps from the mac console and eventually in xcode. I used this page to get started, it works great: http://www.libsdl.org/extras/win32/cross/README.txt I am trying to compile a simple test.c file with (all one line): /usr/local/cross-tools/bin/i386-mingw32-g++ -I"/Users/zmorris/ Development/Windows/DXSDK/include" -L"/usr/local/cross-tools/ lib" -mwindows -g -o test.exe test.c libddraw.a The include portion is where I manually copied the windows DXSDK into my development folder to get the directx headers, and is working perfectly to give me ddraw.h etc, but for the life of me I can't get the -L option to work. If I copy libddraw.a manually into my local directory, it compiles fine. I am not using a configure script. I have scoured google for hours. I hardly ever ask mailing lists, but I think this is something that most people will encounter their first time compiling so hopefully the answer can go into the archives. Is there another command like LDFLAGS, LIBPATH etc that will get this working? Thanx! --Zack |
From: John B. <joh...@ho...> - 2008-03-29 03:48:47
|
zmorris wrote: [snip] > > I am trying to compile a simple test.c file with (all one line): > > /usr/local/cross-tools/bin/i386-mingw32-g++ -I"/Users/zmorris/ > Development/Windows/DXSDK/include" -L"/usr/local/cross-tools/ > lib" -mwindows -g -o test.exe test.c libddraw.a > [snip] Assuming that libXXX.a is in the directory specified by -L, then write '-lXXX' instead of 'libXXX.a'. If you want, you can also write '/full/path/to/libXXX.a' _________________________________________________________________ Watch “Cause Effect,” a show about real people making a real difference. Learn more. http://im.live.com/Messenger/IM/MTV/?source=text_watchcause |
From: <zm...@ma...> - 2008-03-29 04:06:59
|
On Mar 28, 2008, at 9:48 PM, John Brown wrote: > > zmorris wrote: > > [snip] > >> >> I am trying to compile a simple test.c file with (all one line): >> >> /usr/local/cross-tools/bin/i386-mingw32-g++ -I"/Users/zmorris/ >> Development/Windows/DXSDK/include" -L"/usr/local/cross-tools/ >> lib" -mwindows -g -o test.exe test.c libddraw.a >> > > [snip] > > Assuming that libXXX.a is in the directory specified by -L, then write > '-lXXX' instead of 'libXXX.a'. If you want, you can also write > '/full/path/to/libXXX.a' Amazing, just amazing :) This is an important enough point, that it might be nice to have an errata or FAQ about it, because I seriously spent all of yesterday searching for how to do this. Thank you very much for your prompt response! --Zack |
From: Tuomo L. <dj...@ik...> - 2008-03-29 13:34:03
|
zm...@ma... wrote: > On Mar 28, 2008, at 9:48 PM, John Brown wrote: >> Assuming that libXXX.a is in the directory specified by -L, then write >> '-lXXX' instead of 'libXXX.a'. If you want, you can also write >> '/full/path/to/libXXX.a' > > Amazing, just amazing :) This is an important enough point, that it > might be nice to have an errata or FAQ about it, because I seriously > spent all of yesterday searching for how to do this. Thank you very > much for your prompt response! This is sort of assumed to be known, since it belongs to the category of "basic gcc usage" rather than to MinGW specifics or common gotchas. It is such a basic piece of information that it really isn't even a FAQ. That is, I can't remember anyone asking about it before. However, digging around a bit, I see "How do I specify the libraries to be searched by the linker?" in the FAQ (http://www.mingw.org/MinGWiki/index.php/FAQ). Of course, had you looked inside some simple Makefiles or searched for various command lines instead of documentation, you probably would have found this nugget a lot earlier. Or maybe googled for "+gcc +linking" to find "An Introduction to GCC - Linking with external libraries" (http://www.network-theory.co.uk/docs/gccintro/gccintro_17.html). -- Tuomo ... Imagine my delight/surprise/embarrassment to find the exact answer to my question when I typed :help submatch()! -- on vi...@vi... |
From: Zack M. <zm...@ma...> - 2008-03-29 23:17:49
|
On Saturday, March 29, 2008, at 06:34AM, "Tuomo Latto" <dj...@ik...> wrote: >zm...@ma... wrote: >> On Mar 28, 2008, at 9:48 PM, John Brown wrote: >>> Assuming that libXXX.a is in the directory specified by -L, then write >>> '-lXXX' instead of 'libXXX.a'. If you want, you can also write >>> '/full/path/to/libXXX.a' >> >> Amazing, just amazing :) This is an important enough point, that it >> might be nice to have an errata or FAQ about it, because I seriously >> spent all of yesterday searching for how to do this. Thank you very >> much for your prompt response! > >This is sort of assumed to be known, since it belongs to the category >of "basic gcc usage" rather than to MinGW specifics or common gotchas. >It is such a basic piece of information that it really isn't even a FAQ. >That is, I can't remember anyone asking about it before. Ya true hmm, I just haven't worked much with configure or passing gcc options directly. Well I have it all working from console, and am now trying to integrate this with Xcode. I have done these steps so far to swap mingw in for gcc, and tell Xcode what flags to pass to it: cd /usr/bin sudo mv gcc gccBACKUP sudo ln -s /usr/local/cross-tools/bin/i386-mingw32-g++ gcc // go into project settings: Architectures: i386 (might be $(NATIVE_ARCH) on intel) Valid Architectures: i386 x86_64 Header Search Paths: /Users/zmorris/Development/Windows/DXSDK/include Library Search Paths: /usr/local/cross-tools/lib Other Linker Flags: -mwindows -g -o -lmingw32 -lddraw So far it allllmost works, but I am getting: ld: warning in /usr/local/cross-tools/lib/libddraw.a, file is not of required architecture "_main", referenced from: start in crt1.10.5.o "_MessageBox", referenced from: _WinMain in main.o ld: symbol(s) not found collect2: ld returned 1 exit status I am still not absolutely certain that Xcode is using mingw. The -mwindows flag should skip the need for main(), and I believe -lmingw32 should provide MessageBox(). I am still missing something, but this whole process seems to still be evolving, with several forums on the web offering different suggestions. FYI, I understand this is a potentially painful path I am on, but I want to understand what is happening at a low level. I also have MS Visual C++ Express in parallels and am building a project in parallel on both sides. It's just quicker for me to work in my native environment is all, and then debug in the visual c++ IDE when I need to. Thanx, --Zack |
From: John B. <joh...@ho...> - 2008-03-30 01:32:53
|
Zack Morris wrote: > Ya true hmm, I just haven't worked much with configure or passing gcc > options directly. Well I have it all working from console, and am now > trying to integrate this with Xcode. I have done these steps so far to > swap mingw in for gcc, and tell Xcode what flags to pass to it: > > cd /usr/bin > sudo mv gcc gccBACKUP > sudo ln -s /usr/local/cross-tools/bin/i386-mingw32-g++ gcc > // go into project settings: > Architectures: i386 (might be $(NATIVE_ARCH) on intel) > Valid Architectures: i386 x86_64 > Header Search Paths: /Users/zmorris/Development/Windows/DXSDK/include > Library Search Paths: /usr/local/cross-tools/lib > Other Linker Flags: -mwindows -g -o -lmingw32 -lddraw > > So far it allllmost works, but I am getting: > > ld: warning in /usr/local/cross-tools/lib/libddraw.a, file is not of required architecture > "_main", referenced from: > start in crt1.10.5.o I don't know anything abiyt Xcode, but: You should create symbolic links g++ and gcc, corresponding to i386-mingw32-g++ and i386-mingw32-gcc respectively. If you are compiling C++ files, you should use g++, otherwise use gcc. gcc will work, but you must add -lstdc++ to the command line. However, that is not the problem (yet). It seems that your native ld is being called instead of the cross-compiler's ld. You should probably create your symbolic links in /usr/local/cross-tools/bin and then ensure that this directory appears before /usr/bin (or any other directory that contains gcc) in your PATH. > "_MessageBox", referenced from: > _WinMain in main.o > ld: symbol(s) not found > collect2: ld returned 1 exit status MessageBox is found in -luser32, which is part of w32api. I assume that w32api is installed. You can search the MSDN Library to find out which header and library files are needed for any Win32 API function. > > I am still not absolutely certain that Xcode is using mingw. The -mwindows flag > should skip the need for main(), and I believe -lmingw32 should provide > MessageBox(). I am still missing something, but this whole process seems to > still be evolving, with several forums on the web offering different suggestions. > The -o flag does not belong in 'Other Linker Flags'. I don't think that it is necessary to explicitly link to -lmingw32, and it may even be the problem. > FYI, I understand this is a potentially painful path I am on, but I want to > understand what is happening at a low level. I also have MS Visual C++ > Express in parallels and am building a project in parallel on both sides. > It's just quicker for me to work in my native environment is all, and then > debug in the visual c++ IDE when I need to. > > Thanx, > > --Zack > _________________________________________________________________ Windows Live Hotmail is giving away Zunes. http://www.windowslive-hotmail.com/ZuneADay/?locale=en-US&ocid=TXT_TAGLM_Mobile_Zune_V3 |
From: <zm...@ma...> - 2008-03-31 04:36:48
|
On Mar 29, 2008, at 7:32 PM, John Brown wrote: > > Zack Morris wrote: > >> Ya true hmm, I just haven't worked much with configure or passing gcc >> options directly. Well I have it all working from console, and am now >> trying to integrate this with Xcode. I have done these steps so far >> to >> swap mingw in for gcc, and tell Xcode what flags to pass to it: >> ... > > I don't know anything abiyt Xcode, but: > You should create symbolic links g++ and gcc, corresponding to i386- > mingw32-g++ > and i386-mingw32-gcc respectively. If you are compiling > C++ files, you should use g++, otherwise use gcc. gcc will work, but > you must > add -lstdc++ to the command line. However, that is not the problem > (yet). > > It seems that your native ld is being called instead of the > cross-compiler's ld. You should probably create your symbolic links > in > /usr/local/cross-tools/bin and then ensure that this directory > appears before > /usr/bin (or any other directory that contains gcc) in your PATH. Man, unbelievably, I spent a couple of hours researching and reinvented the wheel doing exactly this method. The symlinks for xcode go in /Developer/usr/bin, and you have to point /Developer/usr/ bin/gcc-4.0 to /usr/local/cross-tools/bin/i386-mingw32-g++ and / Developer/usr/bin/ld to i386-mingw32-ld. Unfortunately, mingw can't handle -arch, -F/ or -I/yourapp.exe.hmap. I had to make a perl script to filter these out and then call mingw with the new arg list. >> "_MessageBox", referenced from: >> _WinMain in main.o >> ld: symbol(s) not found >> collect2: ld returned 1 exit status > > MessageBox is found in -luser32, which is part of w32api. I assume > that w32api > is installed. You can search the MSDN Library to find out which > header and > library files are needed for any Win32 API function. -luser32 is a useful tidbit. I am having trouble getting the linker to use -mwindows, because it gives me an emulation warning and says that only i386pe is allowed. I am able to get i386-mingw32-ld to link if I use this: /usr/local/cross-tools/bin/i386-mingw32-ld -o /Users/zmorris/ Development/Windows/test-xcode/build/Release/test.exe -L/Users/zmorris/ Development/Windows/test-xcode/build/Release -L/usr/local/cross-tools/ lib /Users/zmorris/Development/Windows/test-xcode/build/test.build/ Release/test.build/Objects-normal/i386/main.o /Users/zmorris/ Development/Windows/test-xcode/build/test.build/Release/test.build/ Objects-normal/i386/file2.o --subsystem windows -e _WinMain@16 - luser32 -lddraw The important parts being: --subsystem windows -e _WinMain@16 -luser32 >> I am still not absolutely certain that Xcode is using mingw. The - >> mwindows flag >> should skip the need for main(), and I believe -lmingw32 should >> provide >> MessageBox(). I am still missing something, but this whole process >> seems to >> still be evolving, with several forums on the web offering >> different suggestions. >> > > The -o flag does not belong in 'Other Linker Flags'. I don't think > that it is > necessary to explicitly link to -lmingw32, and it may even be the > problem. You were right about these two, they were making each file.o generated by xcode be 400k. Now they are each under 4k. The last thing I am having issues with is getting i386-mingw32-ld to read xcode's yourapp.exe.LinkFileList. This is just a list of all of the file.o that xcode compiled. I will probably make the ld.pl script read the LinkFileList and pass the lines as one line to i386-mingw32- ld, unless there is a command for mingw that allows you to pass a file containing a list of .o files, like the -filelist option in gcc. Either that or I will add a new build phase. Thanx for all of your help, --Zack |
From: John B. <joh...@ho...> - 2008-03-31 05:22:58
|
Zack Morris wrote: [snip] > -luser32 is a useful tidbit. I am having trouble getting the linker > to use -mwindows, because it gives me an emulation warning and says > that only i386pe is allowed. I am able to get i386-mingw32-ld to link > if I use this: > > /usr/local/cross-tools/bin/i386-mingw32-ld -o /Users/zmorris/ > Development/Windows/test-xcode/build/Release/test.exe -L/Users/zmorris/ > Development/Windows/test-xcode/build/Release -L/usr/local/cross-tools/ > lib /Users/zmorris/Development/Windows/test-xcode/build/test.build/ > Release/test.build/Objects-normal/i386/main.o /Users/zmorris/ > Development/Windows/test-xcode/build/test.build/Release/test.build/ > Objects-normal/i386/file2.o --subsystem windows -e _WinMain@16 - > luser32 -lddraw That should not be necessary, but if it works ... [snip] > > The last thing I am having issues with is getting i386-mingw32-ld to > read xcode's yourapp.exe.LinkFileList. This is just a list of all of > the file.o that xcode compiled. I will probably make the ld.pl script > read the LinkFileList and pass the lines as one line to i386-mingw32- > ld, unless there is a command for mingw that allows you to pass a file > containing a list of .o files, like the -filelist option in gcc. > Either that or I will add a new build phase. > MinGW is is a win32 port of gcc. Whatever gcc options you are used to having should be there. By the way, what is your cross-compiler's gcc version number? _________________________________________________________________ Windows Live Hotmail is giving away Zunes. http://www.windowslive-hotmail.com/ZuneADay/?locale=en-US&ocid=TXT_TAGLM_Mobile_Zune_V3 |
From: <zm...@ma...> - 2008-03-31 14:32:09
|
On Mar 30, 2008, at 11:22 PM, John Brown wrote: > > Zack Morris wrote: > [snip] > >> -luser32 is a useful tidbit. I am having trouble getting the linker >> to use -mwindows, because it gives me an emulation warning and says >> that only i386pe is allowed. I am able to get i386-mingw32-ld to link >> if I use this: >> >> /usr/local/cross-tools/bin/i386-mingw32-ld -o /Users/zmorris/ >> Development/Windows/test-xcode/build/Release/test.exe -L/Users/ >> zmorris/ >> Development/Windows/test-xcode/build/Release -L/usr/local/cross- >> tools/ >> lib /Users/zmorris/Development/Windows/test-xcode/build/test.build/ >> Release/test.build/Objects-normal/i386/main.o /Users/zmorris/ >> Development/Windows/test-xcode/build/test.build/Release/test.build/ >> Objects-normal/i386/file2.o --subsystem windows -e _WinMain@16 - >> luser32 -lddraw > > That should not be necessary, but if it works ... > > [snip] > >> ... > > MinGW is is a win32 port of gcc. Whatever gcc options you are used to > having should be there. By the way, what is your cross-compiler's gcc > version number? Mingw's is: gcc version 3.4.5 (mingw special) Whereas I guess my Leopard gcc is 4.0.1? That could explain some missing options. I have it all working, I just had to use perl to parse yourapp.exe.LinkFileList into an array and then pass all of the files as a string to mingw's ld, and also strip out incompatible options. I'm going to try to clean up the symlinking of gcc->mingw by putting those steps into a new build phase before the compile step I think, and then putting them back after the build finishes. I wish I knew a way to just tell Xcode to use a different compiler, local to each project. --Zack |
From: Brian D. <br...@de...> - 2008-04-04 00:19:33
|
zm...@ma... wrote: > -luser32 is a useful tidbit. I am having trouble getting the linker > to use -mwindows, because it gives me an emulation warning and says > that only i386pe is allowed. I am able to get i386-mingw32-ld to link > if I use this: -mwindows is a gcc flag, not a linker flag. In fact it is just an alias for "-Wl,--subsystem,windows" which means to pass "--subsystem windows" to the linker. Check the gcc specs file. You should be linking by invoking gcc or g++ (or i586-mingw-gcc/g++) not by calling ld directly -- that is almost always a mistake. Also -luser32 is always given implicitly by the specs file so there should never be a need to give it. The specs file takes care of all this for you, that's its function. Brian |