Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...

[Basile Starynkevitch <basile at starynkevitch dot net>]

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} ***