From: Sidharth <cd...@gm...> - 2009-12-12 19:14:16
|
@Lloyd: I agree with your views on this. @Tor: I am not a novice to Linux but this is the first time i am planning to work on an open source project. MinGW combining a good dose of Linux+Windows attracted me to it. I respect your views, will try with something smaller and then give MinGW a shot. @lele: I have tried with gcc but am running to compile errors, believe i am missing something. Will get back to the group, if i cant get further. @All: I am ready to document the steps/create a howto. If there is a mechanism to follow/someone knows the steps, I can do it. On Fri, Dec 11, 2009 at 8:09 PM, <min...@li...>wrote: > Send MinGW-users mailing list submissions to > min...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/mingw-users > or, via email, send a message with subject or body 'help' to > min...@li... > > You can reach the person managing the list at > min...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of MinGW-users digest..." > > > Today's Topics: > > 1. Re: How to build Mingw Source files in windows (Lloyd Sargent) > 2. Re: perl symlink oddity (Cesar Strauss) > 3. Re: Window API don't find thefunction: > TzSpecificLocalTimeToSystemTime() (Thomas Steinbach) > 4. Re: Window API don't find > thefunction:TzSpecificLocalTimeToSystemTime() (Thomas Steinbach) > 5. Re: Window API don't find thefunction: > TzSpecificLocalTimeToSystemTime() (Sergey Sarbash) > 6. Re: Window API don't find thefunction: > TzSpecificLocalTimeToSystemTime() (Dennis Wassel) > 7. Re: Window API don't find thefunction: > TzSpecificLocalTimeToSystemTime() (Sergey Sarbash) > 8. Re: to_lower does not work with accents. valid locale names ? > (Alessandro Antonello) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 10 Dec 2009 17:18:28 -0600 > From: Lloyd Sargent <ll...@ca...> > Subject: Re: [Mingw-users] How to build Mingw Source files in windows > To: MinGW Users List <min...@li...> > Message-ID: <1BE...@ca...> > Content-Type: text/plain; charset=us-ascii > > On Dec 10, 2009, at 2:54 AM, Tor Lillqvist wrote: > > >> Can someone please point me to the right procedure. > > > > If you really are totally new to "open-source development > > tools/utilities" (meaning make, configure scripts, non-IDE tools in > > general etc), then I advice you start with something easier first, > > just to get experience of what the tools do at what stage in a typical > > build, and not jump right in at the hardest end and build the > > compiler. > > > > It would also be useful to have Unix experience. (It does not have to > > be Linux. Even being familiar with Microsoft's Interix ("Subsystem for > > Unix Applications") is a plus.) > > I've 30 years in programming, did my Masters work in compiler design and > STILL have not managed to get it to compile. > > So, no, it is not a simple case of "you might want to start with something > simple" it is a case, in my humble opinion, of lack of adequate > documentation. > > And yes I've Linux, Windows, and Mac OS experience. Did I mention that I > have written drivers for Windows, Windows CE and Linux? > > So if someone has a definitive guide I would be more than happy. But so > far, I have yet to get that magic arrangement of files that works on > Windows. > > Cheers, > > Lloyd > > > ------------------------------ > > Message: 2 > Date: Thu, 10 Dec 2009 23:04:13 -0200 > From: Cesar Strauss <ces...@gm...> > Subject: Re: [Mingw-users] perl symlink oddity > To: min...@li... > Message-ID: <hfs5qe$4vk$1...@ge...> > Content-Type: text/plain; charset=ISO-8859-1 > > Ralf Wildenhues wrote: > > Hello mingw-users, > > > > I've encountered an oddity with MSYS perl: it claims to support symlink, > > but failure to create a symlink due to missing target directory is not > > diagnosed: > > > > $ perl -e 'print eval { symlink("",""); 1} . "\n";' > > 1 > > $ rm -rf sub bar > > $ touch foo > > $ perl -e '$!=0; print symlink ("foo", "bar") . ", $!\n";' > > 1, No such file or directory > > $ ls bar > > bar > > $ rm -f bar > > $ perl -e '$!=0; print symlink ("foo", "sub/bar") . ", $!\n";' > > 1, No such file or directoryThanks again, and sorry for the > inconvenience. > > $ ls -l bar sub > > ls: bar: No such file or directory > > ls: sub: No such file or directory > > $ > > > > Dear Ralf > > Thanks for the report. > > As it turns out, there is a bug in the MSYS implementation of the > symlink system call. It is returning 1 on failure, when it should return > -1. > > The behavior you see is due to Perl treating any non-negative return > value from symlink() as a success. In fact, as it stands, the symlink > call of MSYS Perl will always report success, no matter what you throw > at it. > > The reason why one doesn't see this problem when running "ln -s" is > because the ln tool treats any non-zero return value from symlink() as a > failure, which masks the issue. > > After fixing the symlink() return value in the MSYS runtime library, > Perl starts behaving as one would expect: > > $ perl -e '$!=0; print symlink ("foo", "sub/bar") . ", $!\n";' > 0, No such file or directory > > You should expect the fix to be present in the next MSYS release. > > Thanks again, and sorry for the inconvenience. > > Cesar > > > > > ------------------------------ > > Message: 3 > Date: Fri, 11 Dec 2009 02:11:50 +0100 > From: "Thomas Steinbach" <ste...@gm...> > Subject: Re: [Mingw-users] Window API don't find thefunction: > TzSpecificLocalTimeToSystemTime() > To: min...@li... > Message-ID: <hfs72h$7pg$1...@ge...> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > Hello Sergey, > > >> [...] > > Me too. :( > > > >> I look for SystemTimeToTzSpecificLocalTime() function but > >> also can't find that function. > > > > It is. In the last mingw winapi release. > > Yes, found that now too. > If you still need the "TzSpecificLocalTimeToSystemTime" then > you can download the source for that function at: > > http://www.failure.bravehost.com/prog/mingw/additions/ > > Either use it with the files and copy both to your project and > add lines like: > > #ifdef __MINGW_H > #include "_time.h" > #endif > > or copy the funtion and declaration to your sourcecode. > Enclosed with a #ifdef __MINGW_H statement, etc. > Then you can use that Function with MinGW too. > > Comments about the sorucecode are welcome. > > Thomas > > > > > ------------------------------ > > Message: 4 > Date: Fri, 11 Dec 2009 02:08:26 +0100 > From: "Thomas Steinbach" <ste...@gm...> > Subject: Re: [Mingw-users] Window API don't find > thefunction:TzSpecificLocalTimeToSystemTime() > To: min...@li... > Message-ID: <hfs72i$7pi$1...@ge...> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > Hello Dennis, > > > Well, unless you bribe Bill, I am pretty sure you won't ... ;-) > > >> don't see that code in w32api-3.14-mingw32-src.tar.gz > >> or w32api-3.14-mingw32-dev.tar.gz > >> Are these funtions only "imported"? and there is no source code? > > > > If these are WIN API functions, then yes, they should only be imported > > (that is, unless they are overridden by mingw-specific > > implementations, which I highly doubt in this case). > > ok, begin to see... > > > The technique, as mentioned before, is to create headers and an > > appropriate import library for kernel32.dll, all of which the mingw > > winapi provides. As Sergey said, get the latest release and you should > > be fine. > > Argh, ok. That is the way how it works. Thought that all theese > functions are "new" implemented and in an own way to use it with MinGW. > > But then I don't understand, why this function is not in the > kernel32.def file in the latest release... Should be simple > to add that, shouldn't it? > > Anyway. Found the problem. It was just a missing > "#include <windows.h>" Now it works fine. > > Searching now a description/tutorial and how to create such import > libs and header files for mingw and to use it with my programs. > Does anybody knows such a tutorial for less experienced > programmers? > > Thomas > > > > > ------------------------------ > > Message: 5 > Date: Fri, 11 Dec 2009 09:15:00 +0300 > From: Sergey Sarbash <se...@un...> > Subject: Re: [Mingw-users] Window API don't find thefunction: > TzSpecificLocalTimeToSystemTime() > To: MinGW Users List <min...@li...> > Message-ID: <4B2...@un...> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Thomas Steinbach ?????: > > If you still need the "TzSpecificLocalTimeToSystemTime" then > > you can download the source for that function at: > > > > http://www.failure.bravehost.com/prog/mingw/additions/ > > Thank you for the link. I still think that it's better to add the > description of this function to MinGW WinAPI because it is already > implemented so we needn't to reinvent the wheel... > Your solution is the good thing for a while as temporary "crutch" until > then the maintainers update api's desc&lib. Thank you. > > -- > Best regards, > Sergey Sarbash. > > > > > > ------------------------------ > > Message: 6 > Date: Fri, 11 Dec 2009 08:39:50 +0100 > From: Dennis Wassel <den...@go...> > Subject: Re: [Mingw-users] Window API don't find thefunction: > TzSpecificLocalTimeToSystemTime() > To: MinGW Users List <min...@li...> > Message-ID: > <fe0...@ma...> > Content-Type: text/plain; charset=ISO-8859-1 > > 2009/12/11 Sergey Sarbash <se...@un...>: > > > Thank you for the link. I still think that it's better to add the > > description of this function to MinGW WinAPI because it is already > > implemented so we needn't to reinvent the wheel... > > Your solution is the good thing for a while as temporary "crutch" until > > then the maintainers update api's desc&lib. Thank you. > > I feel confused - does the latest w32api contain defs and imports for > those time functions or doesn't it? > > If not, have a look at > http://mingw.org/wiki/SubmitPatches > and send it upstream for others to benefit. > > Thomas: > The first two google links when searching for "dlltool" are quite helpful. > > Cheers, > Dennis > > > > ------------------------------ > > Message: 7 > Date: Fri, 11 Dec 2009 11:54:03 +0300 > From: Sergey Sarbash <se...@un...> > Subject: Re: [Mingw-users] Window API don't find thefunction: > TzSpecificLocalTimeToSystemTime() > To: MinGW Users List <min...@li...> > Message-ID: <4B2...@un...> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Dennis Wassel ?????: > > I feel confused - does the latest w32api contain defs and imports for > > those time functions or doesn't it? > > It does for the second mentioned (SystemTimeToTzSpecificLocalTime()). > TzSpecificLocalTimeToSystemTime() is missed there (winbase.h). > > -- > Truly yours, > Sergey Sarbash. > > > > > > ------------------------------ > > Message: 8 > Date: Fri, 11 Dec 2009 12:39:02 -0200 > From: Alessandro Antonello <ant...@gm...> > Subject: Re: [Mingw-users] to_lower does not work with accents. valid > locale names ? > To: MinGW Users List <min...@li...> > Message-ID: > <ceb...@ma...> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, Mauricio. > > I did find the same problem in 'libcmt.lib' shipped with Microsoft > compiler. > Functions like 'islower', 'isspace' and family thrown an 'assertion failed' > when used with accented characters. I tested with default locale and > 'pt_BR' > locale and both have the same problem. I didn't follow your posts but if > you > are testing in a Windows environment maybe the problem is in the 'msvcrt' > DLL > and not in GCC it self. > > Regards, > Alessandro Antonello > > > Tor, your text suggests I was lazy and that I did not do any research. > You > > are mistaken. > > > > I did my fair share of research. I stand by my post. It was stated in a > > clear and polite way. Boost is a well known library in the C++ community > and > > even if one does not know it, it is just a test case framework as the > string > > TEST_CASE in the macro suggests. > > The intent of showing the test case method was to demonstrate the code > works > > for other inputs. > > But I agree that trying to avoid 3rd party code in the examples is a good > > policy. I will try to be more restrict with boost usage in the mailing > list > > in the future. > > > > I tested with several strings for locale (including your suggestion) and > all > > but "C" and "POSIX" caused a runtime error. "C" and "POSIX" fail the test > > case but do not cause the runtime error because they are recognised as > valid > > locale names. > > > > Here is a complete code without boost and with only one failed test case: > > > > #include <iostream> > > #include <string> > > #include <locale> > > > > template<typename C> > > void to_lower(std::basic_string<C>& s, const std::locale& loc = > std::locale > > ()) > > { > > ??? typename std::basic_string<C>::iterator p; > > ??? for (p = s.begin (); p != s.end (); ++p) > > ??? { > > ??? ??? *p = std::use_facet<std::ctype<C> >(loc).tolower (*p); > > ??? } > > } > > > > int main() > > { > > ??? std::string s = "? JO?O"; > > ??? to_lower (s, std::locale("Portuguese_Brazil"));? // pt_BR also fails. > > ??? if (s == "? jo?o") > > ??????? std::cout << "OK - " << s; > > ??? else > > ??????? std::cout << "FAILED - " << s; > > ??? return 0; > > } > > > > > > ------------------------------ > > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > > > ------------------------------ > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > > > End of MinGW-users Digest, Vol 43, Issue 14 > ******************************************* > |
From: JonY <jo...@us...> - 2009-12-13 02:00:29
|
On 12/13/2009 03:14, Sidharth wrote: > @Lloyd: I agree with your views on this. > > @Tor: I am not a novice to Linux but this is the first time i am planning to > work on an open source project. MinGW combining a good dose of Linux+Windows > attracted me to it. I respect your views, will try with something smaller > and then give MinGW a shot. > > @lele: I have tried with gcc but am running to compile errors, believe i am > missing something. Will get back to the group, if i cant get further. > > @All: I am ready to document the steps/create a howto. If there is a > mechanism to follow/someone knows the steps, I can do it. > Hi, I do not agree with Lloyd, building a compiler does not require you to know its internals, however building one is not a trivial everyday task either. However, there are tons of documentation on building GCC, just look at the build scripts included with the GCC source tarballs on the MinGW downloads list, they'll tell you step by step on what you need to do. In any case, MinGW is not Linux+Windows, you should really try something smaller to familiarize yourself with the build system and terminology used. Here is something about building MinGW, to get you started, <http://wiki.wxwidgets.org/Install_The_Mingw_Cross-Compiler>. The guide about building by hand is very old but much of it still applies, just be sure to update the version numbers. For GCC building itself, you should read <http://gcc.gnu.org/install/> instead. Please do not top post, thanks. |
From: Lloyd S. <ll...@ca...> - 2009-12-16 14:55:39
Attachments:
Building Mingw 4.4.0
|
On Dec 12, 2009, at 7:17 PM, JonY wrote: > On 12/13/2009 03:14, Sidharth wrote: >> @Lloyd: I agree with your views on this. >> >> @Tor: I am not a novice to Linux but this is the first time i am planning to >> work on an open source project. MinGW combining a good dose of Linux+Windows >> attracted me to it. I respect your views, will try with something smaller >> and then give MinGW a shot. >> >> @lele: I have tried with gcc but am running to compile errors, believe i am >> missing something. Will get back to the group, if i cant get further. >> >> @All: I am ready to document the steps/create a howto. If there is a >> mechanism to follow/someone knows the steps, I can do it. >> > > Hi, > > I do not agree with Lloyd, building a compiler does not require you to > know its internals, however building one is not a trivial everyday task > either. That wasn't my point. Building GCC IS a trivial task. I have built it for other processors using buildroot. The problem is that the environment is not adequately documented. I'm willing to do so, but I'm NOT willing to spend a year on trial and error to do so. > However, there are tons of documentation on building GCC, just look at > the build scripts included with the GCC source tarballs on the MinGW > downloads list, they'll tell you step by step on what you need to do. They do not. If they DID tell you step by step, then I would not be experiencing this kind of frustration. > In any case, MinGW is not Linux+Windows, you should really try something > smaller to familiarize yourself with the build system and terminology used. So MinGW is no Linux+Windows and yet... > Here is something about building MinGW, to get you started, > <http://wiki.wxwidgets.org/Install_The_Mingw_Cross-Compiler>. The guide > about building by hand is very old but much of it still applies, just be > sure to update the version numbers. ... this link is "How to Build a Linux Cross Compiler" (btw it is virtually useless). Attached are my steps... feel free to modify or correct. Cheers, Lloyd |
From: JonY <jo...@us...> - 2009-12-16 16:38:18
|
On 12/16/2009 22:55, Lloyd Sargent wrote: >> >> I do not agree with Lloyd, building a compiler does not require you to >> know its internals, however building one is not a trivial everyday task >> either. > > That wasn't my point. > > Building GCC IS a trivial task. I have built it for other processors using buildroot. The problem is that the environment is not adequately documented. I'm willing to do so, but I'm NOT willing to spend a year on trial and error to do so. > Fine, just examine and read the buildroot script for an overview of the build procedures, they apply to equally to building GCC under MSYS as well. >> However, there are tons of documentation on building GCC, just look at >> the build scripts included with the GCC source tarballs on the MinGW >> downloads list, they'll tell you step by step on what you need to do. > > They do not. > > If they DID tell you step by step, then I would not be experiencing this kind of frustration. > How would a shell script NOT run step by step? >> In any case, MinGW is not Linux+Windows, you should really try something >> smaller to familiarize yourself with the build system and terminology used. > > So MinGW is no Linux+Windows and yet... > >> Here is something about building MinGW, to get you started, >> <http://wiki.wxwidgets.org/Install_The_Mingw_Cross-Compiler>. The guide >> about building by hand is very old but much of it still applies, just be >> sure to update the version numbers. > > ... this link is "How to Build a Linux Cross Compiler" (btw it is virtually useless). > > Why would it be useless? The steps to setup compiler or cross compiler is basically the same with Linux/Cygwin/MSYS when it comes to the GNU toolchain, regardless of target or host. You should already know how to use the shell and understand the basics of the autotools build system before trying to build GCC. If not, try something simpler first. |
From: Lloyd S. <ll...@ca...> - 2009-12-16 23:47:00
|
On Dec 16, 2009, at 10:22 AM, JonY wrote: > On 12/16/2009 22:55, Lloyd Sargent wrote: > You should already know how to use the shell and understand the basics > of the autotools build system before trying to build GCC. If not, try > something simpler first. Yes and in fact one on of the things you HAVE TO DO to get anywhere with MinGW is hack the build script. If and when I get the compiler to FINALLY build, I will correct the build script - I have fixed a few things but it still is a mess. One of the patch files is also wrong. I had to go in and hand patch it. Last I checked no one made any changes so it will not patch the files correctly. Where I gave up was on "c:\MinGW\mingw32\bin\ar.exe: .libs/libgomp.lib: File format not recognized" -- not terribly helpful and the answers I got were also unhelpful. It appears to be in the final stage of the compiles. If knowing autotools better will resolve this, then please enlighten this fool. Cheers, Lloyd |
From: JonY <jo...@us...> - 2009-12-17 02:58:22
|
On 12/17/2009 07:46, Lloyd Sargent wrote: > On Dec 16, 2009, at 10:22 AM, JonY wrote: > >> On 12/16/2009 22:55, Lloyd Sargent wrote: > >> You should already know how to use the shell and understand the basics >> of the autotools build system before trying to build GCC. If not, try >> something simpler first. > > Yes and in fact one on of the things you HAVE TO DO to get anywhere with MinGW is hack the build script. If and when I get the compiler to FINALLY build, I will correct the build script - I have fixed a few things but it still is a mess. > Please report the problems you have found. The build script maintainers would certainly know what to do. > One of the patch files is also wrong. I had to go in and hand patch it. Last I checked no one made any changes so it will not patch the files correctly. > > Where I gave up was on "c:\MinGW\mingw32\bin\ar.exe: .libs/libgomp.lib: File format not recognized" -- not terribly helpful and the answers I got were also unhelpful. It appears to be in the final stage of the compiles. > This bug probably started on the libtool side of things. A quick workaround is to edit the "libtool" shell script, change ".lib" file extension to ".dll.a", "rm libgomp.la" and "make libgomp.la" again. Be assured that ".libs/libgomp.lib" is a valid file, ar is picky with file extensions. It has already been reported at <http://gcc.gnu.org/ml/gcc/2009-08/msg00085.html>, but not much have been done. > If knowing autotools better will resolve this, then please enlighten this fool. > It won't fix the libtool bug, but knowing it gives you an understanding of the target, host and build relations that is integral to autotools. This is especially important for setting up GCC, building binutils for the incorrect target can break a working toolchain. |
From: <uti...@ya...> - 2009-12-17 05:03:54
|
It took me 11 hours, but it's progress :) It was a recipe someone else wrote. I ran testgtk.exe successfully. No c++ compilations yet, but soon. I'll try the gtkmm advice you gave me tomorrow. I started compiling cairomm but it depended on libsig++ so I'm going to bed :) It's midnight. I'll post the details about the gtk build and the gtkmm stuff tomorrow. Cheers, David Marceau |
From: JonY <jo...@us...> - 2009-12-17 05:26:15
|
On 12/17/2009 13:07, uti...@ya... wrote: > It took me 11 hours, but it's progress :) > It was a recipe someone else wrote. I ran testgtk.exe successfully. > No c++ compilations yet, but soon. I'll try the gtkmm advice you gave > me tomorrow. I started compiling cairomm but it depended on libsig++ so > I'm going to bed :) It's midnight. > > I'll post the details about the gtk build and the gtkmm stuff tomorrow. > > Cheers, > David Marceau > Hi, you replied to the wrong thread. :) |
From: Tor L. <tm...@ik...> - 2009-12-17 10:20:30
|
But I thought what you wanted to do was to build a GTK+ *application* (a gtkmm one), not GTK+ itself? Sure, it's OK if you want to build GTK+ itself, especially if you want to help out fixing the bugs in it. But you should just know that it certainly is not expected that people who build software that uses a complex library stack like gtkmm have to build the library stack from its sources first. Anyway, as long as there really isn't much MinGW-specific issues here (with which I mean issues with the MinGW compiler, headers, binutils like ld, etc), these two threads you started would belong more in a GTK+ list, not this list. --tml |
From: <uti...@ya...> - 2009-12-17 20:25:01
|
Tor Lillqvist wrote: > But I thought what you wanted to do was to build a GTK+ *application* > (a gtkmm one), not GTK+ itself? These links have the words cygwin inside them, but they seem to discuss mingw and no cygwin at all: http://kemovitra.blogspot.com/2009/06/setting-up-cygwin-for-software.html http://kemovitra.blogspot.com/2009/06/cygwin-tutorial-compiling-gtk-2162-for.html I followed above and here are my observations: 1)needed to download and compile the unzip sources and adjust the 2)cflags in makefile.gcc and in my 3)/home/user/.profile to have the following flags: -march pentium3 -mtune i586 4)zlib needs to be compiled before glib 5)bug in the glib configure: checking mswsock.h usability... no checking mswsock.h presence... yes configure: WARNING: mswsock.h: present but cannot be compiled configure: WARNING: mswsock.h: check for missing prerequisite headers? configure: WARNING: mswsock.h: see the Autoconf documentation configure: WARNING: mswsock.h: section "Present But Cannot Be Compiled" configure: WARNING: mswsock.h: proceeding with the preprocessor's result configure: WARNING: mswsock.h: in the future, the compiler will take precedence configure: WARNING: ## ----------------------------------------------------- -------------- ## configure: WARNING: ## Report this to http://bugzilla.gnome.org/enter_bug.cg i?product=glib ## configure: WARNING: ## ----------------------------------------------------- -------------- ## checking for mswsock.h... yes 6)make/make install for glib succeeded. 7)libpng done 8)libjpeg-7 done 9)libtiff cd port;make;cd ../libtiff;make done 10)libfreetype done 11)libexpat done 12)libxml done 13)libfontconfig done 14)libatk done 15)libpixman done 16)libcairo giving me issues with the configure/Makefile. I know that libpng-config exists, but I don't know how to connect it to the configure script. I changed the respective libpng cflags and libs in the Makefile along with adding -lpng14 to the cairo libs in the Makefile to get it to compile successfully. done 16.2)libpango done 16.3)gtk+2 changed the configure script to use png instead of png12 done 17)libcairomm /mingw/lib/pkg-config/cairo.pc changed libpng12 to libpng it wants libsig++ I installed the gtkmm.exe package you told me in your previous email: export PKG_CONFIG_PATH=/c/gtkmm/lib/pkgconfig:/c/mingw/lib/pkgconfig export LD_LIBRARY_PATH=/c/gtkmm/redist:/c/gtkmm/bin export PATH=/c/gtkmm/bin:/c/gtkmm/redist:$PATH gcc -Wall -o anomos.exe `pkg-config --cflags gtkmm-2.4 pangomm-1.4` anomos.cc `pkg-config --libs gtkmm-2.4 pangomm-1.4` -lstdc++ I ran anomos.exe with no hitches, twice in a row with no exceptions raised. BTW I tried to compile cadaver sources using mingw and was missing some stuff about glob/regex/signals. Is there a repository of mingw compiled gnu tools like wget and cadaver around? Cygwin has these. I needed to use cygwing cadaver to move these notes over from the windows laptop to the linux box. I prefer not to use nfs/samba/ftp. cadaver knows https out-of-the-box. Cheers, David Marceau |
From: <uti...@ya...> - 2009-12-17 22:46:24
|
uti...@ya... wrote: > Tor Lillqvist wrote: > These links have the words cygwin inside them, but they seem to discuss > mingw and no cygwin at all: > http://kemovitra.blogspot.com/2009/06/setting-up-cygwin-for-software.html > http://kemovitra.blogspot.com/2009/06/cygwin-tutorial-compiling-gtk-2162-for.html Oops I made a mistake with the two links. Here are the correct ones: http://kemovitra.blogspot.com/2008/01/installing-mingw-on-windows.html http://kemovitra.blogspot.com/2009/06/compiling-gtk-2-for-windows.html |
From: Tor L. <tm...@ik...> - 2009-12-17 22:55:38
|
>> But I thought what you wanted to do was to build a GTK+ *application* >> (a gtkmm one), not GTK+ itself? > These links have the words cygwin inside them, but they seem to discuss > mingw and no cygwin at all: > http://kemovitra.blogspot.com/2009/06/setting-up-cygwin-for-software.html > http://kemovitra.blogspot.com/2009/06/cygwin-tutorial-compiling-gtk-2162-for.html Hmm. There doesn't seem to be much actual communication of the old-fashioned "reply with something related to the question" sort going on here. I give up. --tml |