From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5865 invoked by alias); 31 Mar 2012 11:55:51 -0000 Received: (qmail 5856 invoked by uid 22791); 31 Mar 2012 11:55:50 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_SV X-Spam-Check-By: sourceware.org Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 31 Mar 2012 11:55:36 +0000 Received: by wibhn6 with SMTP id hn6so1143365wib.8 for ; Sat, 31 Mar 2012 04:55:34 -0700 (PDT) Received: by 10.180.78.40 with SMTP id y8mr815493wiw.15.1333194934689; Sat, 31 Mar 2012 04:55:34 -0700 (PDT) Received: from [192.168.0.1] (che78-2-82-227-240-214.fbx.proxad.net. [82.227.240.214]) by mx.google.com with ESMTPS id ex2sm24716509wib.8.2012.03.31.04.55.31 (version=SSLv3 cipher=OTHER); Sat, 31 Mar 2012 04:55:34 -0700 (PDT) Subject: Re: [GCC-MELT-391] MELT 0.9.5rc1 etc... Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Romain Geissler In-Reply-To: <20120331122743.041226112d48f7053fd881f0@starynkevitch.net> Date: Sat, 31 Mar 2012 11:55:00 -0000 Cc: gcc-melt@googlegroups.com, gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <349BFE85-C8C7-4127-9FD8-1113A64C15A0@gmail.com> References: <20120329220207.bae3ea9d282f9f857b810a4a@starynkevitch.net> <128B3796-F687-4007-AD2D-AE235B916D88@gmail.com> <20120329230309.205f604fd0c1abfc19f2ea58@starynkevitch.net> <20120330094041.GA1260@ours.starynkevitch.net> <20120331090754.ad4e9bc3602eee0470b9cb47@starynkevitch.net> <18D969F4-9873-433F-BF79-EC9208BDAD2A@gmail.com> <20120331122743.041226112d48f7053fd881f0@starynkevitch.net> To: Basile Starynkevitch X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-03/txt/msg00570.txt.bz2 Le 31 mars 2012 =E0 12:27, Basile Starynkevitch a =E9crit : > I am surprised of your patch which indeed contains gcc/melt-build.tpl: >=20 > -## GAWK is needed, the GNU awk [+ (. (tpl-file-line))+] > -GAWK ?=3D gawk > +## AWK is needed [+ (. (tpl-file-line))+] > +AWK ?=3D awk >=20 >=20 > I really need GNU awk (and I may depend upon GNU extensions of awk). AFAI= K, GCC also > requires *GNU* awk specifically (and not some other awk). Why the above p= atch? 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 convent= ion, 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 re= placed 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/bu= ild-melt-plugin.sh but those are only for packagers, not for melt users). The gawk usage i rep= laced 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 chec= k performed to know if it is GNU awk or not, as all uses are conforming to the common awk speci= fications. 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 o= ne 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, no= t GNU awk. > A more general question is the status of plugins on MacOSX. I thought tha= t GCC plugins in > general only work for ELF shared object systems with dlopen. It seems tha= t gcc/plugin.c > is hardwiring the ".so" suffix in function add_new_plugin. Can an unpatch= ed 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 nee= d 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/functi= ons/dlopen.html > etc work on MacOSX (in particular when file is NULL and mode contains RTL= D_GLOBAL)? =46rom the man page shipped by Apple, i see : If a null pointer is passed in path, dlopen() returns a handle equivalent t= o 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 pa= tch plugin.c > first if needed (and propose that to the trunk), by taking care of at lea= st naming the > suffix needed for them (in a publicly available header exported to plugin= s), 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 ins= tead of *.so. We'll see if it's accepted. > This .so suffix is hardwired in melt-runtime.c; I am adding MELT_DYNLOADE= D_SUFFIX > constant to help going to systems with other dlopen-ed dynamic libraries = suffixes. >=20 > I added your SHARED_LIBRARY_FLAGS patch into melt-module.mk >=20 > 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 effic= ient 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 OS= X, 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. >=20 > I still need to replace the occurrences of .so in the MELT code itself. >=20 > Thanks. > --=20 > Basile STARYNKEVITCH http://starynkevitch.net/Basile/ > email: basilestarynkevitchnet mobile: +33 6 8501 2359 > 8, rue de la Faiencerie, 92340 Bourg La Reine, France > *** opinions {are only mine, sont seulement les miennes} ***