This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]