* pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues) @ 2012-03-29 20:02 Basile Starynkevitch 2012-03-29 20:45 ` [GCC-MELT-386] " Romain Geissler 2012-04-02 10:31 ` Announce: MELT 0.9.5rc2 release candidate (for GCC 4.6 and 4.7) Basile Starynkevitch 0 siblings, 2 replies; 18+ messages in thread From: Basile Starynkevitch @ 2012-03-29 20:02 UTC (permalink / raw) To: gcc-melt; +Cc: gcc Hello All, The pre-release candidate 1 of MELT 0.9.5 is available for testing on http://gcc-melt.org/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7.tar.gz as a gzipped tar archive of 4473286 bytes and md5sum ae00b9bd31f481e1bbc406711ca4c2f4. extracted from MELT branch 185969, march 29th 2012 You could try building it e.g. with make MELTGCC=gcc-4.7 GCCMELT_CC=gcc-4.7 It seems to be also buildable for GCC 4.6 with make MELTGCC=gcc-4.6 GCCMELT_CC=gcc-4.6 (both commands sort of work, with perhaps minor issues very late in the build process; I'm not very afraid of these) But I'm trying to code a makefile which would autodetect in GCC 4.7 was compiled in C++ mode (or if the GCC was compiled in C mode, then it is probably a 4.6 or a 4.7 configured in a weird fashion). So far I tried to code in my Makefile the following trick ############################################################################ ## the compiler with which melt.so is used ifndef MELTGCC MELTGCC = $(or $(CC),gcc) endif ## gives yes if MELTGCC has been built with C++ or else the empty string MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define +ENABLE_BUILD_WITH_CXX +1' \ `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes) ## The compiler and flags used to build the melt.so plugin and to ## compile MELT generated code. Notice that melt-module.mk use the ## same Make variables. For a melt plugin to GCC 4.7 or later, that ## could be a C++ compiler! eg ## make MELTGCC=gcc-4.7 GCCMELT_CC=g++-4.7 ## hence we add a test if $(MELTGCC) was built with C++ or with C ifeq ($(strip $(MELTGCC_BUILD_WITH_CXX)),) GCCMELT_CC ?= $(or $(CC),gcc) -Wc++-compat else GCCMELT_CC ?= $(or $(CXX),g++) endif GCCMELT_CFLAGS ?= -g -O -Wall $(info MELT plugin for MELTGCC= $(MELTGCC) to be compiled with GCCMELT_CC= $(GCCMELT_CC) \ flags $(GCCMELT_CFLAGS) $(if $(MELTGCC_BUILD_WITH_CXX),built with C++ \ $(MELTGCC_BUILD_WITH_CXX))) ### rest of makefile skipped ############################################################################# but for some reason it does not work. (Maybe a := versus = make variable thing). Do you have any suggestions about such things? Assuming a plugin whose source code should work with both 4.6 & 4.7, how would you autodetect if GCC was compiled in C++ or in C mode? What am I doing wrong? Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GCC-MELT-386] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues) 2012-03-29 20:02 pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues) Basile Starynkevitch @ 2012-03-29 20:45 ` Romain Geissler 2012-03-29 21:03 ` [GCC-MELT-387] " Basile Starynkevitch 2012-04-02 10:31 ` Announce: MELT 0.9.5rc2 release candidate (for GCC 4.6 and 4.7) Basile Starynkevitch 1 sibling, 1 reply; 18+ messages in thread From: Romain Geissler @ 2012-03-29 20:45 UTC (permalink / raw) To: gcc-melt; +Cc: gcc Le 29 mars 2012 à 22:02, Basile Starynkevitch a écrit : > > Hello All, > > The pre-release candidate 1 of MELT 0.9.5 is available for testing on > http://gcc-melt.org/melt-0.9.5rc1-plugin-for-gcc-4.6-or-4.7.tar.gz > as a gzipped tar archive of 4473286 bytes and md5sum ae00b9bd31f481e1bbc406711ca4c2f4. > extracted from MELT branch 185969, march 29th 2012 > > You could try building it e.g. with > make MELTGCC=gcc-4.7 GCCMELT_CC=gcc-4.7 > It seems to be also buildable for GCC 4.6 with > make MELTGCC=gcc-4.6 GCCMELT_CC=gcc-4.6 > > (both commands sort of work, with perhaps minor issues very late in the build process; > I'm not very afraid of these) > > But I'm trying to code a makefile which would autodetect in GCC 4.7 was compiled in C++ > mode (or if the GCC was compiled in C mode, then it is probably a 4.6 or a 4.7 > configured in a weird fashion). > > So far I tried to code in my Makefile the following trick > ############################################################################ > ## the compiler with which melt.so is used > ifndef MELTGCC > MELTGCC = $(or $(CC),gcc) > endif > > ## gives yes if MELTGCC has been built with C++ or else the empty string > MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define +ENABLE_BUILD_WITH_CXX +1' \ > `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes) > > ## The compiler and flags used to build the melt.so plugin and to > ## compile MELT generated code. Notice that melt-module.mk use the > ## same Make variables. For a melt plugin to GCC 4.7 or later, that > ## could be a C++ compiler! eg > ## make MELTGCC=gcc-4.7 GCCMELT_CC=g++-4.7 > ## hence we add a test if $(MELTGCC) was built with C++ or with C > ifeq ($(strip $(MELTGCC_BUILD_WITH_CXX)),) > GCCMELT_CC ?= $(or $(CC),gcc) -Wc++-compat > else > GCCMELT_CC ?= $(or $(CXX),g++) > endif > > GCCMELT_CFLAGS ?= -g -O -Wall > > $(info MELT plugin for MELTGCC= $(MELTGCC) to be compiled with GCCMELT_CC= $(GCCMELT_CC) \ > flags $(GCCMELT_CFLAGS) $(if $(MELTGCC_BUILD_WITH_CXX),built with C++ \ > $(MELTGCC_BUILD_WITH_CXX))) > ### rest of makefile skipped > ############################################################################# > > but for some reason it does not work. (Maybe a := versus = make variable thing). > > Do you have any suggestions about such things? Assuming a plugin whose source code > should work with both 4.6 & 4.7, how would you autodetect if GCC was compiled in C++ or > in C mode? What am I doing wrong? > > Regards. > -- > Basile STARYNKEVITCH http://starynkevitch.net/Basile/ > email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 > 8, rue de la Faiencerie, 92340 Bourg La Reine, France > *** opinions {are only mine, sont seulement les miennes} *** > > -- > Message from the http://groups.google.com/group/gcc-melt group. > About GCC MELT http://gcc-melt.org/ a high level domain specific language to code extensions to the Gnu Compiler Collection Hi, You almost got it. You simply need to backslash escape the '+' operator in your regexp. Also, it would be welcome to allow any blank chars to separate words, not any the space char (\t for example). Thus, i changed space ' ' by [[:space:]] (tested with GNU grep). MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \ `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes) Anyway, as i already told you, you don't look for gengtype and gtype.state at the right place. Romain Geissler ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GCC-MELT-387] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues) 2012-03-29 20:45 ` [GCC-MELT-386] " Romain Geissler @ 2012-03-29 21:03 ` Basile Starynkevitch 2012-03-29 21:29 ` Romain Geissler 0 siblings, 1 reply; 18+ messages in thread From: Basile Starynkevitch @ 2012-03-29 21:03 UTC (permalink / raw) To: gcc-melt; +Cc: Romain Geissler, gcc On Thu, 29 Mar 2012 22:45:27 +0200 Romain Geissler <romain.geissler@gmail.com> wrote: > MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \ > `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes) > Thanks; I applied that patch with 2012-03-29 Romain Geissler <romain.geissler@gmail.com> * MELT-Plugin-Makefile (MELTGCC_BUILD_WITH_CXX): Better grep. (I will test it tomorrow) Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GCC-MELT-387] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues) 2012-03-29 21:03 ` [GCC-MELT-387] " Basile Starynkevitch @ 2012-03-29 21:29 ` Romain Geissler 2012-03-30 5:22 ` Basile Starynkevitch 2012-03-30 9:41 ` MELT 0.9.5rc1 etc Basile Starynkevitch 0 siblings, 2 replies; 18+ messages in thread From: Romain Geissler @ 2012-03-29 21:29 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: gcc-melt, gcc Le 29 mars 2012 à 23:03, Basile Starynkevitch a écrit : > On Thu, 29 Mar 2012 22:45:27 +0200 > Romain Geissler <romain.geissler@gmail.com> wrote: > >> MELTGCC_BUILD_WITH_CXX = $(shell grep -q 'define[[:space:]]\+ENABLE_BUILD_WITH_CXX[[:space:]]\+1' \ >> `$(MELTGCC) -print-file-name=plugin/include/auto-host.h` && echo yes) >> > > Thanks; I applied that patch with > > > 2012-03-29 Romain Geissler <romain.geissler@gmail.com> > * MELT-Plugin-Makefile (MELTGCC_BUILD_WITH_CXX): Better grep. > > > (I will test it tomorrow) > Cheers. You've made a typo will copy/pasting part of the line. Look at the dollar $ char near '=$ (shell)', the space is misplaced. It should be '= $(shell'. Romain Geissler ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GCC-MELT-387] pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues) 2012-03-29 21:29 ` Romain Geissler @ 2012-03-30 5:22 ` Basile Starynkevitch 2012-03-30 9:41 ` MELT 0.9.5rc1 etc Basile Starynkevitch 1 sibling, 0 replies; 18+ messages in thread From: Basile Starynkevitch @ 2012-03-30 5:22 UTC (permalink / raw) To: Romain Geissler; +Cc: gcc-melt, gcc On Thu, 29 Mar 2012 23:29:40 +0200 Romain Geissler <romain.geissler@gmail.com> wrote: > > You've made a typo will copy/pasting part of the line. Look at the dollar $ char > near '=$ (shell)', the space is misplaced. It should be '= $(shell'. Thanks! Corrected. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 18+ messages in thread
* MELT 0.9.5rc1 etc... 2012-03-29 21:29 ` Romain Geissler 2012-03-30 5:22 ` Basile Starynkevitch @ 2012-03-30 9:41 ` Basile Starynkevitch 2012-03-31 0:23 ` [GCC-MELT-391] " Romain Geissler 1 sibling, 1 reply; 18+ messages in thread From: Basile Starynkevitch @ 2012-03-30 9:41 UTC (permalink / raw) To: gcc-melt; +Cc: Basile Starynkevitch, gcc Hello If you want to help me on the makefile issues for the next MELT plugin release 0.9.5, please extract the MELT plugin from the svn repository, since I am making small changes (which still don't work) since 0.9.5rc1 The procedure to extract the MELT plugin from the MELT brannch is: Retrieve the MELT branch if you don't have it svn co svn://gcc.gnu.org/svn/gcc/branches/melt-branch gcc-melt Go into it cd gcc-melt Run the update to be sure to have the latest SVN & to gernerate the REVISION etc files ./contrib/gcc_update Run the following script to get the MELT plugin tarball ./contrib/make-melt-source-tar.sh $PWD /tmp/meltplugin You now should have a /tmp/meltplugin.tar.gz which is the MELT plugin tarball corresponding to your state of the MELT branch Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GCC-MELT-391] MELT 0.9.5rc1 etc... 2012-03-30 9:41 ` MELT 0.9.5rc1 etc Basile Starynkevitch @ 2012-03-31 0:23 ` Romain Geissler 2012-03-31 7:08 ` Basile Starynkevitch 0 siblings, 1 reply; 18+ messages in thread From: Romain Geissler @ 2012-03-31 0:23 UTC (permalink / raw) To: gcc-melt; +Cc: Basile Starynkevitch, gcc [-- Attachment #1: Type: text/plain, Size: 1951 bytes --] Le 30 mars 2012 à 11:40, Basile Starynkevitch a écrit : > Hello > > If you want to help me on the makefile issues for the next MELT plugin > release 0.9.5, please extract the MELT plugin from the svn repository, since > I am making small changes (which still don't work) since 0.9.5rc1 > > The procedure to extract the MELT plugin from the MELT brannch is: > > Retrieve the MELT branch if you don't have it > > svn co svn://gcc.gnu.org/svn/gcc/branches/melt-branch gcc-melt > > Go into it > > cd gcc-melt > > Run the update to be sure to have the latest SVN & to gernerate the REVISION > etc files > > ./contrib/gcc_update > > Run the following script to get the MELT plugin tarball > > ./contrib/make-melt-source-tar.sh $PWD /tmp/meltplugin > > You now should have a /tmp/meltplugin.tar.gz which is the MELT plugin > tarball corresponding to your state of the MELT branch > > Regards. > -- > Basile STARYNKEVITCH http://starynkevitch.net/Basile/ > email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 > 8, rue de la Faiencerie, 92340 Bourg La Reine, France > *** opinions {are only mines, sont seulement les miennes} *** > Hi, I tried to build the latest melt-branch (not the generated tarball) on a mac. Here is the few change required to allow the build (note that it builds but as your cc/cxx detection still fails, the generated melt-runtime.o and *.so files can't be loaded with gcc build with cxx). I removed the test of _POSIX_C_SOURCE in melt-runtime.c because this makes no sense to test the availability of the poll function that way : just use the function, the compiler will find it out by itself if it is really defined. Moreover, this kind of test should be in a configure file, not in a source file. On a mac, _POSIX_C_SOURCE is not defined by default, and defining it lead to errors while building other parts of GCC. Romain Geissler [-- Attachment #2: melt-mac-build.Changelog --] [-- Type: application/octet-stream, Size: 216 bytes --] 2012-03-31 Romain Geissler <romain.geissler@gmail.com> * melt-build.tpl: Use AWK instead of GAWK. * melt-module.mk: Likewise. * melt-build.mk: Regenerate. * melt-runtime.c: Do not check _POSIX_C_SOURCE value. [-- Attachment #3: melt-mac-build.diff --] [-- Type: application/octet-stream, Size: 14717 bytes --] diff --git gcc/melt-build.mk gcc/melt-build.mk index 3aa9011..4218b1d 100644 --- gcc/melt-build.mk +++ gcc/melt-build.mk @@ -3,7 +3,7 @@ #@#@# #@#@# DO NOT EDIT THIS FILE (melt-build.mk) #@#@# -#@#@# It has been AutoGen-ed March 30, 2012 at 10:56:40 AM by AutoGen 5.12 +#@#@# It has been AutoGen-ed March 31, 2012 at 01:19:19 AM by AutoGen 5.11.1 #@#@# From the definitions melt-build.def #@#@# and the template file melt-build.tpl ##@@ melt-build.mk is generated from melt-build.tpl by 'autogen melt-build.def' @@ -21,7 +21,7 @@ # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # -#@ from melt-build.tpl line 22 generated by Autogen 5.12 using melt-build.def +#@ from melt-build.tpl line 22 generated by Autogen 5.11.1 using melt-build.def ## See http://stackoverflow.com/q/8727896/841108 ## and http://lists.gnu.org/archive/html/help-make/2012-01/msg00017.html ## and http://gcc.gnu.org/ml/gcc/2012-01/msg00089.html @@ -131,8 +131,8 @@ endif ## LN_S might not be defined, e.g. in MELT-Plugin-Makefile from melt-build.tpl line 71 LN_S ?= ln -sv -## GAWK is needed, the GNU awk from melt-build.tpl line 74 -GAWK ?= gawk +## AWK is needed from melt-build.tpl line 74 +AWK ?= awk ## the md5sum utility is needed from melt-build.tpl line 77 MD5SUM ?= md5sum @@ -241,7 +241,7 @@ MELT_ZERO_GENERATED_FIRST_BASE= \ $(basename $(notdir $(MELT_GENERATED_FIRST_C_FILES))) # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171 ## avoid spaces in MELT_GENERATED_FIRST_CUMULMD5 below from melt-build.tpl line 172 -MELT_ZERO_GENERATED_FIRST_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-first+meltdesc.c) +MELT_ZERO_GENERATED_FIRST_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-first+meltdesc.c) #@ The C files of the stage 0 are deposited from melt-build.tpl line 164 MELT_ZERO_GENERATED_BASE_C_FILES= \ @@ -252,7 +252,7 @@ MELT_ZERO_GENERATED_BASE_BASE= \ $(basename $(notdir $(MELT_GENERATED_BASE_C_FILES))) # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171 ## avoid spaces in MELT_GENERATED_BASE_CUMULMD5 below from melt-build.tpl line 172 -MELT_ZERO_GENERATED_BASE_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-base+meltdesc.c) +MELT_ZERO_GENERATED_BASE_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-base+meltdesc.c) #@ The C files of the stage 0 are deposited from melt-build.tpl line 164 MELT_ZERO_GENERATED_DEBUG_C_FILES= \ @@ -263,7 +263,7 @@ MELT_ZERO_GENERATED_DEBUG_BASE= \ $(basename $(notdir $(MELT_GENERATED_DEBUG_C_FILES))) # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171 ## avoid spaces in MELT_GENERATED_DEBUG_CUMULMD5 below from melt-build.tpl line 172 -MELT_ZERO_GENERATED_DEBUG_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-debug+meltdesc.c) +MELT_ZERO_GENERATED_DEBUG_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-debug+meltdesc.c) #@ The C files of the stage 0 are deposited from melt-build.tpl line 164 MELT_ZERO_GENERATED_MACRO_C_FILES= \ @@ -274,7 +274,7 @@ MELT_ZERO_GENERATED_MACRO_BASE= \ $(basename $(notdir $(MELT_GENERATED_MACRO_C_FILES))) # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171 ## avoid spaces in MELT_GENERATED_MACRO_CUMULMD5 below from melt-build.tpl line 172 -MELT_ZERO_GENERATED_MACRO_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-macro+meltdesc.c) +MELT_ZERO_GENERATED_MACRO_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-macro+meltdesc.c) #@ The C files of the stage 0 are deposited from melt-build.tpl line 164 MELT_ZERO_GENERATED_NORMAL_C_FILES= \ @@ -285,7 +285,7 @@ MELT_ZERO_GENERATED_NORMAL_BASE= \ $(basename $(notdir $(MELT_GENERATED_NORMAL_C_FILES))) # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171 ## avoid spaces in MELT_GENERATED_NORMAL_CUMULMD5 below from melt-build.tpl line 172 -MELT_ZERO_GENERATED_NORMAL_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-normal+meltdesc.c) +MELT_ZERO_GENERATED_NORMAL_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-normal+meltdesc.c) #@ The C files of the stage 0 are deposited from melt-build.tpl line 164 MELT_ZERO_GENERATED_NORMATCH_C_FILES= \ @@ -296,7 +296,7 @@ MELT_ZERO_GENERATED_NORMATCH_BASE= \ $(basename $(notdir $(MELT_GENERATED_NORMATCH_C_FILES))) # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171 ## avoid spaces in MELT_GENERATED_NORMATCH_CUMULMD5 below from melt-build.tpl line 172 -MELT_ZERO_GENERATED_NORMATCH_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-normatch+meltdesc.c) +MELT_ZERO_GENERATED_NORMATCH_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-normatch+meltdesc.c) #@ The C files of the stage 0 are deposited from melt-build.tpl line 164 MELT_ZERO_GENERATED_GENOBJ_C_FILES= \ @@ -307,7 +307,7 @@ MELT_ZERO_GENERATED_GENOBJ_BASE= \ $(basename $(notdir $(MELT_GENERATED_GENOBJ_C_FILES))) # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171 ## avoid spaces in MELT_GENERATED_GENOBJ_CUMULMD5 below from melt-build.tpl line 172 -MELT_ZERO_GENERATED_GENOBJ_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-genobj+meltdesc.c) +MELT_ZERO_GENERATED_GENOBJ_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-genobj+meltdesc.c) #@ The C files of the stage 0 are deposited from melt-build.tpl line 164 MELT_ZERO_GENERATED_OUTOBJ_C_FILES= \ @@ -318,7 +318,7 @@ MELT_ZERO_GENERATED_OUTOBJ_BASE= \ $(basename $(notdir $(MELT_GENERATED_OUTOBJ_C_FILES))) # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171 ## avoid spaces in MELT_GENERATED_OUTOBJ_CUMULMD5 below from melt-build.tpl line 172 -MELT_ZERO_GENERATED_OUTOBJ_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-outobj+meltdesc.c) +MELT_ZERO_GENERATED_OUTOBJ_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-outobj+meltdesc.c) #@ The C files of the stage 0 are deposited from melt-build.tpl line 164 MELT_ZERO_GENERATED_MODES_C_FILES= \ @@ -329,7 +329,7 @@ MELT_ZERO_GENERATED_MODES_BASE= \ $(basename $(notdir $(MELT_GENERATED_MODES_C_FILES))) # for stage 0 files, we don't compute the checksum, we extract what was deposited from melt-build.tpl line 171 ## avoid spaces in MELT_GENERATED_MODES_CUMULMD5 below from melt-build.tpl line 172 -MELT_ZERO_GENERATED_MODES_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-modes+meltdesc.c) +MELT_ZERO_GENERATED_MODES_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/warmelt-modes+meltdesc.c) #@ the required work directory from melt-build.tpl line 176 diff --git gcc/melt-build.tpl gcc/melt-build.tpl index ebdb4b5..c55ae24 100644 --- gcc/melt-build.tpl +++ gcc/melt-build.tpl @@ -71,8 +71,8 @@ endif ## LN_S might not be defined, e.g. in MELT-Plugin-Makefile [+ (. (tpl-file-line))+] LN_S ?= ln -sv -## GAWK is needed, the GNU awk [+ (. (tpl-file-line))+] -GAWK ?= gawk +## AWK is needed [+ (. (tpl-file-line))+] +AWK ?= awk ## the md5sum utility is needed [+ (. (tpl-file-line))+] MD5SUM ?= md5sum @@ -170,7 +170,7 @@ MELT_ZERO_GENERATED_[+mkvarsuf+]_BASE= \ $(basename $(notdir $(MELT_GENERATED_[+mkvarsuf+]_C_FILES))) # for stage 0 files, we don't compute the checksum, we extract what was deposited [+ (. (tpl-file-line))+] ## avoid spaces in MELT_GENERATED_[+mkvarsuf+]_CUMULMD5 below [+ (. (tpl-file-line))+] -MELT_ZERO_GENERATED_[+mkvarsuf+]_CUMULMD5:=$(shell $(GAWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/[+base+]+meltdesc.c) +MELT_ZERO_GENERATED_[+mkvarsuf+]_CUMULMD5:=$(shell $(AWK) -F\" '/extern/{next} /melt_cumulated_hexmd5/{print $$2}' $(melt_make_source_dir)/generated/[+base+]+meltdesc.c) [+ENDFOR melt_translator_file+] #@ the required work directory [+ (. (tpl-file-line))+] diff --git gcc/melt-module.mk gcc/melt-module.mk index fedb20a..78dae26 100644 --- gcc/melt-module.mk +++ gcc/melt-module.mk @@ -72,10 +72,8 @@ ifeq ($(findstring $(GCCMELT_MODULE_FLAVOR),optimized quicklybuilt debugnoline d $(error invalid GCCMELT_MODULE_FLAVOR $(GCCMELT_MODULE_FLAVOR)) endif -### GNU awk is required -ifndef GAWK -GAWK=gawk -endif +### awk is required +AWK?=awk ## The md5sum command is required MD5SUM ?= md5sum @@ -90,6 +88,12 @@ GCCMELT_CC ?= $(firstword $(GCC) gcc) GCCMELT_BASE=$(notdir $(basename $(GCCMELT_MODULE_SOURCEBASE))) GCCMELT_SOURCEDIR=$(dir $(GCCMELT_MODULE_SOURCEBASE)) +ifeq ($(shell uname),Darwin) +SHARED_LIBRARY_FLAGS=-bundle -undefined dynamic_lookup +else +SHARED_LIBRARY_FLAGS=-shared +endif + ## these flags should only affect the quality of the generated ## binaries. No preprocessor flags please here! GCCMELT_OPTIMIZED_FLAGS ?= -O1 @@ -105,16 +109,16 @@ $(error Did not found MELT primary file $(GCCMELT_MODULE_SOURCEBASE).c) endif ## the md5 checksum of the primary file -GCCMELT_PRIMARYMD5:= $(shell $(MD5SUM) $(GCCMELT_PRIMARY) | $(GAWK) '{print $$1}') +GCCMELT_PRIMARYMD5:= $(shell $(MD5SUM) $(GCCMELT_PRIMARY) | $(AWK) '{print $$1}') ## the secondary C files, in order GCCMELT_SECONDARIES= $(sort $(wildcard $(GCCMELT_MODULE_SOURCEBASE)+[09]*.c)) ## the corresponding checksums GCCMELT_SECONDARIES_MD5:= $(if $(GCCMELT_SECONDARIES), \ - $(shell $(MD5SUM) $(GCCMELT_SECONDARIES) | $(GAWK) '{print $$1}')) + $(shell $(MD5SUM) $(GCCMELT_SECONDARIES) | $(AWK) '{print $$1}')) ## the cumulated checksum -GCCMELT_CUMULATED_MD5 ?= $(shell cat $(GCCMELT_PRIMARY) $(GCCMELT_SECONDARIES) | $(MD5SUM) | $(GAWK) '{print $$1}') +GCCMELT_CUMULATED_MD5 ?= $(shell cat $(GCCMELT_PRIMARY) $(GCCMELT_SECONDARIES) | $(MD5SUM) | $(AWK) '{print $$1}') ## the primary object basename GCCMELT_PRIMARY_OBJ:= $(basename $(notdir $(GCCMELT_PRIMARY))).$(GCCMELT_PRIMARYMD5) @@ -161,7 +165,7 @@ $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).optimized.s GCCMELT_MODULE_WORKSPACE=$(GCCMELT_MODULE_WORKSPACE) \ GCCMELT_MODULE_FLAVOR=$(GCCMELT_MODULE_FLAVOR) \ GCCMELT_CUMULATED_MD5=$(GCCMELT_CUMULATED_MD5) - $(GCCMELT_CC) $(GCCMELT_OPTIMIZED_FLAGS) $(GCCMELT_CFLAGS) -fPIC -shared -o $@ $^ $(GCCMELT_MODULE_EXTRALIBES) + $(GCCMELT_CC) $(GCCMELT_OPTIMIZED_FLAGS) $(GCCMELT_CFLAGS) -fPIC $(SHARED_LIBRARY_FLAGS) -o $@ $^ $(GCCMELT_MODULE_EXTRALIBES) $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).dynamic.so: \ $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_PRIMARY_OBJ).dynamic.pic.o \ @@ -173,7 +177,7 @@ $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).dynamic.so: GCCMELT_MODULE_WORKSPACE=$(GCCMELT_MODULE_WORKSPACE) \ GCCMELT_MODULE_FLAVOR=$(GCCMELT_MODULE_FLAVOR) \ GCCMELT_CUMULATED_MD5=$(GCCMELT_CUMULATED_MD5) - $(GCCMELT_CC) $(GCCMELT_DYNAMIC_FLAGS) $(GCCMELT_CFLAGS) -fPIC -shared -o $@ $^ $(GCCMELT_MODULE_EXTRALIBES) + $(GCCMELT_CC) $(GCCMELT_DYNAMIC_FLAGS) $(GCCMELT_CFLAGS) -fPIC $(SHARED_LIBRARY_FLAGS) -o $@ $^ $(GCCMELT_MODULE_EXTRALIBES) $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).quicklybuilt.so: \ $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_PRIMARY_OBJ).quicklybuilt.pic.o \ @@ -185,7 +189,7 @@ $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).quicklybuil GCCMELT_MODULE_WORKSPACE=$(GCCMELT_MODULE_WORKSPACE) \ GCCMELT_MODULE_FLAVOR=$(GCCMELT_MODULE_FLAVOR) \ GCCMELT_CUMULATED_MD5=$(GCCMELT_CUMULATED_MD5) - $(GCCMELT_CC) $(GCCMELT_QUICKLYBUILT_FLAGS) $(GCCMELT_CFLAGS) -fPIC -shared -o $@ $^ $(GCCMELT_MODULE_EXTRALIBES) + $(GCCMELT_CC) $(GCCMELT_QUICKLYBUILT_FLAGS) $(GCCMELT_CFLAGS) -fPIC $(SHARED_LIBRARY_FLAGS) -o $@ $^ $(GCCMELT_MODULE_EXTRALIBES) $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).debugnoline.so: \ @@ -198,7 +202,7 @@ $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).debugnoline GCCMELT_MODULE_WORKSPACE=$(GCCMELT_MODULE_WORKSPACE) \ GCCMELT_MODULE_FLAVOR=$(GCCMELT_MODULE_FLAVOR) \ GCCMELT_CUMULATED_MD5=$(GCCMELT_CUMULATED_MD5) - $(GCCMELT_CC) $(GCCMELT_DEBUGNOLINE_FLAGS) $(GCCMELT_CFLAGS) -fPIC -shared -o $@ $^ $(GCCMELT_MODULE_EXTRALIBES) + $(GCCMELT_CC) $(GCCMELT_DEBUGNOLINE_FLAGS) $(GCCMELT_CFLAGS) -fPIC $(SHARED_LIBRARY_FLAGS) -o $@ $^ $(GCCMELT_MODULE_EXTRALIBES) $(GCCMELT_MODULE_BINARYBASE).$(GCCMELT_MODULE_FLAVOR).so: $(GCCMELT_MODULE_WORKSPACE)/$(GCCMELT_BASE).$(GCCMELT_CUMULATED_MD5).$(GCCMELT_MODULE_FLAVOR).so diff --git gcc/melt-runtime.c gcc/melt-runtime.c index 87168cb..b81b454 100644 --- gcc/melt-runtime.c +++ gcc/melt-runtime.c @@ -13306,9 +13306,6 @@ meltgc_poll_inputs (melt_ptr_t inbuck_p, int delayms) #define seqv meltfram__.mcfr_varptr[3] #define closv meltfram__.mcfr_varptr[4] MELT_LOCATION_HERE("meltgc_poll_inputs"); -#if _POSIX_C_SOURCE < 200112L -#error meltgc_poll_inputs need a Posix 2001 system with poll -#endif /* _POSIX_C_SOURCE < 200112L */ inbuckv = inbuck_p; if (melt_magic_discr ((melt_ptr_t) inbuckv) != MELTOBMAG_BUCKETLONGS) goto end; [-- Attachment #4: Type: text/plain, Size: 3 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GCC-MELT-391] MELT 0.9.5rc1 etc... 2012-03-31 0:23 ` [GCC-MELT-391] " Romain Geissler @ 2012-03-31 7:08 ` Basile Starynkevitch 2012-03-31 8:52 ` Romain Geissler 0 siblings, 1 reply; 18+ messages in thread From: Basile Starynkevitch @ 2012-03-31 7:08 UTC (permalink / raw) To: Romain Geissler; +Cc: gcc-melt, gcc On Sat, 31 Mar 2012 02:22:43 +0200 Romain Geissler <romain.geissler@gmail.com> wrote: > > I tried to build the latest melt-branch (not the generated tarball) on a mac. > Here is the few change required to allow the build (note that it builds but as your > cc/cxx detection still fails, the generated melt-runtime.o and *.so files can't be > loaded with gcc build with cxx). Thanks! But please patch melt-build.tpl, not melt-build.mk which is autogen generated. > > I removed the test of _POSIX_C_SOURCE in melt-runtime.c because this > makes no sense to test the availability of the poll function that way : just use > the function, the compiler will find it out by itself if it is really defined. Moreover, > this kind of test should be in a configure file, not in a source file. On a mac, > _POSIX_C_SOURCE is not defined by default, and defining it lead to errors > while building other parts of GCC. Do you have any ideas on how to make autoconf things for the MELT plugin? Also, I was believing MacOSX needs *dylib files not *so one ? Thanks, cheers -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GCC-MELT-391] MELT 0.9.5rc1 etc... 2012-03-31 7:08 ` Basile Starynkevitch @ 2012-03-31 8:52 ` Romain Geissler 2012-03-31 10:28 ` Basile Starynkevitch 0 siblings, 1 reply; 18+ messages in thread From: Romain Geissler @ 2012-03-31 8:52 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: gcc-melt, gcc Le 31 mars 2012 à 09:07, Basile Starynkevitch a écrit : > On Sat, 31 Mar 2012 02:22:43 +0200 > Romain Geissler <romain.geissler@gmail.com> wrote: > >> >> I tried to build the latest melt-branch (not the generated tarball) on a mac. >> Here is the few change required to allow the build (note that it builds but as your >> cc/cxx detection still fails, the generated melt-runtime.o and *.so files can't be >> loaded with gcc build with cxx). > > Thanks! But please patch melt-build.tpl, not melt-build.mk which is autogen generated. Well I know it's autogenerated, that's why i wrote 'Regenerate.' in the Changelog. In such cases, i should not include the regenerated file to the patch ? Is it the maintainer role to run autogen on every patch that affects *.tpl ? >> >> I removed the test of _POSIX_C_SOURCE in melt-runtime.c because this >> makes no sense to test the availability of the poll function that way : just use >> the function, the compiler will find it out by itself if it is really defined. Moreover, >> this kind of test should be in a configure file, not in a source file. On a mac, >> _POSIX_C_SOURCE is not defined by default, and defining it lead to errors >> while building other parts of GCC. > > Do you have any ideas on how to make autoconf things for the MELT plugin? Well I currently don't know, although i already patched the GCC configuration scripts. It's like all, just need to learn. > > Also, I was believing MacOSX needs *dylib files not *so one ? Yes dynamic libraries are named *.dylib on a mac because the dynamic linker dyld looks for *.dylib files, and not *.so files. OSX makes a difference between a dynamic library you can link (*.dylib) width dyld and binaries you dynamically load on your own with dlopen (*.bundle). So on a mac, your melt plugins should have the .bundle extension. But as the .so extension is hardcoded almost everywhere, i preferred keeping the .so extension, like many other projects do (on my computer, i can see that apache, php, valgrind, ImageMagick, python, gtk and many others just do the same) Romain Geissler ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GCC-MELT-391] MELT 0.9.5rc1 etc... 2012-03-31 8:52 ` Romain Geissler @ 2012-03-31 10:28 ` Basile Starynkevitch 2012-03-31 11:55 ` Romain Geissler 0 siblings, 1 reply; 18+ messages in thread From: Basile Starynkevitch @ 2012-03-31 10:28 UTC (permalink / raw) To: Romain Geissler; +Cc: gcc-melt, gcc On Sat, 31 Mar 2012 10:52:09 +0200 Romain Geissler <romain.geissler@gmail.com> wrote: > > Le 31 mars 2012 à 09:07, Basile Starynkevitch a écrit : > > > On Sat, 31 Mar 2012 02:22:43 +0200 > > Romain Geissler <romain.geissler@gmail.com> wrote: > > > >> > >> I tried to build the latest melt-branch (not the generated tarball) on a mac. > >> Here is the few change required to allow the build (note that it builds but as your > >> cc/cxx detection still fails, the generated melt-runtime.o and *.so files can't be > >> loaded with gcc build with cxx). > > > > Thanks! But please patch melt-build.tpl, not melt-build.mk which is autogen generated. Sorry, my apologies, I didn't saw the patch to melt-build.tpl later in your diff. > Well I know it's autogenerated, that's why i wrote 'Regenerate.' in the Changelog. > In such cases, i should not include the regenerated file to the patch ? Is it the > maintainer role to run autogen on every patch that affects *.tpl ? the melt-build.mk is generated from melt-build.tpl & melt-build.def; after running autogen which generates melt-build.mk in the source tree, we can svn commit. This is exactly the same practice as for configure generated from configure.ac in the trunk. Contributors patch configure.ac, regenerate configure (both in the source tree) and then svn commit (after patch approval) both. For MELT, the translator itself (files gcc/melt/generated/{warmelt*.[ch]) and some parts of the runtime (files gcc/melt/generated/meltrunsup*.[ch]) are also generated and svn commit-ed in the trunk. FYI I use make upgrade-warmelt to regenerate them. I am surprised of your patch which indeed contains gcc/melt-build.tpl: -## GAWK is needed, the GNU awk [+ (. (tpl-file-line))+] -GAWK ?= gawk +## AWK is needed [+ (. (tpl-file-line))+] +AWK ?= awk I really need GNU awk (and I may depend upon GNU extensions of awk). AFAIK, GCC also requires *GNU* awk specifically (and not some other awk). Why the above patch? If GNU awk is called awk on MacOS (like it is on some Linux distributions) just call it still GAWK in makefile things! I'm pretty sure to not be the only one with this convention, that GAWK in Makefile meen that GNU extensions of awk is necessary. A more general question is the status of plugins on MacOSX. I thought that GCC plugins in general only work for ELF shared object systems with dlopen. It seems that gcc/plugin.c is hardwiring the ".so" suffix in function add_new_plugin. Can an unpatched GCC 4.7 (FSF distributed) be built on MacOSX with plugins enabled and working? Does dlopen as specified by Posix: http://pubs.opengroup.org/onlinepubs/009695399/functions/dlopen.html etc work on MacOSX (in particular when file is NULL and mode contains RTLD_GLOBAL)? What kind of file extension does it requires or appends: *.bundle, *.dylib or *.so on MacOSX? If you think that plugins can easily be made working on MacOSX, please patch plugin.c first if needed (and propose that to the trunk), by taking care of at least naming the suffix needed for them (in a publicly available header exported to plugins), then melt-runtime.h could use that. This .so suffix is hardwired in melt-runtime.c; I am adding MELT_DYNLOADED_SUFFIX constant to help going to systems with other dlopen-ed dynamic libraries suffixes. I added your SHARED_LIBRARY_FLAGS patch into melt-module.mk I sadly think that MELT plugin would need autoconf things to be workable on non Linux systems. But I really don't know autoconf (actually, I hate it) and don't know how to start working on that. Can you help? I just commited svn rev 186039 of MELT branch with some of your and mine changes. I still need to replace the occurrences of .so in the MELT code itself. Thanks. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GCC-MELT-391] MELT 0.9.5rc1 etc... 2012-03-31 10:28 ` Basile Starynkevitch @ 2012-03-31 11:55 ` Romain Geissler 2012-03-31 12:03 ` Romain Geissler 0 siblings, 1 reply; 18+ messages in thread From: Romain Geissler @ 2012-03-31 11:55 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: gcc-melt, gcc Le 31 mars 2012 à 12:27, Basile Starynkevitch a écrit : > I am surprised of your patch which indeed contains gcc/melt-build.tpl: > > -## GAWK is needed, the GNU awk [+ (. (tpl-file-line))+] > -GAWK ?= gawk > +## AWK is needed [+ (. (tpl-file-line))+] > +AWK ?= awk > > > I really need GNU awk (and I may depend upon GNU extensions of awk). AFAIK, GCC also > requires *GNU* awk specifically (and not some other awk). Why the above patch? If GNU awk > is called awk on MacOS (like it is on some Linux distributions) just call it still GAWK in > makefile things! I'm pretty sure to not be the only one with this convention, that GAWK in > Makefile meen that GNU extensions of awk is necessary. Are you sure you really need GNU awk ? I don't think so ! In my patch, i replaced every GAWK uses in Melt (only the melt files that you ship in the packaged version of Melt, there are still somes instances of Gawk in /contrib/MELT-Plugin-Makefile and in /contrib/build-melt-plugin.sh but those are only for packagers, not for melt users). The gawk usage i replaced were trivial uses that DO NOT use specific GNU awk features (on printing and using the {next} command). I've take a look at the different GCC configure scripts, and it only looks for one awk implementation in that order : for ac_prog in gawk mawk nawk awk. There is no further check performed to know if it is GNU awk or not, as all uses are conforming to the common awk specifications. You may fix my patch so that it first looks for gawk, then mawk, then nawk then finally awk. But again i'd better see this kind of test in a configure script. Usually, if one awk program exists (may it be gawk, mawk or nawk) then awk will also do (typically a symlink to the right executable). On a mac, only the classical awk version is shipped by default by Apple, not GNU awk. > A more general question is the status of plugins on MacOSX. I thought that GCC plugins in > general only work for ELF shared object systems with dlopen. It seems that gcc/plugin.c > is hardwiring the ".so" suffix in function add_new_plugin. Can an unpatched GCC 4.7 (FSF > distributed) be built on MacOSX with plugins enabled and working? Plugins works fine on Darwin with an unpatched GCC 4.6 or 4.7, you just need to know that building a bundle is made with -bundle -undefined dynamic_lookup instead of -shared. My plugins work, and so does Dragon Egg in the LLVM project. > Does dlopen as > specified by Posix: http://pubs.opengroup.org/onlinepubs/009695399/functions/dlopen.html > etc work on MacOSX (in particular when file is NULL and mode contains RTLD_GLOBAL)? From the man page shipped by Apple, i see : If a null pointer is passed in path, dlopen() returns a handle equivalent to RTLD_DEFAULT. So i think the uses of dlopen made by gcc and melt might work on a mac. > What > kind of file extension does it requires or appends: *.bundle, *.dylib or *.so on MacOSX? > If you think that plugins can easily be made working on MacOSX, please patch plugin.c > first if needed (and propose that to the trunk), by taking care of at least naming the > suffix needed for them (in a publicly available header exported to plugins), then > melt-runtime.h could use that. No extension is required it could be *.anything. By convention, on Darwin, we should call those files *.bundle. I'll patch gcc so that it looks for *.bundle instead of *.so. We'll see if it's accepted. > This .so suffix is hardwired in melt-runtime.c; I am adding MELT_DYNLOADED_SUFFIX > constant to help going to systems with other dlopen-ed dynamic libraries suffixes. > > I added your SHARED_LIBRARY_FLAGS patch into melt-module.mk > > I sadly think that MELT plugin would need autoconf things to be workable on non Linux > systems. But I really don't know autoconf (actually, I hate it) and don't know how to > start working on that. Can you help? I might help, just need some time. Building properly melt with a much efficient Makefile is more important for now, I thinl. I'll keep my specific OSX change for me for now, until other things work well on ELF platforms (as the only native OS i have is OSX, I don't want to loose time building GCC in a virtual machine). > I just commited svn rev 186039 of MELT branch with some of your and mine changes. > > I still need to replace the occurrences of .so in the MELT code itself. > > Thanks. > -- > Basile STARYNKEVITCH http://starynkevitch.net/Basile/ > email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 > 8, rue de la Faiencerie, 92340 Bourg La Reine, France > *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GCC-MELT-391] MELT 0.9.5rc1 etc... 2012-03-31 11:55 ` Romain Geissler @ 2012-03-31 12:03 ` Romain Geissler 2012-03-31 12:39 ` [GCC-MELT-397] " Basile Starynkevitch 0 siblings, 1 reply; 18+ messages in thread From: Romain Geissler @ 2012-03-31 12:03 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: gcc-melt, gcc Le 31 mars 2012 à 13:55, Romain Geissler a écrit : > > Le 31 mars 2012 à 12:27, Basile Starynkevitch a écrit : > >> I am surprised of your patch which indeed contains gcc/melt-build.tpl: >> >> -## GAWK is needed, the GNU awk [+ (. (tpl-file-line))+] >> -GAWK ?= gawk >> +## AWK is needed [+ (. (tpl-file-line))+] >> +AWK ?= awk >> >> >> I really need GNU awk (and I may depend upon GNU extensions of awk). AFAIK, GCC also >> requires *GNU* awk specifically (and not some other awk). Why the above patch? If GNU awk >> is called awk on MacOS (like it is on some Linux distributions) just call it still GAWK in >> makefile things! I'm pretty sure to not be the only one with this convention, that GAWK in >> Makefile meen that GNU extensions of awk is necessary. > > Are you sure you really need GNU awk ? I don't think so ! In my patch, i replaced every GAWK > uses in Melt (only the melt files that you ship in the packaged version of Melt, there are still > somes instances of Gawk in /contrib/MELT-Plugin-Makefile and in /contrib/build-melt-plugin.sh > but those are only for packagers, not for melt users). The gawk usage i replaced were trivial > uses that DO NOT use specific GNU awk features (on printing and using the {next} command). I forgot to add add that the awk usages you perform are so trivial that grep will also fits your needs and is a lower dependency than awk. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GCC-MELT-397] MELT 0.9.5rc1 etc... 2012-03-31 12:03 ` Romain Geissler @ 2012-03-31 12:39 ` Basile Starynkevitch 2012-03-31 13:07 ` Jonathan Wakely 0 siblings, 1 reply; 18+ messages in thread From: Basile Starynkevitch @ 2012-03-31 12:39 UTC (permalink / raw) To: gcc-melt; +Cc: Romain Geissler, gcc On Sat, 31 Mar 2012 14:02:45 +0200 Romain Geissler <romain.geissler@gmail.com> wrote: > > I forgot to add add that the awk usages you perform are so trivial that grep will also fits your needs > and is a lower dependency than awk. I am not sure of that. MELT need several awk scripts, make-melt-predefh.awk & make-warmelt-predef.awk which probably uses some GNU things. (I think that printf in AWK script is a GNU extension). Cheers -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GCC-MELT-397] MELT 0.9.5rc1 etc... 2012-03-31 12:39 ` [GCC-MELT-397] " Basile Starynkevitch @ 2012-03-31 13:07 ` Jonathan Wakely 2012-03-31 13:56 ` Romain Geissler 0 siblings, 1 reply; 18+ messages in thread From: Jonathan Wakely @ 2012-03-31 13:07 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: gcc-melt, Romain Geissler, gcc On 31 March 2012 13:38, Basile Starynkevitch wrote: > > (I think that printf in AWK script is a GNU extension). Nope, it's standard. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GCC-MELT-397] MELT 0.9.5rc1 etc... 2012-03-31 13:07 ` Jonathan Wakely @ 2012-03-31 13:56 ` Romain Geissler 2012-03-31 14:30 ` Basile Starynkevitch 0 siblings, 1 reply; 18+ messages in thread From: Romain Geissler @ 2012-03-31 13:56 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Basile Starynkevitch, gcc-melt, gcc Le 31 mars 2012 à 15:07, Jonathan Wakely a écrit : > On 31 March 2012 13:38, Basile Starynkevitch wrote: >> >> (I think that printf in AWK script is a GNU extension). > > Nope, it's standard. Yeah it is. I looked at your the melt files in contrib (that's quite strange that the Makefile used to build the melt plugin is located in here through, files in the contrib directory should not be mandatory to build gcc !). It seems that among all your gawk uses, including make-warmelt-predef.awk and make-melt-predefh.awk the only GNU specific feature is strtonum. But you don't need it, as the following works with regular awk : echo 4.7.0 | awk '{split($1,vertab,"."); printf "%d", vertab[1]*1000+vertab[2]}' By looking at your awk calls, i think you've got some errors in MELT-Plugin-Makefile at the following line: MELTGCC_VERSION := $(shell env LANG=C LC_ALL=C $(MELTGCC) -v < /dev/null 2>&1 | $(GAWK) "/^gcc version/{print $$3}") Notice the $$3 at the end, showing you only need the version number. This line currently outputs something like: gcc version 4.7.0 20120115 (experimental) (GCC) If you change double quote by single quote like this: MELTGCC_VERSION := $(shell env LANG=C LC_ALL=C $(MELTGCC) -v < /dev/null 2>&1 | $(GAWK) '/^gcc version/{print $$3}') It'll output: 4.7.0 If you change this, then you'll also have to change this line: echo "$(MELTGCC_VERSION)" | $(GAWK) '{split($$3,vertab,"."); printf "%d", strtonum(vertab[1])*1000+strtonum(vertab[2])}' > $@ to this: echo "$(MELTGCC_VERSION)" | $(GAWK) '{split($$1,vertab,"."); printf "%d", strtonum(vertab[1])*1000+strtonum(vertab[2])}' > $@ (notice $$3 becomes $$1) Romain Geissler ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [GCC-MELT-397] MELT 0.9.5rc1 etc... 2012-03-31 13:56 ` Romain Geissler @ 2012-03-31 14:30 ` Basile Starynkevitch 0 siblings, 0 replies; 18+ messages in thread From: Basile Starynkevitch @ 2012-03-31 14:30 UTC (permalink / raw) To: Romain Geissler; +Cc: Jonathan Wakely, gcc-melt, gcc On Sat, 31 Mar 2012 15:55:50 +0200 Romain Geissler <romain.geissler@gmail.com> wrote: > Le 31 mars 2012 à 15:07, Jonathan Wakely a écrit : > > > On 31 March 2012 13:38, Basile Starynkevitch wrote: > >> > >> (I think that printf in AWK script is a GNU extension). > > > > Nope, it's standard. > > Yeah it is. I looked at your the melt files in contrib (that's quite > strange that the Makefile used to build the melt plugin is > located in here through, files in the contrib directory should > not be mandatory to build gcc !). No, it is not strange: indeed the MELT *branch* has a file contrib/MELT-Plugin-Makefile which is used for the *MELT* plugin (but is useless for the MELT *branch*, which has its own gcc/Makefile.in). But the MELT plugin is not useful for the MELT branch. When you build a gcc-melt from the MELT branch, there is no melt.so file involved, the melt-runtime.o is statically linked inside cc1 (and cc1plus, etc etc...) and the MELT runtime is automagically started as a pseudo-plugin without any dlopen-ing. the MELT initialization phase is indeed dlopen-ing MELT modules (as does the melt.so plugin for a regular GCC), because toplev.c of the MELT branch calls melt_initialize() and melt_finalize(). So, when building the MELT *branch* (which few people do), you don't need or use contrib/MELT-Plugin-Makefile. When I extract the MELT plugin from the MELT branch (e.g. for MELT plugin releases) with the procedure in https://groups.google.com/group/gcc-melt/msg/083091abb7f30c39?hl=en the MELT-Plugin-Makefile is becoming the Makefile for the extracted plugin. But the MELT branch don't need it, so it sits in rightly contrib/MELT-Plugin-Makefile > It seems that among all your gawk uses, including > make-warmelt-predef.awk and make-melt-predefh.awk > the only GNU specific feature is strtonum. But you don't need it, > as the following works with regular awk : > > echo 4.7.0 | awk '{split($1,vertab,"."); printf "%d", vertab[1]*1000+vertab[2]}' > > By looking at your awk calls, i think you've got some errors in > MELT-Plugin-Makefile at the following line: > > MELTGCC_VERSION := $(shell env LANG=C LC_ALL=C $(MELTGCC) -v < /dev/null 2>&1 | $(GAWK) "/^gcc version/{print $$3}") Corrected and commited svn rev 186044. Thanks -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 18+ messages in thread
* Announce: MELT 0.9.5rc2 release candidate (for GCC 4.6 and 4.7) 2012-03-29 20:02 pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues) Basile Starynkevitch 2012-03-29 20:45 ` [GCC-MELT-386] " Romain Geissler @ 2012-04-02 10:31 ` Basile Starynkevitch 2012-04-02 10:35 ` Basile Starynkevitch 1 sibling, 1 reply; 18+ messages in thread From: Basile Starynkevitch @ 2012-04-02 10:31 UTC (permalink / raw) To: gcc-melt; +Cc: gcc Hello All, It is my pleasure to announce the MELT plugin 0.9.5 release candidate 2 for GCC 4.6 or 4.7. ################################################################ NEWS for 0.9.5rc2 MELT plugin for GCC 4.6 & 4.7 [[April 2nd 2012]] release candidate 2 Alternative infix syntax is abandoned (it was never implemented) Accept $(sub sepxr) in macro-string and $[seq sepxr] Handle SIGIO Unix signals with asynchronous input channels (experimental feature) Can be compiled by C++ (since GCC 4.7 often is) All the values are translated to melt_ptr_t variables, not void* ones. ############################################################### I believe it should work for a GCC 4.7 compiled in C++ mode. Thanks to Alexnadre Lissy & Romain Geissler for their help. Please test and report bugs or build success or failure on gcc-melt@googlegroups.com list. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Announce: MELT 0.9.5rc2 release candidate (for GCC 4.6 and 4.7) 2012-04-02 10:31 ` Announce: MELT 0.9.5rc2 release candidate (for GCC 4.6 and 4.7) Basile Starynkevitch @ 2012-04-02 10:35 ` Basile Starynkevitch 0 siblings, 0 replies; 18+ messages in thread From: Basile Starynkevitch @ 2012-04-02 10:35 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: gcc-melt, gcc On Mon, Apr 02, 2012 at 12:30:51PM +0200, Basile Starynkevitch wrote: > Hello All, > > It is my pleasure to announce the MELT plugin 0.9.5 release candidate 2 for GCC 4.6 or 4.7. MELT is a high-level domain specific language to extend GCC > ################################################################ > NEWS for 0.9.5rc2 MELT plugin for GCC 4.6 & 4.7 > [[April 2nd 2012]] release candidate 2 > > Alternative infix syntax is abandoned (it was never implemented) > > Accept $(sub sepxr) in macro-string and $[seq sepxr] > > Handle SIGIO Unix signals with asynchronous input channels > (experimental feature) > > Can be compiled by C++ (since GCC 4.7 often is) > > All the values are translated to melt_ptr_t variables, not void* > ones. > ############################################################### > > I believe it should work for a GCC 4.7 compiled in C++ mode. > Thanks to Alexnadre Lissy & Romain Geissler for their help. > > Please test and report bugs or build success or failure on > gcc-melt@googlegroups.com list. Sorry, I forgot the download information The release candidate 2 of MELT plugin 0.9.5 is still perhaps buggy but is available from http://gcc-melt.org/melt-0.9.5rc2-plugin-for-gcc-4.6-or-4.7.tar.gz as a gzipped tar archive of 4476348 bytes and md5sum 75e528535b05a03f452b55018b6b085b. You could try building it e.g. with make CC=gcc-4.7 CXX=g++-4.7 or perhaps with make MELTGCC=gcc-4.7 GCCMELT_CC=g++-4.7. Please report bugs on gcc-melt list. It is extracted from MELT branch svn revision 186078, april 2nd 2012. Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2012-04-02 10:35 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-03-29 20:02 pre-announce: MELT 0.9.5rc1 plugin for GCC 4.6 & 4.7 pre-release candidate 1 (and help needed on make issues) Basile Starynkevitch 2012-03-29 20:45 ` [GCC-MELT-386] " Romain Geissler 2012-03-29 21:03 ` [GCC-MELT-387] " Basile Starynkevitch 2012-03-29 21:29 ` Romain Geissler 2012-03-30 5:22 ` Basile Starynkevitch 2012-03-30 9:41 ` MELT 0.9.5rc1 etc Basile Starynkevitch 2012-03-31 0:23 ` [GCC-MELT-391] " Romain Geissler 2012-03-31 7:08 ` Basile Starynkevitch 2012-03-31 8:52 ` Romain Geissler 2012-03-31 10:28 ` Basile Starynkevitch 2012-03-31 11:55 ` Romain Geissler 2012-03-31 12:03 ` Romain Geissler 2012-03-31 12:39 ` [GCC-MELT-397] " Basile Starynkevitch 2012-03-31 13:07 ` Jonathan Wakely 2012-03-31 13:56 ` Romain Geissler 2012-03-31 14:30 ` Basile Starynkevitch 2012-04-02 10:31 ` Announce: MELT 0.9.5rc2 release candidate (for GCC 4.6 and 4.7) Basile Starynkevitch 2012-04-02 10:35 ` Basile Starynkevitch
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).