Menu
▾
▴
mingw-w64-public
|
From: Peter M. <pm...@ya...> - 2011-12-28 21:24:01
|
Hi, Iam Peter from the Centauri Project here at Sourceforge and we are also OpenSource (unfortently, iam alone on the Project right now but this is an diffrent story). I hope some one can point me to the right point: I just downloaded Sezeros "mingw-w64-bin_x86_64-mingw_20111101_sezero.zip" from your Downloadsection and everything working very well.Ich can compile 64-Bit Console Appz and simple Makefiles with mingw32-make.exe works also well. Now the Problem: I have installed this Version of the GTK Win64 Devel Package: http://www.gtk.org/download/win64.php (but i really was not able to find out if this Package was build with Visual C/C++ or your Mingw64 64-Bit Compiler (i was not able to find the Infos, but i thin it is a Mingw64 Build, please let me know if iam right or wrong) But anyway, i modifying my Makefile for a dummy test and i was able to figure out the Include part, but not the LDFLAGS Part. There are a lots of *.LIB Files in the X:\GTK64\lib Folder but also Files with names like >> libgdkmm-2.4.dll.a << but i allways getting the following Error if i use gmake: Location: X:\Tmp\gtk2_tests\test1_win64> (UAC is OFF, Windows Vista 64) gmake hello.o:hello.cpp:(.text+0x52): undefined reference to `Glib::ustring::~ustring()' As Result: The Objectfile hello.o was created, but the Exe was not: This is the Code of hello.cpp #include <stdlib.h> #include <stdio.h> #include <iostream> #include <gtkmm.h> <<---- This blank Include produces the Linker Error // if uncomment, the Error disapear. using namespace std; int main() { cout << "test"; getchar(); return(0); } My Question is: How to set LDFLAGS Linker params on MinGW64 correctly? On Linux and Solaris there is no Problem using GCC 4.5 but. I hope some one has an Ideaa. By the Way: VERRY good Project! Greetings Peter |
|
From: JonY <jo...@us...> - 2011-12-28 22:50:50
Attachments:
signature.asc
|
On 12/29/2011 05:23, Peter Meyer wrote: > Hi, > Iam Peter from the Centauri Project here at Sourceforge and we are also > OpenSource (unfortently, iam alone on the Project right now but this > is an diffrent story). > > I hope some one can point me to the right point: > > I just downloaded Sezeros > "mingw-w64-bin_x86_64-mingw_20111101_sezero.zip" from your Downloadsection > and everything working very well.Ich can compile 64-Bit Console Appz and > simple Makefiles with mingw32-make.exe > works also well. > > Now the Problem: > I have installed this Version of the GTK Win64 Devel Package: > http://www.gtk.org/download/win64.php (but i > really was not able to find out if this Package was build with Visual > C/C++ or your Mingw64 64-Bit Compiler (i > was not able to find the Infos, but i thin it is a Mingw64 Build, please > let me know if iam right or wrong) > > But anyway, i modifying my Makefile for a dummy test and i was able to > figure out the Include part, > but not the LDFLAGS Part. There are a lots of *.LIB Files in the > X:\GTK64\lib Folder but also Files with > names like >> libgdkmm-2.4.dll.a << but i allways getting the following > Error if i use gmake: > > Location: > X:\Tmp\gtk2_tests\test1_win64> (UAC is OFF, Windows Vista 64) > > gmake > hello.o:hello.cpp:(.text+0x52): undefined reference to > `Glib::ustring::~ustring()' > > As Result: The Objectfile hello.o was created, but the Exe was not: > > This is the Code of hello.cpp > > > #include <stdlib.h> > #include <stdio.h> > #include <iostream> > #include <gtkmm.h> <<---- This blank Include produces the Linker Error > // if uncomment, the Error disapear. > > using namespace std; > > int main() > { > cout << "test"; > getchar(); > return(0); > } > > My Question is: > How to set LDFLAGS Linker params on MinGW64 correctly? > On Linux and Solaris there is no Problem using GCC 4.5 but. > > I hope some one has an Ideaa. > By the Way: VERRY good Project! > > Greetings Peter LDFLAGS is very much autotools specific (avoid custom Makefiles if possible). Your custom Makefile might not respect LDFLAGS env var. You need to dive in and understand it before being able to edit it correctly. I'm guessing you didn't link to glibmm, or your glibmm install is broken in some way. Look for your hello.exe target link rule and add the proper link libraries. |
|
From: Peter M. <pm...@ya...> - 2011-12-28 23:17:26
|
Hi (and thx for the reply) Am 28.12.2011 23:50, schrieb JonY: > LDFLAGS is very much autotools specific (avoid custom Makefiles if > possible). Your custom Makefile might not respect LDFLAGS env var. You > need to dive in and understand it before being able to edit it > correctly. I'm guessing you didn't link to glibmm, or your glibmm > install is broken in some way. Look for your hello.exe target link > rule and add the proper link libraries. Youre right, i dont use Autotools and i dont use gtk-config Tool to automate things.Iam developing right now on Windows with a Console and an Editor. There is nothing broken, the Includ path in the Makefiles has to be set correctly. For Headers it works, but it cannot find the Libs. For Example: In MS-Visual C/C++ i can add in the Project properties / Linker Section wsock32.lib and the MS Compiler will link against it, but how do i this step in g++ ?? There are no *.LIB Files, so what is the correct File? Should i add *.dll.a Files in the /package/lib/ Folder? Autotools. Is Autotools in the MinGW64 Release included right now (on Win64)? Me and Make. Iam very intrested in understanding the GNU Makesystem and it has alot more of cool Features then QMake or MSBuild and its fun to play with it, but for now i only have to know how the MinGW64 Linker must be prepared for finding the libs on Windows in general and in special from within a Makefile. Greetings Peter |
|
From: JonY <jo...@us...> - 2011-12-29 09:30:51
Attachments:
signature.asc
|
On 12/29/2011 07:17, Peter Meyer wrote: > Hi (and thx for the reply) > > Am 28.12.2011 23:50, schrieb JonY: >> LDFLAGS is very much autotools specific (avoid custom Makefiles if >> possible). Your custom Makefile might not respect LDFLAGS env var. You >> need to dive in and understand it before being able to edit it >> correctly. I'm guessing you didn't link to glibmm, or your glibmm >> install is broken in some way. Look for your hello.exe target link >> rule and add the proper link libraries. > > Youre right, i dont use Autotools and i dont use gtk-config Tool to > automate things.Iam developing right now on Windows with a Console and > an Editor. > There is nothing broken, the Includ path in the Makefiles has to be set > correctly. For Headers it works, but it cannot find the Libs. > > For Example: In MS-Visual C/C++ i can add in the Project properties / > Linker Section wsock32.lib and the MS Compiler will link against it, > but how do i this step in g++ ?? There are no *.LIB Files, so what is > the correct File? Should i add *.dll.a Files in the /package/lib/ Folder? > Autotools. Is Autotools in the MinGW64 Release included right now (on > Win64)? > Oh boy, looks like you skipped some manuals. Use -lfoo to link to libfoo.dll.a, libfoo.a or foo.lib. -L is equivalent to your LIBPATH in MSVC. Please at least look at the GNU GCC and LD manual. Autotools is a shell program to generate configure/makefile.in etc, configure in this case is also a shell script. A base install of Windows will not have anything to run or interpret the shell script, you'll need to install Cygwin, MSYS or Interix. The easiest way to get it all in one place is to use Cygwin and its setup program, simply pick and choose what you want to install, and use the provided mingw-w64 cross compiler to build your program. As for wsock32, it is now relegated to a forwarder DLL to ws2_32.dll, it is strange use wsock32 deliberately these days. It might have problems with some newer WINSOCK API versions, but I'm not sure of this. > Me and Make. Iam very intrested in understanding the GNU Makesystem and > it has alot more of cool Features then QMake or > MSBuild and its fun to play with it, but for now i only have to know how > the MinGW64 Linker must be prepared for finding the > libs on Windows in general and in special from within a Makefile. > I wouldn't say autotools is the perfect solution for everything, but it is the very best if you are looking for platform portability, especially when you start dealing with shared libraries. Afaik, the sanctioned way to ask for gtkmm library flags is to query it from pkg-config. You'll probably need to work that into your makefile somehow |
|
From: Peter M. <pm...@ya...> - 2011-12-29 11:51:52
|
Hi Am 29.12.2011 10:30, schrieb JonY: > Oh boy, looks like you skipped some manuals. Thadt might be true, but i allways struggle to find the correct manuals. I Google all the time but it is verry hard for me to find the hardfacts. Of cause, there are lots of Informations out there, but if you have a specific question like linking a non standard Linux/Unix Compiler on a special Windows Versio (Vista) with all the hassle, its not thadt eas: In my opinion there must be a think like "-lfoo to link to libfoo.dll.a," and it was. > Please at least look at the GNU GCC and LD manual. It sounds stupid but can you give me a link to the Manual and Books thadt you are using? I google a lot but i allways find some basic stuff. On FreeBSD the docs are a dream, but on Linux sometimes it depresses me. > Autotools is a shell program to generate configure/makefile.in etc, > configure in this case is also a shell script. A base install of > Windows will not have anything to run or interpret the shell script, > you'll need to install Cygwin, MSYS or Interix. The easiest way to get > it all in one place is to use Cygwin and its setup program, simply > pick and choose I know Cygwin but the last time i was looking at it, there was no plans off 64-Bit on Windows and other things simply doesent work. > As for wsock32, it is now relegated to a forwarder DLL to ws2_32.dll, > it is strange use wsock32 deliberately these days. It might have > problems with some newer WINSOCK API versions, but I'm not sure of this. wsock32.lib was an example, there is no Project where iam using this lib. >> Me and Make. Iam very intrested in understanding the GNU Makesystem and >> it has alot more of cool Features then QMake or >> MSBuild and its fun to play with it, but for now i only have to know how >> the MinGW64 Linker must be prepared for finding the >> libs on Windows in general and in special from within a Makefile. >> > I wouldn't say autotools is the perfect solution for everything, but it > is the very best if you are looking for platform portability, especially > when you start dealing with shared libraries. Iam the Setup Guy and i have no shy to create Setup.exes (now *.msi) MacOSX DMG's, Redhat RPM's, Debian DEB's and Solaris ICS Packages as well. On Linux (with KDevelop or Anjunta) Autotools would my choice, but i must work on Mac, Solaris, Windows and FreeBSD and i think, if i only use the GCC / G++ then pure Makefiles are my best Friends, but you are right, i will use GTK's pkg-config and this was the real Problem i was had. Thx for the help Best regards, Peter |
|
From: Kai T. <kti...@go...> - 2011-12-29 13:19:15
|
Hi Peter, if you want that your replies getting unmanaged to this ML, then I kindly ask you to subscribe to ML. Otherwise it might happen, that your mails getting stuck there for some time, before a ML-manager manually approves them. You can subscribe to the ML via the link provided at http://sourceforge.net/mail/?group_id=202880 Regards, Kai 2011/12/29 Peter Meyer <pm...@ya...>: > Hi > > Am 29.12.2011 10:30, schrieb JonY: >> Oh boy, looks like you skipped some manuals. > > Thadt might be true, but i allways struggle to find the correct manuals. > I Google all the time but it is verry > hard for me to find the hardfacts. Of cause, there are lots of > Informations out there, but if you have a specific > question like linking a non standard Linux/Unix Compiler on a special > Windows Versio (Vista) with all the hassle, > its not thadt eas: In my opinion there must be a think like "-lfoo to > link to libfoo.dll.a," and it was. > >> Please at least look at the GNU GCC and LD manual. > It sounds stupid but can you give me a link to the Manual and Books > thadt you are using? > I google a lot but i allways find some basic stuff. On FreeBSD the docs > are a dream, but on Linux sometimes it > depresses me. > > >> Autotools is a shell program to generate configure/makefile.in etc, >> configure in this case is also a shell script. A base install of >> Windows will not have anything to run or interpret the shell script, >> you'll need to install Cygwin, MSYS or Interix. The easiest way to get >> it all in one place is to use Cygwin and its setup program, simply >> pick and choose > > I know Cygwin but the last time i was looking at it, there was no plans > off 64-Bit on Windows and other things simply doesent > work. > >> As for wsock32, it is now relegated to a forwarder DLL to ws2_32.dll, >> it is strange use wsock32 deliberately these days. It might have >> problems with some newer WINSOCK API versions, but I'm not sure of this. > > wsock32.lib was an example, there is no Project where iam using this lib. > >>> Me and Make. Iam very intrested in understanding the GNU Makesystem and >>> it has alot more of cool Features then QMake or >>> MSBuild and its fun to play with it, but for now i only have to know how >>> the MinGW64 Linker must be prepared for finding the >>> libs on Windows in general and in special from within a Makefile. >>> >> I wouldn't say autotools is the perfect solution for everything, but it >> is the very best if you are looking for platform portability, especially >> when you start dealing with shared libraries. > > Iam the Setup Guy and i have no shy to create Setup.exes (now *.msi) > MacOSX DMG's, Redhat RPM's, Debian DEB's and Solaris ICS > Packages as well. On Linux (with KDevelop or Anjunta) Autotools would > my choice, but i must work on Mac, Solaris, Windows and > FreeBSD and i think, if i only use the GCC / G++ then pure Makefiles are > my best Friends, but you are right, i will use GTK's pkg-config > and this was the real Problem i was had. > > Thx for the help > Best regards, Peter > > > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
|
From: Peter M. <pm...@ya...> - 2011-12-29 13:28:51
|
Hi Kai, Hmm thadts sounds strange, because i have subscribed the Mailinglist and in my Inbox was the Welcome message: <snip> Welcome to the...@li... mailing list! To post to this list, send your email to: min...@li... General information about the mailing list is at: https://lists.sourceforge.net/lists/listinfo/mingw-w64-public If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://lists.sourceforge.net/lists/options/mingw-w64-public/pmvstrm%40users.sourceforge.net You can also make such adjustments via email by sending a message to: Min...@li... with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: </snip> Greetings, Peter |
|
From: Kai T. <kti...@go...> - 2011-12-29 13:32:59
|
Hmm, indeed strange. I subscribed you via adminstrative tool now. Regards, Kai |
|
From: JonY <jo...@us...> - 2011-12-29 14:07:39
Attachments:
signature.asc
|
On 12/29/2011 19:51, Peter Meyer wrote: > Hi > > Am 29.12.2011 10:30, schrieb JonY: >> Oh boy, looks like you skipped some manuals. > > Thadt might be true, but i allways struggle to find the correct manuals. > I Google all the time but it is verry > hard for me to find the hardfacts. Of cause, there are lots of > Informations out there, but if you have a specific > question like linking a non standard Linux/Unix Compiler on a special > Windows Versio (Vista) with all the hassle, > its not thadt eas: In my opinion there must be a think like "-lfoo to > link to libfoo.dll.a," and it was. > >> Please at least look at the GNU GCC and LD manual. > It sounds stupid but can you give me a link to the Manual and Books > thadt you are using? > I google a lot but i allways find some basic stuff. On FreeBSD the docs > are a dream, but on Linux sometimes it > depresses me. > > SeeGNU GCC Manual at <http://gcc.gnu.org/onlinedocs/>, likewise for binutils, <http://sourceware.org/binutils/docs-2.22/>. >> Autotools is a shell program to generate configure/makefile.in etc, >> configure in this case is also a shell script. A base install of >> Windows will not have anything to run or interpret the shell script, >> you'll need to install Cygwin, MSYS or Interix. The easiest way to get >> it all in one place is to use Cygwin and its setup program, simply >> pick and choose > > I know Cygwin but the last time i was looking at it, there was no plans > off 64-Bit on Windows and other things simply doesent > work. > I'm using it now, never had any major issues with it. autotools/mingw-w64 is all in there already. >> As for wsock32, it is now relegated to a forwarder DLL to ws2_32.dll, >> it is strange use wsock32 deliberately these days. It might have >> problems with some newer WINSOCK API versions, but I'm not sure of this. > > wsock32.lib was an example, there is no Project where iam using this lib. > >>> Me and Make. Iam very intrested in understanding the GNU Makesystem and >>> it has alot more of cool Features then QMake or >>> MSBuild and its fun to play with it, but for now i only have to know how >>> the MinGW64 Linker must be prepared for finding the >>> libs on Windows in general and in special from within a Makefile. >>> >> I wouldn't say autotools is the perfect solution for everything, but it >> is the very best if you are looking for platform portability, especially >> when you start dealing with shared libraries. > > Iam the Setup Guy and i have no shy to create Setup.exes (now *.msi) > MacOSX DMG's, Redhat RPM's, Debian DEB's and Solaris ICS > Packages as well. On Linux (with KDevelop or Anjunta) Autotools would > my choice, but i must work on Mac, Solaris, Windows and > FreeBSD and i think, if i only use the GCC / G++ then pure Makefiles are > my best Friends, but you are right, i will use GTK's pkg-config > and this was the real Problem i was had. > /off topic rant Most custom Makefiles cannot handle systems that are different from the developer's, requiring manual editing to fix it. This gets very tedious when you keep running into them over and over. Did I mention different authors have different naming conventions and styles? Do you set CFLAGS? COMPLE_FLAGS? OPTIMIZATION_FLAGS? So many combinations, you have to dig through and understand all of it, they may have also done silly things like assuming you are on their platform of choice, like leaving shared libraries partially linked or using "ld" directly. Mac, Solaris and FreeBSD already have a shell interpreter, not sure why you want to use custom Makefiles there. For Windows, please do not use custom Makefiles, ever, it makes your code hard to cross compile, so stop. doing. that. Most custom Makefiles also can't handle out of tree builds, why should I need to pollute my source directory when I can just rm * to clean things? BTW, did you remember handle pkg-config in cross compile scenarios? IMHO, setup.exe files are a curse of Windows software, held over from the Win95 days, they are very opaque, you have no idea what they are doing when you give them admin privileges to "install", are they even doing that? MSI files are slightly better, they have administrative installs. Just use 7z, zip or rar. In conclusion, too many developers think their libs/apps should use only simple Makefiles. Too many released binaries with stupid huge overkill setup.exes that only extracts and installs a few files when a zip will do. There, end of rant. |
|
From: Peter M. <pm...@ya...> - 2011-12-29 14:42:55
|
> /off topic rant > > Most custom Makefiles cannot handle systems that are different from the > developer's, requiring manual editing to fix it. This gets very tedious > when you keep running into them over and over. Thadt are the problems you have to deal with it, but thadts no Problem, if you allways have a bunch of vmware Images so you can test check the git checkouts. > Did I mention different authors have different naming conventions and > styles? Do you set CFLAGS? COMPLE_FLAGS? OPTIMIZATION_FLAGS? So many I do not agree.In reality, there are only a few things you must check (for example: if Arch type is only x86 and x86_64) , maybe a bit more if you use profile guided optimization e.c.t. > Mac, Solaris and FreeBSD already have a shell interpreter, not sure why / rant on In reality they have diffrent interpreters. Some having bash and you cannot simply change it (espacially on Mac, the bash is needed for internal OS puporses) and shared libs often are builded as framework ant not simply as shared or static type. You also have to binary patch executables and shared object so you can create a setup dmg File to provide a setup download. and in Solaris, there has a LOT changed the last two years. a complet new Packaging system was integrated in (called ICS) wich used the scm system bazar. In the wild, if you have a fresh installed Solaris System you even dont have access to gcc or binutils and the expected main Compiler is SUN C/C++ and on older Solaris Versions you have to deal with Blastwave as thirdparty packaging system. Bottom line: the Operatingsystems are not 100% equal and assumptions or automated, generated tasks can be terrible wrong and its hard to figure out what tools (for example: qmake) do. QMake for example has an intermediate compiler called moc, thadt does things like autotools and after this generates standard GNU Makefiles, but if moc has a Problem, then ýou lost and take a look in the autognerated makefiles to find out whats going wrong /rant off Thadts only my two cents on this. Thx for the doc links and happy new year, Greetings, Peter |
|
From: JonY <jo...@us...> - 2011-12-29 15:59:42
Attachments:
signature.asc
|
On 12/29/2011 22:42, Peter Meyer wrote: >> /off topic rant >> >> Most custom Makefiles cannot handle systems that are different from the >> developer's, requiring manual editing to fix it. This gets very tedious >> when you keep running into them over and over. > > Thadt are the problems you have to deal with it, but thadts no Problem, > if you allways > have a bunch of vmware Images so you can test check the git checkouts. > > That is fine and dandy if you have access to said platform and they run at reasonable performance. Now, try that again when porting code to small non-x86 platforms. I guess you don't mind building the GCC on your phone or prototyping board. >> Did I mention different authors have different naming conventions and >> styles? Do you set CFLAGS? COMPLE_FLAGS? OPTIMIZATION_FLAGS? So many > > I do not agree.In reality, there are only a few things you must check > (for example: if Arch type > is only x86 and x86_64) , maybe a bit more if you use profile guided > optimization e.c.t. > > CFLAGS are not only used for optimizations. So how do I tell from the CPU type if I should use ELF or PE semantics? Where do I put my compiler flags to do some security hardening or custom linker scripts? How do I make compiler use non-default libdir/headers dir? >> Mac, Solaris and FreeBSD already have a shell interpreter, not sure why > / rant on > > In reality they have diffrent interpreters. Some having bash and you > cannot simply > change it (espacially on Mac, the bash is needed for internal OS > puporses) and shared > libs often are builded as framework ant not simply as shared or static > type. You also > have to binary patch executables and shared object so you can create a > setup dmg > File to provide a setup download. and in Solaris, there has a LOT > changed the last > two years. a complet new Packaging system was integrated in (called ICS) > wich > used the scm system bazar. In the wild, if you have a fresh installed > Solaris System > you even dont have access to gcc or binutils and the expected main Compiler > is SUN C/C++ and on older Solaris Versions you have to deal with Blastwave > as thirdparty packaging system. > Autotools already know about those non-gcc compilers, bash isn't a requirement for autotools. I'm sure its able to check the BUILD OS capabilities. Whereas qmake requires you to have some parts of QT installed, cmake needs cmake, both not as common as the basic sh shell. I don't know about how DMG installs go, but I'm sure you can take a peek inside without actually running it first. OSX framework bundling is simply another step in automake, its not hard after you understand the MACH-O manual, or just use libtool to do it for you. > Bottom line: the Operatingsystems are not 100% equal and assumptions or > automated, > generated tasks can be terrible wrong and its hard to figure out what > tools (for example: > qmake) do. QMake for example has an intermediate compiler called moc, > thadt does > things like autotools and after this generates standard GNU Makefiles, > but if moc > has a Problem, then ýou lost and take a look in the autognerated > makefiles to find > out whats going wrong autotools has config.log. Automated buildsystems are still more convenient than those that require special attention on every different platform. Using custom makefiles will only make it worst, since you now have a dozen other authors with their own handcrafted buildsystems to compete with. |
|
From: Peter M. <pm...@ya...> - 2011-12-29 16:24:50
|
29.12.2011 16:59, schrieb JonY: > autotools has config.log. Automated buildsystems are still more > convenient than those that require special attention on every > different platform. Using custom makefiles will only make it worst, > since you now have a dozen other authors with their own handcrafted > buildsystems to compete with. You maybe right. I think i will give Cygwin another try to take advantage of autobuild. Greetings, Peter |
|
From: Peter M. <pm...@ya...> - 2011-12-29 21:08:15
|
Hi again, After ours of trial and error i will give some feedback and share my results (maybe it is usefull for anyone out there, finding this on the list archiv via Google (Date of writing is: 12/29/2011). Ok, Cygwin 1.7.x worked at compilation level, but if you wish to run the GTK Gnome2 App on Win you need more thand 42 Cygwin DLL's and the Cygwin X11-Server or the Program stops simply with the messeage it thadt cannot find display 0:0 Just for fun i was trying to Install Cygwin x11 xfree server and run my test Program in it and it works, but the Taskmanager shows thadt my X11 Test GTK Programm was on a 32* (32-Bit) Process. It runs but this suckz and i go not further this direction. I found a easier Solution outside from Cygwin.I was able to find a way how gmake and pkg-config works seamles side by side and get my little Testprogram working on Windows Vista 7 64-Bit. It just shows a little GTK2 Widget Mainwindow, but it works as expected (HINT: My Testprgrogramm was C++ NOT C, so C might work, but i only tested the official gtkmm C++ Wrapper! Downloads you need: gtkmm-win64-devel-2.22.0-2.exe http://ftp.gnome.org/Public/gnome/binaries/win64/gtkmm/2.22/ mingw-w64-bin_x86_64-mingw_20111101_sezero.zip http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_4.5_20111101/ Used Utilities: A Windows/Dos Console and an Texteditor, the builded Program is an Win64 GTK2.22 GUI-Executable. You only need this two files: The Makefile: mymake.mak PROGRAM = test CC=g++ LDLIBS= $(shell pkg-config gtkmm-2.4 --libs) CFLAGS=-Wall -g $(shell pkg-config gtkmm-2.4 --cflags) OBJS = gtkmmtest.o #other_objects.o gtkmmtest: $(OBJS) $(CC) $(OBJS) $(LDLIBS) -o gtkTest gtkmmtest.o: gtkmmtest.cc $(CC) $(CFLAGS) -c gtkmmtest.cc clean: rm -f *.o The simple C++ Testprogramm (NOT C !!) Filename: gtkmmtest.cc #include <gtkmm.h> int main(int argc, char *argv[]) { Gtk::Main kit(argc, argv); Gtk::Window window; kit.run(window); return 0; } gmake -f mymake.mak As result you get "gtkTest.exe" (172 KBytes) This Files you need in an independant Setup.exe / MSI-Installer for Binary distribution: 175.547 gtkTest.exe 104.448 libatk-1.0-0.dll 456.704 libatkmm-1.6-1.dll 953.344 libcairo-2.dll 868.352 libcairomm-1.0-1.dll 152.576 libexpat-1.dll 193.024 libfontconfig-1.dll 484.352 libfreetype-6.dll 77.312 libgcc_s_sjlj-1.dll 1.099.771 libgdk-win32-2.0-0.dll 488.448 libgdkmm-2.4-1.dll 199.168 libgdk_pixbuf-2.0-0.dll 811.520 libgio-2.0-0.dll 996.864 libgiomm-2.4-1.dll 1.267.577 libglib-2.0-0.dll 1.183.744 libglibmm-2.4-1.dll 19.968 libgmodule-2.0-0.dll 258.560 libgobject-2.0-0.dll 24.576 libgthread-2.0-0.dll 5.207.359 libgtk-win32-2.0-0.dll 4.502.528 libgtkmm-2.4-1.dll 240.862 libintl-8.dll 252.928 libpango-1.0-0.dll 48.640 libpangocairo-1.0-0.dll 207.360 libpangoft2-1.0-0.dll 280.576 libpangomm-1.4-1.dll 60.928 libpangowin32-1.0-0.dll 145.408 libpng14-14.dll 705.536 libsigc-2.0-0.dll 980.480 libstdc++-6.dll 191.825 zlib1.dll 21 Files, 21 MBytes (7 MBytes in a compressed Zipfile) Tested on Windows 8 64-Bit (Oracle VirtualBox 4.1) Ok, thadts it. The next step for me, is a crosstarget build for Win64 and Win32 so i can produce a 32-Bit and 64-Bit MSI Installer (with the free OpenSource Windows Installer XML Toolkit from Sourceforge from Microsoft) for automated MSI Setups generation. Greetings, Peter |
|
From: JonY <jo...@us...> - 2011-12-29 22:02:49
Attachments:
signature.asc
|
On 12/30/2011 05:07, Peter Meyer wrote: > Hi again, > > After ours of trial and error i will give some feedback and share my > results (maybe it is usefull for > anyone out there, finding this on the list archiv via Google (Date of > writing is: 12/29/2011). > > Ok, Cygwin 1.7.x worked at compilation level, but if you wish to run the > GTK Gnome2 App on Win > you need more thand 42 Cygwin DLL's and the Cygwin X11-Server or the > Program stops simply with the messeage > it thadt cannot find display 0:0 Just for fun i was trying to Install > Cygwin x11 xfree server and run my test Program > in it and it works, but the Taskmanager shows thadt my X11 Test GTK > Programm was on a 32* (32-Bit) Process. > It runs but this suckz and i go not further this direction. > You should be cross compiling for windows, you don't need X11 or any Cygwin GTK DLLs. If you do, you're doing it wrong somewhere. |
|
From: Peter M. <pm...@ya...> - 2011-12-30 00:25:48
|
JonY:
> You should be cross compiling for windows, you don't need X11 or any
> Cygwin GTK DLLs. If you do, you're doing it wrong somewhere.
Can you explain this a bit more precise?
if you compile this Program base.c
#include <gtk/gtk.h>
int main( int argc, char *argv[] )
{
GtkWidget *window;
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_show (window);
gtk_main ();
return 0;
}
using:
$ gcc base.c -Wall -o base `pkg-config --cflags --libs gtk+-2.0`
As described in the Basic Gnome GTK Tutorial from
http://www.gtk.org/tutorial1.2/gtk_tut-2.html
at the Cygwin prompt / console (installed with complete Gnome Options,
with all postinstall tasksare flawless running correctly) the programm
will build and link without Errors. But if you try to start it in the
Cygwin Console ./base.exe yout geht this Message: (base:3460):
Gtk-WARNING **: cannot open display: and the programm aborts.
Otherwise if you select in the Cygwin Installer the X11 Setup Options (
XServer stuff) you can start X11 with the command "startx" at the Cygwin
Shell, a new Windows Window apears and a minimalistic twm Window
Manageris showing (you can also install KDE or Gnome Desktop) but twm is
ok for testing. The in an xterminal under X11
you can run the Program using the command ./base.exe and it will
start.Outside Cygwin you have not chance to do this, you need X11, i
have tested it or you get stuck on the (base:3460): Gtk-WARNING **:
cannot open display: But if i install the normal Mingw and tweaking it
a little bit, you can use GTK, without Cygwin and without X11 and cannot
open Display message.
I just finished the crossbuild 32/64-Bit Windows targeting task and
tested it successfully on diffrent Windows Versions in some Virtual
Machines (VMware7) The Win64 Build does not run on Windows XP 32-Bit (ok
thadt was clear, but i tested to make sure it is a real 64-Bit) The
Mingw32 Build (is used your
mingw-w32-bin_i686-mingw_20111101_sezero.zip personal build from Sezero)
i was able to make a good 32-Bit build (wich runs on Windows XP and the
64-Bit Windows as well (like the
Win64 build, the same list of shared redist DLL's has to be placed in
the Exe Folder side by side).
I just tested the 32-Bit build on Windows 2000 32-Biz SP4 with latest
patches but there is an Error:"Entry Point Not Found The procedure entry
point ___lc_codepage_func could not be located in the dynamic linl
library msvcrt.dll" I just investigating this problem right now.
Greetings Peter
|
|
From: JonY <jo...@us...> - 2011-12-30 09:07:07
Attachments:
signature.asc
|
On 12/30/2011 08:25, Peter Meyer wrote:
> JonY:
>> You should be cross compiling for windows, you don't need X11 or any
>> Cygwin GTK DLLs. If you do, you're doing it wrong somewhere.
> Can you explain this a bit more precise?
>
> if you compile this Program base.c
>
> #include <gtk/gtk.h>
> int main( int argc, char *argv[] )
> {
> GtkWidget *window;
> gtk_init (&argc, &argv);
> window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
> gtk_widget_show (window);
> gtk_main ();
> return 0;
> }
>
> using:
> $ gcc base.c -Wall -o base `pkg-config --cflags --libs gtk+-2.0`
>
You are using "gcc" to compile for Cygwin, your pkg-config command will
also pull in Cygwin libraries, so it is expected X11 will be involved.
The cross compiler is normally x86_64-w64-mingw32-gcc or
i686-w64-mingw32-gcc or some such variant.
You should be recompiling GTK for win32 also, you can't use native
libraries when cross compiling. You may also want to build a specially
modified pkg-config for cross compiles, eg i686-w64-mingw32-pkg-config
that points to your special PKG_CONFIG_PATH for your Win32 GTK libraries.
Cross compile GTK and its dependencies with --build=i686-pc-cygwin
--host=i686-w64-mingw32 --prefix=...., use x86_64-w64-mingw32 for win64.
> As described in the Basic Gnome GTK Tutorial from
> http://www.gtk.org/tutorial1.2/gtk_tut-2.html
>
> at the Cygwin prompt / console (installed with complete Gnome Options,
> with all postinstall tasksare flawless running correctly) the programm
> will build and link without Errors. But if you try to start it in the
> Cygwin Console ./base.exe yout geht this Message: (base:3460):
> Gtk-WARNING **: cannot open display: and the programm aborts.
> Otherwise if you select in the Cygwin Installer the X11 Setup Options (
> XServer stuff) you can start X11 with the command "startx" at the Cygwin
> Shell, a new Windows Window apears and a minimalistic twm Window
> Manageris showing (you can also install KDE or Gnome Desktop) but twm is
> ok for testing. The in an xterminal under X11
> you can run the Program using the command ./base.exe and it will
> start.Outside Cygwin you have not chance to do this, you need X11, i
> have tested it or you get stuck on the (base:3460): Gtk-WARNING **:
> cannot open display: But if i install the normal Mingw and tweaking it
> a little bit, you can use GTK, without Cygwin and without X11 and cannot
> open Display message.
>
Ditto, you mixed Cygwin with non-Cygwin, don't do that, cross compile
all the dependencies as well.
> I just finished the crossbuild 32/64-Bit Windows targeting task and
> tested it successfully on diffrent Windows Versions in some Virtual
> Machines (VMware7) The Win64 Build does not run on Windows XP 32-Bit (ok
> thadt was clear, but i tested to make sure it is a real 64-Bit) The
> Mingw32 Build (is used your
> mingw-w32-bin_i686-mingw_20111101_sezero.zip personal build from Sezero)
> i was able to make a good 32-Bit build (wich runs on Windows XP and the
> 64-Bit Windows as well (like the
> Win64 build, the same list of shared redist DLL's has to be placed in
> the Exe Folder side by side).
>
> I just tested the 32-Bit build on Windows 2000 32-Biz SP4 with latest
> patches but there is an Error:"Entry Point Not Found The procedure entry
> point ___lc_codepage_func could not be located in the dynamic linl
> library msvcrt.dll" I just investigating this problem right now.
>
This is a problem with the older toolchains, it has been fixed some time
ago, you may need to update your mingw-w64 install and/or recompile your
code. IIRC this problem plagues early XP SP0 and Win2K (Win2K isn't
exactly supported by mingw-w64, so anything goes).
|
|
From: Peter M. <pm...@ya...> - 2011-12-30 10:14:47
|
Am 30.12.2011 10:06, schrieb JonY: > You should be recompiling GTK for win32 also, you can't use native > libraries when cross compiling. You may also want to build a specially > modified pkg-config for cross compiles, eg i686-w64-mingw32-pkg-config > that points to your special PKG_CONFIG_PATH for your Win32 GTK libraries. Sorry, but i dont do thadt.I have a solution on Win64 and Win32-Systems and thadt works. On Linux/Unix this is an diffrent story but not on Microsot Windows . Windows is not an posix System and it will never.I on Windows the best Solution is using Cmake and avoid posix only things Cygwin at all. CMake works fine and is real Crossplatform and 10.000 times faster than the ugly autotool stuff ;D > Ditto, you mixed Cygwin with non-Cygwin, don't do that, cross compile > all the dependencies as well. Again, thanks but no thanks.If i can, then i use GCC/G++ but if this is not possible, i have to target Visual C/C/++ or SUN/Oracles C/C++ Compiler as well. > I just tested the 32-Bit build on Windows 2000 32-Biz SP4 with latest > patches but there is an Error:"Entry Point Not Found The procedure entry > point ___lc_codepage_func could not be located in the dynamic linl > library msvcrt.dll" I just investigating this problem right now. > > This is a problem with the older toolchains, it has been fixed some time > ago, you may need to update your mingw-w64 install and/or recompile your > code. IIRC this problem plagues early XP SP0 and Win2K (Win2K isn't > exactly supported by mingw-w64, so anything goes). Hmm, i read a diffrent post from Kai Tiez [quote]mingw-w64 does not support Windows OSes below XP officially.[/quote] http://sourceforge.net/support/tracker.php?aid=3382873 This explain a lot to me.Ok, if i want, i could built mingw64, GTK, Boost and anythin i needed from scratch, but this is an oververhead and like Kai explains: "This may work, but it is not officially supported". So i think i will compile my Projects on Win x64 with mingw64 4.5.x and on Win32 with MinGW 4.5.x wich runs out of the box on Win2000 Systems up to Win8 on Win32 Targets (i have used it in an QT4Project and it works flawless) On top of this i will use Cmake, it was build for Crossplatform and Cross Compiler builts and it is 10.000 times faster than the ugly Autotools ;D Greetings, Peter |
|
From: JonY <jo...@us...> - 2011-12-30 10:57:24
Attachments:
signature.asc
|
On 12/30/2011 18:14, Peter Meyer wrote: > Am 30.12.2011 10:06, schrieb JonY: >> You should be recompiling GTK for win32 also, you can't use native >> libraries when cross compiling. You may also want to build a specially >> modified pkg-config for cross compiles, eg i686-w64-mingw32-pkg-config >> that points to your special PKG_CONFIG_PATH for your Win32 GTK libraries. > Sorry, but i dont do thadt.I have a solution on Win64 and Win32-Systems > and thadt works. On Linux/Unix this is an diffrent story but not on > Microsot Windows . > Windows is not an posix System and it will never.I on Windows the best > Solution is using Cmake and avoid posix only things Cygwin at all. CMake > works fine and is real Crossplatform and 10.000 times faster than the > ugly autotool stuff ;D This is already a solved problem, made into a big issue with your insistence to use custom makefiles and failing to understand the basics of using a cross compiler. If only you took some initiative to understand what you are actually doing, you won't run into any issues, cmake or not. I don't understand why you are making this difficult for yourself. >> Ditto, you mixed Cygwin with non-Cygwin, don't do that, cross compile >> all the dependencies as well. > Again, thanks but no thanks.If i can, then i use GCC/G++ but if this is > not possible, i have to target Visual C/C/++ or > SUN/Oracles C/C++ Compiler as well. Likewise, autotools already handles that nicely. It even knows about MSVC already. Good luck maintaining multiple build systems that all need to be updated to accommodate different scenarios. >> I just tested the 32-Bit build on Windows 2000 32-Biz SP4 with latest >> patches but there is an Error:"Entry Point Not Found The procedure entry >> point ___lc_codepage_func could not be located in the dynamic linl >> library msvcrt.dll" I just investigating this problem right now. >> >> This is a problem with the older toolchains, it has been fixed some time >> ago, you may need to update your mingw-w64 install and/or recompile your >> code. IIRC this problem plagues early XP SP0 and Win2K (Win2K isn't >> exactly supported by mingw-w64, so anything goes). > Hmm, i read a diffrent post from Kai Tiez > > [quote]mingw-w64 does not support Windows OSes below XP officially.[/quote] > http://sourceforge.net/support/tracker.php?aid=3382873 > > This explain a lot to me.Ok, if i want, i could built mingw64, GTK, > Boost and anythin i needed from scratch, but this is an oververhead and > like Kai explains: "This may work, but it is not officially supported". > So i think i will compile my Projects on Win x64 with mingw64 4.5.x > and on Win32 with MinGW 4.5.x wich runs out of the box on Win2000 > Systems up to Win8 on Win32 Targets (i have used it in an QT4Project and > it works flawless) On top of this i will use Cmake, it was build for > Crossplatform and Cross Compiler > builts and it is 10.000 times faster than the ugly Autotools ;D > I guess you can't tell the difference between a compiler host, target system, C Runtime and a buildsystem, you managed to mangle them all together. Try again next time. |
|
From: Peter M. <pm...@ya...> - 2011-12-30 11:39:48
|
Sorry if you feel angry and not all person in the world having the same views like you. There is no Problem and nothing needs to solve - what you talking about? Am 30.12.2011 11:57, schrieb JonY: > On 12/30/2011 18:14, Peter Meyer wrote: >> Am 30.12.2011 10:06, schrieb JonY: >>> You should be recompiling GTK for win32 also, you can't use native >>> libraries when cross compiling. You may also want to build a specially >>> modified pkg-config for cross compiles, eg i686-w64-mingw32-pkg-config >>> that points to your special PKG_CONFIG_PATH for your Win32 GTK libraries. >> Sorry, but i dont do thadt.I have a solution on Win64 and Win32-Systems >> and thadt works. On Linux/Unix this is an diffrent story but not on >> Microsot Windows . >> Windows is not an posix System and it will never.I on Windows the best >> Solution is using Cmake and avoid posix only things Cygwin at all. CMake >> works fine and is real Crossplatform and 10.000 times faster than the >> ugly autotool stuff ;D > This is already a solved problem, made into a big issue with your > insistence to use custom makefiles and failing to understand the basics > of using a cross compiler. If only you took some initiative to > understand what you are actually doing, you won't run into any issues, > cmake or not. I don't understand why you are making this difficult for > yourself. > >>> Ditto, you mixed Cygwin with non-Cygwin, don't do that, cross compile >>> all the dependencies as well. >> Again, thanks but no thanks.If i can, then i use GCC/G++ but if this is >> not possible, i have to target Visual C/C/++ or >> SUN/Oracles C/C++ Compiler as well. > Likewise, autotools already handles that nicely. It even knows about > MSVC already. Good luck maintaining multiple build systems that all need > to be updated to accommodate different scenarios. > >>> I just tested the 32-Bit build on Windows 2000 32-Biz SP4 with latest >>> patches but there is an Error:"Entry Point Not Found The procedure entry >>> point ___lc_codepage_func could not be located in the dynamic linl >>> library msvcrt.dll" I just investigating this problem right now. >>> >>> This is a problem with the older toolchains, it has been fixed some time >>> ago, you may need to update your mingw-w64 install and/or recompile your >>> code. IIRC this problem plagues early XP SP0 and Win2K (Win2K isn't >>> exactly supported by mingw-w64, so anything goes). >> Hmm, i read a diffrent post from Kai Tiez >> >> [quote]mingw-w64 does not support Windows OSes below XP officially.[/quote] >> http://sourceforge.net/support/tracker.php?aid=3382873 >> >> This explain a lot to me.Ok, if i want, i could built mingw64, GTK, >> Boost and anythin i needed from scratch, but this is an oververhead and >> like Kai explains: "This may work, but it is not officially supported". >> So i think i will compile my Projects on Win x64 with mingw64 4.5.x >> and on Win32 with MinGW 4.5.x wich runs out of the box on Win2000 >> Systems up to Win8 on Win32 Targets (i have used it in an QT4Project and >> it works flawless) On top of this i will use Cmake, it was build for >> Crossplatform and Cross Compiler >> builts and it is 10.000 times faster than the ugly Autotools ;D >> > I guess you can't tell the difference between a compiler host, target > system, C Runtime and a buildsystem, you managed to mangle them all > together. Try again next time. > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > > > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public |
|
From: Kai T. <kti...@go...> - 2011-12-30 11:56:03
|
Peter, if you like cmake more, feel confortable. I know about some points autotools can easily get a mess. In general it works nice, but if trouble occured by it, then it gets sometimes pretty hairy. For compiling via autotools on cygwin, I think you didn't specified on configure the option --host=x86_64-w64-mingw32. At least I assume so, but well, if you have a working makefile, it is fine too. Happy new year, Kai 2011/12/30 Peter Meyer <pm...@ya...>: > Sorry if you feel angry and not all person in the world having the same > views like > you. There is no Problem and nothing needs to solve - what you talking > about? > > > Am 30.12.2011 11:57, schrieb JonY: > > On 12/30/2011 18:14, Peter Meyer wrote: > > Am 30.12.2011 10:06, schrieb JonY: > > You should be recompiling GTK for win32 also, you can't use native > libraries when cross compiling. You may also want to build a specially > modified pkg-config for cross compiles, eg i686-w64-mingw32-pkg-config > that points to your special PKG_CONFIG_PATH for your Win32 GTK libraries. > > Sorry, but i dont do thadt.I have a solution on Win64 and Win32-Systems > and thadt works. On Linux/Unix this is an diffrent story but not on > Microsot Windows . > Windows is not an posix System and it will never.I on Windows the best > Solution is using Cmake and avoid posix only things Cygwin at all. CMake > works fine and is real Crossplatform and 10.000 times faster than the > ugly autotool stuff ;D > > This is already a solved problem, made into a big issue with your > insistence to use custom makefiles and failing to understand the basics > of using a cross compiler. If only you took some initiative to > understand what you are actually doing, you won't run into any issues, > cmake or not. I don't understand why you are making this difficult for > yourself. > > Ditto, you mixed Cygwin with non-Cygwin, don't do that, cross compile > all the dependencies as well. > > Again, thanks but no thanks.If i can, then i use GCC/G++ but if this is > not possible, i have to target Visual C/C/++ or > SUN/Oracles C/C++ Compiler as well. > > Likewise, autotools already handles that nicely. It even knows about > MSVC already. Good luck maintaining multiple build systems that all need > to be updated to accommodate different scenarios. > > I just tested the 32-Bit build on Windows 2000 32-Biz SP4 with latest > patches but there is an Error:"Entry Point Not Found The procedure entry > point ___lc_codepage_func could not be located in the dynamic linl > library msvcrt.dll" I just investigating this problem right now. > > This is a problem with the older toolchains, it has been fixed some time > ago, you may need to update your mingw-w64 install and/or recompile your > code. IIRC this problem plagues early XP SP0 and Win2K (Win2K isn't > exactly supported by mingw-w64, so anything goes). > > Hmm, i read a diffrent post from Kai Tiez > > [quote]mingw-w64 does not support Windows OSes below XP officially.[/quote] > http://sourceforge.net/support/tracker.php?aid=3382873 > > This explain a lot to me.Ok, if i want, i could built mingw64, GTK, > Boost and anythin i needed from scratch, but this is an oververhead and > like Kai explains: "This may work, but it is not officially supported". > So i think i will compile my Projects on Win x64 with mingw64 4.5.x > and on Win32 with MinGW 4.5.x wich runs out of the box on Win2000 > Systems up to Win8 on Win32 Targets (i have used it in an QT4Project and > it works flawless) On top of this i will use Cmake, it was build for > Crossplatform and Cross Compiler > builts and it is 10.000 times faster than the ugly Autotools ;D > > I guess you can't tell the difference between a compiler host, target > system, C Runtime and a buildsystem, you managed to mangle them all > together. Try again next time. > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > > > > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
Thanks for helping keep SourceForge clean.
X