On Sat, 31 Mar 2012 10:52:09 +0200
Romain Geissler <romain.geiss...@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.geiss...@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} ***
