From: Xavier M. <xav...@al...> - 2006-02-07 19:06:50
|
Hi, I need to be able to compile under msys using make 3.80 (mainly to have the eval function of Make). However I cannot find any msys build that already includes this version of make. So, my questions are: - does it exist an msys build with that version of make? - if not, is there a (simple) way to create one of my own? - or is it recommended not to do so? - or shall I try directly with the 3.81beta4 (although I see many compilation problems on the make mailing list about it)? Thanks, Xavier |
From: Greg C. <chi...@co...> - 2006-02-07 19:42:11
|
On 2006-2-7 19:06 UTC, Xavier Marichal wrote: > > I need to be able to compile under msys using make 3.80 (mainly to have > the eval function of Make). > - does it exist an msys build with that version of make? I've only seen 3.79.1 included with MSYS. > - if not, is there a (simple) way to create one of my own? I think 3.81beta4 is easier to build with MSYS. With 3.80, you'd need to modify the sources. > - or is it recommended not to do so? > - or shall I try directly with the 3.81beta4 (although I see many > compilation problems on the make mailing list about it)? IIRC, I simply downloaded it and did './configure && make', and it succeeded except for 'loadavg.exe'. |
From: Xavier M. <xav...@al...> - 2006-02-07 20:49:10
|
>>- or is it recommended not to do so? >>- or shall I try directly with the 3.81beta4 (although I see many >>compilation problems on the make mailing list about it)? >> >> > >IIRC, I simply downloaded it and did './configure && make', >and it succeeded except for 'loadavg.exe'. > > I tried as well. I managed to get around the getloadavg.c problem by replacing the sleep by usleep in the code... Yet, I just have one problem, at both the end of the "make" and "make install" batches. It says: rm: cannot unlink `make.exe': Permission denied make[1]: *** [make.exe] Error 1 Regards, Xavier |
From: Earnie B. <ea...@us...> - 2006-02-07 22:38:36
|
Quoting Xavier Marichal <xav...@al...>: > >>> - or is it recommended not to do so? >>> - or shall I try directly with the 3.81beta4 (although I see many >>> compilation problems on the make mailing list about it)? >>> >> >> IIRC, I simply downloaded it and did './configure && make', >> and it succeeded except for 'loadavg.exe'. >> > I tried as well. I managed to get around the getloadavg.c problem by > replacing the sleep by usleep in the code... > > Yet, I just have one problem, at both the end of the "make" and "make > install" batches. It says: > > rm: cannot unlink `make.exe': Permission denied > make[1]: *** [make.exe] Error 1 > Because the first directory in PATH points to the current directory; you used the make program you were installing to install itself. The rm failed because the binary was in use. I've only been bitten by this a few hundred times. :) Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Xavier M. <xav...@al...> - 2006-02-07 22:48:22
|
> Because the first directory in PATH points to the current directory; > you used the make program you were installing to install itself. The > rm failed because the binary was in use. I've only been bitten by > this a few hundred times. :) Sounds logical. And now, hopefully my last dumb question ;-) : how do I redefine the path in Msys? I 'just' do so in a .bash_profile? Xavier |
From: Earnie B. <ea...@us...> - 2006-02-07 23:27:35
|
Quoting Xavier Marichal <xav...@al...>: > >> Because the first directory in PATH points to the current directory; >> you used the make program you were installing to install itself. >> The rm failed because the binary was in use. I've only been bitten >> by this a few hundred times. :) > > Sounds logical. > And now, hopefully my last dumb question ;-) : how do I redefine the > path in Msys? I 'just' do so in a .bash_profile? > Close, ~/.profile is what you need to create to modify the environment. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Xavier M. <xav...@al...> - 2006-02-08 01:11:42
|
Earnie Boyd wrote: > Quoting Xavier Marichal <xav...@al...>: > >> > Because the first directory in PATH points to the current >> directory; you used the make program you were installing to install >> itself. The rm failed because the binary was in use. I've only been >> bitten by this a few hundred times. :) >> >> Sounds logical. >> And now, hopefully my last dumb question ;-) : how do I redefine the >> path in Msys? I 'just' do so in a .bash_profile? > > Close, ~/.profile is what you need to create to modify the environment. > > Earnie Boyd Thanks Earnie, I feel progresses are made. - So, after modifying my path and commenting the sleep line in getloadavg.c and avoiding , all of make-3.81beta4 compiles with './configure && make' - 'make check' shows good results (still 24 mistakes yet, I do not know if you are interested in those?) - yet, 'make install' still encounters the following problems: Making install in w32 make[1]: Entering directory `C:/msys/home/marichal/make-3.81beta4/w32' make[2]: Entering directory `C:/msys/home/marichal/make-3.81beta4/w32' make[2]: Nothing to be done for `install-exec-am'. make[2]: Nothing to be done for `install-data-am'. make[2]: Leaving directory `C:/msys/home/marichal/make-3.81beta4/w32' make[1]: Leaving directory `C:/msys/home/marichal/make-3.81beta4/w32' make[1]: Entering directory `C:/msys/home/marichal/make-3.81beta4' make[2]: Entering directory `C:/msys/home/marichal/make-3.81beta4' test -z "/usr/local/bin" || mkdir -p -- "/usr/local/bin" /bin/install -c 'make.exe' '/usr/local/bin/make.exe' /bin/install: cannot remove `/usr/local/bin/make.exe': Permission denied make[2]: *** [install-binPROGRAMS] Error 1 make[2]: Leaving directory `C:/msys/home/marichal/make-3.81beta4' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `C:/msys/home/marichal/make-3.81beta4' make: *** [install-recursive] Error 1 Yet, the path is set so that: marichal@XM-LAPTOP ~/make-3.81beta4 $ make -v GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Any idea? Regards, Xavier |
From: Keith M. <kei...@to...> - 2006-02-08 09:55:18
|
Xavier Marichal wrote, quoting Greg Chicares: >> IIRC, I simply downloaded it and did './configure && make', >> and it succeeded except for 'loadavg.exe'. > > I tried as well. I managed to get around the getloadavg.c problem > by replacing the sleep by usleep in the code... I've seen this reported once before; I could not reproduce it. I did exactly as Greg did, and *everything* built successfully, with only a few minor, and easily corrected warnings. You should *not* have needed to remove the `sleep' reference; there may be some defect in your MSYS or MinGW installation. > Yet, I just have one problem, at both the end of the "make" and > "make install" batches. It says: > > rm: cannot unlink `make.exe': Permission denied > make[1]: *** [make.exe] Error 1 This happens when you try to replace the `make.exe' which is running your actual build process. In this particular case, it appears that you are trying to overwrite the make.exe in your MSYS /bin directory; you must not do this. The make-3.81-beta4 you are building is a *native* Win32 app. Unless you are running the msys-1.0.11 release candidate, then you must never put native binaries in /bin. Leave the make-3.79 that's there alone, and install your make-3.81 somewhere else. Ideally, also give it a different name, say gnumake.exe, to avoid confusion -- this is why we call our native version mingw32-make. If you then ensure that wherever you installed gnumake.exe is in your path, and you use gnumake instead of make, you should be running this version; (this will also propagate to recursive makes, if you've used $(MAKE) correctly). Regards, Keith. |
From: Xavier M. <xav...@al...> - 2006-02-08 15:38:03
|
Keith, >I've seen this reported once before; I could not reproduce it. I >did exactly as Greg did, and *everything* built successfully, with >only a few minor, and easily corrected warnings. You should *not* >have needed to remove the `sleep' reference; there may be some >defect in your MSYS or MinGW installation. > > It might be indeed. But unfortunately, I cannot spot what... >>Yet, I just have one problem, at both the end of the "make" and >>"make install" batches. It says: >> >>rm: cannot unlink `make.exe': Permission denied >>make[1]: *** [make.exe] Error 1 >> >> > >This happens when you try to replace the `make.exe' which is running >your actual build process. In this particular case, it appears that >you are trying to overwrite the make.exe in your MSYS /bin directory; >you must not do this. > > The fact is that I would actually like to have replace it, yes. >The make-3.81-beta4 you are building is a *native* Win32 app. Unless >you are running the msys-1.0.11 release candidate, then you must never >put native binaries in /bin. Leave the make-3.79 that's there alone, >and install your make-3.81 somewhere else. Ideally, also give it a >different name, say gnumake.exe, to avoid confusion -- this is why we >call our native version mingw32-make. > >If you then ensure that wherever you installed gnumake.exe is in your >path, and you use gnumake instead of make, you should be running this >version; (this will also propagate to recursive makes, if you've used >$(MAKE) correctly). > > This is what I did initially. Here is a little recap of what I tried so far: since I was needing version 3.80 of Make to have the eval function working, I downloaded and installed mingw32-make-3.80.0-2.exe <http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-2.exe?download>. I correctly defined $(MAKE) in all my makefiles and launched my make project with mingw32-make. I almost immediately got the following error: sed: -e expression #2, char 9: Unknown option to 's' gnumake[1]: Entering directory `C:/msys/home/marichal/af' g++.exe: no input files The problem clearly comes from a bad interpretation of a sed command, which in turn makes that the g++ command has not received the appropriate parameters. This sed command occurs in one of my rules to automatically generate dependencies and store in .d files: # # Creating sub-makefile for dependencies from C++ source files # $(OBJECT_DIR)%$(DBG_USED_SUFFIX)$(DEP_EXT) : $(FILES_PATH)%$(SRC_EXT) $(VERBOSE_ECHO) $(SHELL) -ec '$(CXX) -MM $(FINAL_CPPFLAGS) $(CXXINCLDIRS) $< | sed '\''s/\($*\)\.o[ :]*/$(OBJECT_DIR_FOR_SED)\1$(DBG_USED_SUFFIX).o $(subst /,\/,$@) : /g'\'' > $@' Yet, this line works perfectly with make 3.79, under both msys and linux. And with make 3.80 as well under Linux.... Then, I first tried to compile make-3.81beta4 under msys using the build_w32.bat script for building a native Win app. It resulted in a gnumake.exe. I assigned $5MAKE) to this command and re-launched my project using it. It resulted in exactly the same sed error. My (may be too naive) conclusion was thus that there might be something clashing between these external build of Make and the shell and other commands (mainly sed and ls) that I ask make to use, which should be the ones defined by msys. Hence my attempt to re-install a version 3.80 of make as the msys default make command. Any better idea is most welcome. Shall I try msys-1.0.11 as you suggest? Currently I use 1.0.10. Regards, Xavier |
From: Greg C. <chi...@co...> - 2006-02-08 16:20:21
|
On 2006-2-8 15:37 UTC, Xavier Marichal wrote: > > [...] I downloaded and installed mingw32-make-3.80.0-2.exe > <http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-2.exe?download>. > I correctly defined $(MAKE) in all my makefiles and launched my make > project with mingw32-make. > > I almost immediately got the following error: > > sed: -e expression #2, char 9: Unknown option to 's' > gnumake[1]: Entering directory `C:/msys/home/marichal/af' > g++.exe: no input files > > The problem clearly comes from a bad interpretation of a sed command, > which in turn makes that the g++ command has not received the > appropriate parameters. > This sed command occurs in one of my rules to automatically generate > dependencies and store in .d files: > > # > # Creating sub-makefile for dependencies from C++ source files > # > $(OBJECT_DIR)%$(DBG_USED_SUFFIX)$(DEP_EXT) : $(FILES_PATH)%$(SRC_EXT) > $(VERBOSE_ECHO) $(SHELL) -ec '$(CXX) -MM $(FINAL_CPPFLAGS) > $(CXXINCLDIRS) $< | sed '\''s/\($*\)\.o[ > :]*/$(OBJECT_DIR_FOR_SED)\1$(DBG_USED_SUFFIX).o $(subst /,\/,$@) : > /g'\'' > $@' > > Yet, this line works perfectly with make 3.79, under both msys and > linux. And with make 3.80 as well under Linux.... Examine the actual 'sed' command that gets executed. Perhaps some portion of it, for instance /$(OBJECT_DIR_FOR_SED) gets expanded by the MSYS shell to something like '/C:\foo\bar'. |
From: Xavier M. <xav...@al...> - 2006-02-08 16:53:30
|
Greg Chicares wrote: >On 2006-2-8 15:37 UTC, Xavier Marichal wrote: > > >>[...] I downloaded and installed mingw32-make-3.80.0-2.exe >><http://prdownloads.sf.net/mingw/mingw32-make-3.80.0-2.exe?download>. >>I correctly defined $(MAKE) in all my makefiles and launched my make >>project with mingw32-make. >> >>I almost immediately got the following error: >> >>sed: -e expression #2, char 9: Unknown option to 's' >>gnumake[1]: Entering directory `C:/msys/home/marichal/af' >>g++.exe: no input files >> >>The problem clearly comes from a bad interpretation of a sed command, >>which in turn makes that the g++ command has not received the >>appropriate parameters. >>This sed command occurs in one of my rules to automatically generate >>dependencies and store in .d files: >> >># >># Creating sub-makefile for dependencies from C++ source files >># >>$(OBJECT_DIR)%$(DBG_USED_SUFFIX)$(DEP_EXT) : $(FILES_PATH)%$(SRC_EXT) >> $(VERBOSE_ECHO) $(SHELL) -ec '$(CXX) -MM $(FINAL_CPPFLAGS) >>$(CXXINCLDIRS) $< | sed '\''s/\($*\)\.o[ >>:]*/$(OBJECT_DIR_FOR_SED)\1$(DBG_USED_SUFFIX).o $(subst /,\/,$@) : >>/g'\'' > $@' >> >>Yet, this line works perfectly with make 3.79, under both msys and >>linux. And with make 3.80 as well under Linux.... >> >> > >Examine the actual 'sed' command that gets executed. Perhaps >some portion of it, for instance > /$(OBJECT_DIR_FOR_SED) >gets expanded by the MSYS shell to something like '/C:\foo\bar'. > > I already did, but I'll again. Yet, why does it work with msys and make (3.79) and not with the same msys and another make? I suspect there are not using the same version of some commands, isn't it? Regards, Xavier |
From: Xavier M. <xav...@al...> - 2006-02-08 23:01:22
|
Greg, >Examine the actual 'sed' command that gets executed. Perhaps >some portion of it, for instance > /$(OBJECT_DIR_FOR_SED) >gets expanded by the MSYS shell to something like '/C:\foo\bar'. > > Actually, you were right: there weird C; that appear with another version of make than the msys intergated one. So, my actual rule (mofidied for complete trace and verbose) is: $(OBJECT_DIR)%$(DBG_SUFFIX)$(DEP_EXT) : $(FILES_PATH)%$(SRC_EXT) $(SHELL) -ec '$(CXX) -MM $(FINAL_CPPFLAGS) $(CXXINCLDIRS) $< | sed '\''s/\($*\)\.o[ :]*/$(shell echo $(OBJECT_DIR) | sed 's/\//\\\//g'))\1$(DBG_SUFFIX).o $(subst /,\/,$@) : /g'\'' > $@' With make3.79 (msys-1.1.10 default), it transforms into: /bin/sh.exe -ec 'g++ -MM -DWINDOWS -Ic:/mingw/local/include/gtkmm-2.4 -Ic:/mingw/local/lib/gtkmm-2.4/include -Ic:/mingw/local/include/glibmm-2.4 -Ic:/mingw/local/lib/glibmm-2.4/include -Ic:/mingw/local/include/gdkmm-2.4 -Ic:/mingw/local/lib/gdkmm-2.4/include -Ic:/mingw/local/include/pangomm-1.4 -Ic:/mingw/local/include/atkmm-1.6 -Ic:/mingw/local/include/gtk-2.0 -Ic:/mingw/local/include/sigc++-2.0 -Ic:/mingw/local/lib/sigc++-2.0/include -Ic:/mingw/local/include/glib-2.0 -Ic:/mingw/local/lib/glib-2.0/include -Ic:/mingw/local/lib/gtk-2.0/include -Ic:/mingw/local/include/pango-1.0 -Ic:/mingw/local/include/atk-1.0 -I/usr/local/include/SDL -Dmain=SDL_main -I/usr/local/include/freetype2 -I/usr/local/include -D_REENTRANT -Ic:/mingw/local/include/gnet-2.0 -Ic:/mingw/local/lib/gnet-2.0/include -Ic:/mingw/local/include/glib-2.0 -Ic:/mingw/local/lib/glib-2.0/include -DALTER_MMX -DALTER_SSE2 -D_REENTRANT -D_GNU_SOURCE -mthreads -mms-bitfields -DALTER_MODULE=AlterHasp -Isrc/ -Isrc/common/ -I/usr/local/xerces-c/include -I/usr/local/include/portaudio -I/usr/local/include/newmat -I/usr/local/include src/AlterHasp/hasptime.cpp | sed '\''s/\(hasptime\)\.o[ :]*/objects\/AlterHasp_)\1.o objects\/AlterHasp_hasptime.d : /g'\'' > objects/AlterHasp_hasptime.d' But with gnumake.exe (native compil of make-3.81beta4) or with mingw32-make (version 3.80, it becomes: C:/msys/bin/sh.exe -ec 'g++ -MM -DWINDOWS -Ic:\mingw\local\include\gtkmm-2.4 -Ic:\mingw\local\lib\gtkmm-2.4\include -Ic:\mingw\local\include\glibmm-2.4 -Ic:\mingw\local\lib\glibmm-2.4\include -Ic:\mingw\local\include\gdkmm-2.4 -Ic:\mingw\local\lib\gdkmm-2.4\include -Ic:\mingw\local\include\pangomm-1.4 -Ic:\mingw\local\include\atkmm-1.6 -Ic:\mingw\local\include\gtk-2.0 -Ic:\mingw\local\include\sigc++-2.0 -Ic:\mingw\local\lib\sigc++-2.0\include -Ic:\mingw\local\include\glib-2.0 -Ic:\mingw\local\lib\glib-2.0\include -Ic:\mingw\local\lib\gtk-2.0\include -Ic:\mingw\local\include\pango-1.0 -Ic:\mingw\local\include\atk-1.0 -I\usr\local\include\SDL -Dmain=SDL_main -I\usr\local\include\freetype2 -I\usr\local\include -D_REENTRANT *-Ic;c:\mingw\local\include\gnet-2.0 -Ic;c:\mingw\local\lib\gnet-2.0\include -Ic;c:\mingw\local\include\glib-2.0 -Ic;c:\mingw\local\lib\glib-2.0\include * -DALTER_MMX -DALTER_SSE2 -D_REENTRANT -D_GNU_SOURCE -mthreads -mms-bitfields -DALTER_MODULE=AlterHasp -Isrc/ -Isrc/common/ -I/usr/local/xerces-c/include -I/usr/local/include/portaudio -I/usr/local/include/newmat -I/usr/local/include src/AlterHasp/hasptime.cpp | sed '\''s/\(hasptime\)\.o[ :]*/)\1.o objects\/AlterHasp_hasptime.d : /g'\'' > objects/AlterHasp_hasptime.d' So, a series of include comes with a -Ic;c:\... instead of -Ix:\... Obviously, sed does not like the semi-colon! Yet, these includes are the results of these two intermediate commands: GNET_CFLAGS := $(shell pkg-config gnet-2.0 --cflags) CPPFLAGS += $(GNET_CFLAGS) But, it I execute the pkg-config in msys, everything goes right: marichal@XM-LAPTOP ~/af $ pkg-config gnet-2.0 --cflags -D_REENTRANT -Ic:/mingw/local/include/gnet-2.0 -Ic:/mingw/local/lib/gnet-2.0/include -Ic:/mingw/local/include/glib-2.0 -Ic:/mingw/local/lib/glib-2.0/include So, again, isn't it a problem of bad integration (I mean dialog) of these makefiles w/r to msys? -- * Xavier Marichal * Voice: (310)242-5866 Fax: (310)242-5201 Cell: (310)733-9086 CTO <http://www.alterface.com> /Disclaimer <http://alterface.adsl.perceval.be:8080/email/disclaimer.txt>/ *Alterface* / 6080 Center Drive - Suite 600 Los Angeles CA 90045 USA / |
From: Greg C. <chi...@co...> - 2006-02-09 04:45:34
|
On 2006-2-8 23:01 UTC, Xavier Marichal wrote: > >>Examine the actual 'sed' command that gets executed. Perhaps >>some portion of it, for instance >> /$(OBJECT_DIR_FOR_SED) >>gets expanded by the MSYS shell to something like '/C:\foo\bar'. >> >> > Actually, you were right: there weird C; that appear with another > version of make than the msys intergated one. IIRC, the MSYS shell's path translation works differently for MSYS-dependent programs than for other programs. > But with gnumake.exe (native compil of make-3.81beta4) or with > mingw32-make (version 3.80, it becomes: [...] > -Ic;c:\mingw\local\lib\gnet-2.0\include > -Ic;c:\mingw\local\include\glib-2.0 [...] > So, a series of include comes with a -Ic;c:\... instead of -Ix:\... > Obviously, sed does not like the semi-colon! It's the MSYS version of bash that does the path translation. It's an aggressive translation. It changes quoted 'sed' commands that somehow look like they might be paths. Often, you can rewrite a 'sed' command so that it doesn't get translated. I don't know a general rule; I just try to find a way to prevent the translation. > But, it I execute the pkg-config in msys, everything goes right: > marichal@XM-LAPTOP ~/af > $ pkg-config gnet-2.0 --cflags > -D_REENTRANT -Ic:/mingw/local/include/gnet-2.0 > -Ic:/mingw/local/lib/gnet-2.0/include -Ic:/mingw/local/include/glib-2.0 > -Ic:/mingw/local/lib/glib-2.0/include Well, if that does everything you need, then that's great. If you still need a later version of 'make', and don't want to change your 'sed' commands, then try building the 'make' beta as an MSYS app. |
From: Xavier M. <xav...@al...> - 2006-02-09 16:56:09
|
Greg Chicares wrote: >IIRC, the MSYS shell's path translation works differently for >MSYS-dependent programs than for other programs. > > Indeed. >It's the MSYS version of bash that does the path translation. >It's an aggressive translation. It changes quoted 'sed' >commands that somehow look like they might be paths. > >Often, you can rewrite a 'sed' command so that it doesn't >get translated. I don't know a general rule; I just try to >find a way to prevent the translation. > > > >>But, it I execute the pkg-config in msys, everything goes right: >>marichal@XM-LAPTOP ~/af >>$ pkg-config gnet-2.0 --cflags >>-D_REENTRANT -Ic:/mingw/local/include/gnet-2.0 >>-Ic:/mingw/local/lib/gnet-2.0/include -Ic:/mingw/local/include/glib-2.0 >>-Ic:/mingw/local/lib/glib-2.0/include >> >> I will indeed try to find a way around this. Yet, the problem does not come from sed in this case. I tried sed with the -c flag, as indicated in http://www.accesspdf.com/article.php/20041222155709745 (telle me more about sed at the end of the page), and it does not change anything. Indeed, I believe that the problem is not sed but rather is a wrong interpretation of this command: GNET_CFLAGS := $(shell pkg-config gnet-2.0 --cflags) >Well, if that does everything you need, then that's great. > >If you still need a later version of 'make', and don't >want to change your 'sed' commands, then try building the >'make' beta as an MSYS app. > > Actually, by explicitely compiling every step of make-3.81beta4 with the /bin/make command, I managed to have it compiled and installed. Now, make is directly pointed at version 3.81beta4 (while /bin/make is still v3.79), but it does not change anything to the afore mentioned problem. Any hint regarding the translation of directories of the pkg-config command ? Regards, Xavier |
From: Xavier M. <xav...@al...> - 2006-02-09 18:04:59
|
I forgot to mention that I still need make v3.80 (or more) in order to be able to use the eval function of make. Earnie, shall I try to move to msys1.0.11 ? What version of make does it include? Regards, Xavier Xavier Marichal wrote: > > Greg Chicares wrote: > >> IIRC, the MSYS shell's path translation works differently for >> MSYS-dependent programs than for other programs. >> >> > Indeed. > >> It's the MSYS version of bash that does the path translation. >> It's an aggressive translation. It changes quoted 'sed' >> commands that somehow look like they might be paths. >> >> Often, you can rewrite a 'sed' command so that it doesn't >> get translated. I don't know a general rule; I just try to >> find a way to prevent the translation. >> >> >> >>> But, it I execute the pkg-config in msys, everything goes right: >>> marichal@XM-LAPTOP ~/af >>> $ pkg-config gnet-2.0 --cflags >>> -D_REENTRANT -Ic:/mingw/local/include/gnet-2.0 >>> -Ic:/mingw/local/lib/gnet-2.0/include -Ic:/mingw/local/include/glib-2.0 >>> -Ic:/mingw/local/lib/glib-2.0/include >> > I will indeed try to find a way around this. Yet, the problem does not > come from sed in this case. > I tried sed with the -c flag, as indicated in > http://www.accesspdf.com/article.php/20041222155709745 (telle me more > about sed at the end of the page), and it does not change anything. > Indeed, I believe that the problem is not sed but rather is a wrong > interpretation of this command: > > GNET_CFLAGS := $(shell pkg-config gnet-2.0 --cflags) > >> Well, if that does everything you need, then that's great. >> >> If you still need a later version of 'make', and don't >> want to change your 'sed' commands, then try building the >> 'make' beta as an MSYS app. >> >> > Actually, by explicitely compiling every step of make-3.81beta4 with > the /bin/make command, I managed to have it compiled and installed. > Now, make is directly pointed at version 3.81beta4 (while /bin/make is > still v3.79), but it does not change anything to the afore mentioned > problem. > Any hint regarding the translation of directories of the pkg-config > command ? > > Regards, > Xavier > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Mingw-msys mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-msys > > |
From: Xavier M. <xav...@al...> - 2006-02-14 04:58:01
|
Sorry to annoy everyone again, but I am still desperately trying to be able to use make-3-80 or higher under msys/mingw, and my deadlines are now quickly approaching. Thinking that it might be due to some slight differences between the 'regular' versions of make and their 'mingw/msys distribution', I did download http://prdownloads.sf.net/mingw/make-3.79.1-20010722-src.tar.gz?download. After compilation (using Makefile.mingw) and execution on my project, I still get exactly the same problem. Anyone has something to advice me? I am available to conduct any test, hopefully this might also be helpful to the community, but I just do not know what to try next... Thanks, Xavier Xavier Marichal wrote: > Greg, > >>Examine the actual 'sed' command that gets executed. Perhaps >>some portion of it, for instance >> /$(OBJECT_DIR_FOR_SED) >>gets expanded by the MSYS shell to something like '/C:\foo\bar'. >> >> > Actually, you were right: there weird C; that appear with another > version of make than the msys intergated one. > > So, my actual rule (mofidied for complete trace and verbose) is: > $(OBJECT_DIR)%$(DBG_SUFFIX)$(DEP_EXT) : $(FILES_PATH)%$(SRC_EXT) > $(SHELL) -ec '$(CXX) -MM $(FINAL_CPPFLAGS) $(CXXINCLDIRS) $< | sed > '\''s/\($*\)\.o[ :]*/$(shell echo $(OBJECT_DIR) | sed > 's/\//\\\//g'))\1$(DBG_SUFFIX).o $(subst /,\/,$@) : /g'\'' > $@' > > With make3.79 (msys-1.1.10 default), it transforms into: > > /bin/sh.exe -ec 'g++ -MM -DWINDOWS -Ic:/mingw/local/include/gtkmm-2.4 > -Ic:/mingw/local/lib/gtkmm-2.4/include > -Ic:/mingw/local/include/glibmm-2.4 > -Ic:/mingw/local/lib/glibmm-2.4/include > -Ic:/mingw/local/include/gdkmm-2.4 > -Ic:/mingw/local/lib/gdkmm-2.4/include > -Ic:/mingw/local/include/pangomm-1.4 > -Ic:/mingw/local/include/atkmm-1.6 -Ic:/mingw/local/include/gtk-2.0 > -Ic:/mingw/local/include/sigc++-2.0 > -Ic:/mingw/local/lib/sigc++-2.0/include > -Ic:/mingw/local/include/glib-2.0 > -Ic:/mingw/local/lib/glib-2.0/include > -Ic:/mingw/local/lib/gtk-2.0/include > -Ic:/mingw/local/include/pango-1.0 -Ic:/mingw/local/include/atk-1.0 > -I/usr/local/include/SDL -Dmain=SDL_main > -I/usr/local/include/freetype2 -I/usr/local/include -D_REENTRANT > -Ic:/mingw/local/include/gnet-2.0 > -Ic:/mingw/local/lib/gnet-2.0/include > -Ic:/mingw/local/include/glib-2.0 > -Ic:/mingw/local/lib/glib-2.0/include -DALTER_MMX -DALTER_SSE2 > -D_REENTRANT -D_GNU_SOURCE -mthreads -mms-bitfields > -DALTER_MODULE=AlterHasp -Isrc/ -Isrc/common/ > -I/usr/local/xerces-c/include -I/usr/local/include/portaudio > -I/usr/local/include/newmat -I/usr/local/include > src/AlterHasp/hasptime.cpp | sed '\''s/\(hasptime\)\.o[ > :]*/objects\/AlterHasp_)\1.o objects\/AlterHasp_hasptime.d : /g'\'' > > objects/AlterHasp_hasptime.d' > > But with gnumake.exe (native compil of make-3.81beta4) or with > mingw32-make (version 3.80, it becomes: > C:/msys/bin/sh.exe -ec 'g++ -MM -DWINDOWS > -Ic:\mingw\local\include\gtkmm-2.4 > -Ic:\mingw\local\lib\gtkmm-2.4\include > -Ic:\mingw\local\include\glibmm-2.4 > -Ic:\mingw\local\lib\glibmm-2.4\include > -Ic:\mingw\local\include\gdkmm-2.4 > -Ic:\mingw\local\lib\gdkmm-2.4\include > -Ic:\mingw\local\include\pangomm-1.4 > -Ic:\mingw\local\include\atkmm-1.6 -Ic:\mingw\local\include\gtk-2.0 > -Ic:\mingw\local\include\sigc++-2.0 > -Ic:\mingw\local\lib\sigc++-2.0\include > -Ic:\mingw\local\include\glib-2.0 > -Ic:\mingw\local\lib\glib-2.0\include > -Ic:\mingw\local\lib\gtk-2.0\include > -Ic:\mingw\local\include\pango-1.0 -Ic:\mingw\local\include\atk-1.0 > -I\usr\local\include\SDL -Dmain=SDL_main > -I\usr\local\include\freetype2 -I\usr\local\include -D_REENTRANT > *-Ic;c:\mingw\local\include\gnet-2.0 > -Ic;c:\mingw\local\lib\gnet-2.0\include > -Ic;c:\mingw\local\include\glib-2.0 > -Ic;c:\mingw\local\lib\glib-2.0\include * -DALTER_MMX -DALTER_SSE2 > -D_REENTRANT -D_GNU_SOURCE -mthreads -mms-bitfields > -DALTER_MODULE=AlterHasp -Isrc/ -Isrc/common/ > -I/usr/local/xerces-c/include -I/usr/local/include/portaudio > -I/usr/local/include/newmat -I/usr/local/include > src/AlterHasp/hasptime.cpp | sed '\''s/\(hasptime\)\.o[ :]*/)\1.o > objects\/AlterHasp_hasptime.d : /g'\'' > objects/AlterHasp_hasptime.d' > > So, a series of include comes with a -Ic;c:\... instead of -Ix:\... > Obviously, sed does not like the semi-colon! > > Yet, these includes are the results of these two intermediate commands: > GNET_CFLAGS := $(shell pkg-config gnet-2.0 --cflags) > CPPFLAGS += $(GNET_CFLAGS) > > But, it I execute the pkg-config in msys, everything goes right: > marichal@XM-LAPTOP ~/af > $ pkg-config gnet-2.0 --cflags > -D_REENTRANT -Ic:/mingw/local/include/gnet-2.0 > -Ic:/mingw/local/lib/gnet-2.0/include > -Ic:/mingw/local/include/glib-2.0 -Ic:/mingw/local/lib/glib-2.0/include > > So, again, isn't it a problem of bad integration (I mean dialog) of > these makefiles w/r to msys? |