public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Romain Geissler <romain.geissler@gmail.com>
To: Basile Starynkevitch <basile@starynkevitch.net>
Cc: gcc-melt@googlegroups.com, gcc@gcc.gnu.org
Subject: Re: [GCC-MELT-391] MELT 0.9.5rc1 etc...
Date: Sat, 31 Mar 2012 11:55:00 -0000	[thread overview]
Message-ID: <349BFE85-C8C7-4127-9FD8-1113A64C15A0@gmail.com> (raw)
In-Reply-To: <20120331122743.041226112d48f7053fd881f0@starynkevitch.net>


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

  reply	other threads:[~2012-03-31 11:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=349BFE85-C8C7-4127-9FD8-1113A64C15A0@gmail.com \
    --to=romain.geissler@gmail.com \
    --cc=basile@starynkevitch.net \
    --cc=gcc-melt@googlegroups.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).