MELT tutorial on the wiki

MELT tutorial on the wiki

[Basile STARYNKEVITCH]

Hello All,

I added as a turorial on the wiki, a small MELT pass which warns against 
fprintf(stdout, ...) in the compiled code.

For GCC hackers, is the page
http://gcc.gnu.org/wiki/writing%20a%20pass%20in%20MELT
clear enough?

(of course, the pass implementation is imperfect, but I have hard time 
finding good *small* examples).

regards.
-- 
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 mines, sont seulement les miennes} ***

Re: MELT tutorial on the wiki

[Tom Tromey]

>>>>> "Basile" == Basile STARYNKEVITCH <basile@starynkevitch.net> writes:

Hi Basile.

Basile> I added as a turorial on the wiki, a small MELT pass which warns
Basile> against fprintf(stdout, ...) in the compiled code.

Basile> For GCC hackers, is the page
Basile> http://gcc.gnu.org/wiki/writing%20a%20pass%20in%20MELT
Basile> clear enough?

I've been looking for a very simple way to do some kinds of static
analysis on gdb, so today I tried building the MELT branch in hopes it
would serve this need.  Unfortunately, it didn't compile.

With C++ enabled, I got this failure:

/space/tromey/MELT/gcc/libstdc++-v3/include/precompiled/stdc++.h:98:18: fatal error: chrono: No such file or directory


With just C enabled, I got:

make[2]: *** No rule to make target `install-melt-headers', needed by `install'.  Stop.
make[2]: Leaving directory `/space/tromey/MELT/build/gcc'


In both cases I just configured with --disable-bootstrap --enable-melt,
plus the appropriate --enable-langauges option.  This is on x86 F11.

Basile> (of course, the pass implementation is imperfect, but I have hard time
Basile> finding good *small* examples).

My gdb examples involve finding broken code that can't be diagnosed by
the compiler.  Most of my examples are simple, but also actually useful.

For example, gdb has function that in the past could return null, but
which now cannot.  So, I'd like to find all places where the return
result is checked.

Or, gdb has a TRY_CATCH macro which expands to a couple of nested loops.
It is not ok to 'return' or 'goto' from inside the inner loop, as this
causes hard-to-find bugs.  So, it would be nice to find any place that
tries this.

Or, there is a data type in gdb that used to be freed using 'xfree', but
which now requires a special function to be called instead.  So, it
would be nice to find any place where xfree is passed an argument of
this type.

Etc.  For my purposes, any kind of simple analysis pass that is simple
to hack and doesn't require me to learn too much would be ideal.

Tom

Re: MELT tutorial on the wiki

[Basile STARYNKEVITCH]

Tom Tromey wrote:
>>>>>> "Basile" == Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
> 
> Hi Basile.
> 
> Basile> I added as a turorial on the wiki, a small MELT pass which warns
> Basile> against fprintf(stdout, ...) in the compiled code.
> 
> Basile> For GCC hackers, is the page
> Basile> http://gcc.gnu.org/wiki/writing%20a%20pass%20in%20MELT
> Basile> clear enough?
> 

A very big thanks to Tom for looking at the page & trying MELT. I would 
be very proud if Tom happens to use it.

> I've been looking for a very simple way to do some kinds of static
> analysis on gdb, so today I tried building the MELT branch in hopes it
> would serve this need.  Unfortunately, it didn't compile.
> 

My current belief is that MELT is easier built (and used) as a GCC-trunk 
(or future GCC-4.5) plugin melt.so. The advantage for you is also to be 
better fit to your GCC (provided it is similar enough to a recent trunk 
and have plugins enabled).
See the http://gcc.gnu.org/wiki/MELT%20tutorial

There are however a few caveats when building MELT as a plugin:

  a) The patch (submitted to the trunk on gcc-patches@) 
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00507.html which provides a 
gengtype usable for MELT as a plugin is required. I hope it will be 
reviewed & accepted for the trunk. The current gengtype (in recent 
trunk) is not good enough for complex plugins like MELT. Of course, you 
have the patched gengtype.c in the MELT branch.
Currently, this is the most annoying issue when building MELT as a plugin.

  b) some more headers are needed to MELT. the PLUGIN_HEADERS in 
gcc/Makefile.in is really incomplete. See footnote 9 of 
http://gcc.gnu.org/wiki/MELT%20tutorial

  c) you need to hack the MELT compile script (used to compile MELT 
generated C code into a shared library), that is, you should edit the 
file gcc/melt-cc-script.proto of MELT branch to suit your needs, and 
rename it appropriately.

  d) you need the PPL library (version 0.10.2 at least; the 0.10 is not 
enough). This is also needed when graphite is enabled.

> With C++ enabled, I got this failure:
> 
> /space/tromey/MELT/gcc/libstdc++-v3/include/precompiled/stdc++.h:98:18: fatal error: chrono: No such file or directory
> 
> 


My fault: I had a mysterious message from svnmerge a few days ago about 
this file. I just copied it manually (from trunk to MELT branch rev 
150308 which I just commited).

> With just C enabled, I got:
> 
> make[2]: *** No rule to make target `install-melt-headers', needed by `install'.  Stop.
> make[2]: Leaving directory `/space/tromey/MELT/build/gcc'
> 
> 
> In both cases I just configured with --disable-bootstrap --enable-melt,
> plus the appropriate --enable-langauges option.  This is on x86 F11.
> 

You probably missed some configure arguments. The MELT's 
gcc/configure.ac ends with
## Basile adds a notice if the MELT branch is configured without
## --enable-melt
if test "$enabled_melt" != "yes" ; then
    AC_MSG_NOTICE(
[GCC MELT branch is configured WITHOUT enabling melt.
  Are you sure to want that?])
fi


So if you got the GCC MELT branch is configured WITHOUT enabling melt 
message, your configure is wrong.


> Basile> (of course, the pass implementation is imperfect, but I have hard time
> Basile> finding good *small* examples).
> 
> My gdb examples involve finding broken code that can't be diagnosed by
> the compiler.  Most of my examples are simple, but also actually useful.
> 
> For example, gdb has function that in the past could return null, but
> which now cannot.  So, I'd like to find all places where the return
> result is checked.
> 
> Or, gdb has a TRY_CATCH macro which expands to a couple of nested loops.
> It is not ok to 'return' or 'goto' from inside the inner loop, as this
> causes hard-to-find bugs.  So, it would be nice to find any place that
> tries this.
> 
> Or, there is a data type in gdb that used to be freed using 'xfree', but
> which now requires a special function to be called instead.  So, it
> would be nice to find any place where xfree is passed an argument of
> this type.
> 
> Etc.  For my purposes, any kind of simple analysis pass that is simple
> to hack and doesn't require me to learn too much would be ideal.
> 
> Tom

So Tom, be kind enough to try MELT again (preferably in plugin mode). I 
am on holidays without email access from august 3rd to august 26th.


Tom, you are definitely the best MELT user I could have, since you know 
much better than I do the internals of GCC! I hope to be able to help you.

You could need to extend MELT (mostly file gcc/melt/ana-base.melt) to 
add all the hooks to GCC that you need and that are not there yet. Ask 
me for help please!

A very big thanks for your message & efforts.

Regards.

-- 
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 mines, sont seulement les miennes} ***

Re: MELT tutorial on the wiki

[Tom Tromey]

>>>>> "Basile" == Basile STARYNKEVITCH <basile@starynkevitch.net> writes:

Basile> My current belief is that MELT is easier built (and used) as a
Basile> GCC-trunk (or future GCC-4.5) plugin melt.so.

Yeah, I looked at this, but I really wanted something where I did not
have to do much work... no applying patches or hacking scripts.  I have
very little time for this side project, so most barriers look too big at
this point.

Tom> In both cases I just configured with --disable-bootstrap --enable-melt,
Tom> plus the appropriate --enable-langauges option.  This is on x86 F11.

Basile> You probably missed some configure arguments. The MELT's
Basile> gcc/configure.ac ends with
Basile> ## Basile adds a notice if the MELT branch is configured without
Basile> ## --enable-melt
Basile> if test "$enabled_melt" != "yes" ; then
Basile>    AC_MSG_NOTICE(
Basile> [GCC MELT branch is configured WITHOUT enabling melt.
Basile>  Are you sure to want that?])
Basile> fi

I looked into this a little.  It looks like the PPL checks don't work
properly in the case where PPL is a system library.  I guess I need
--with-ppl=/usr ... I will try that later.

BTW: IMO, on a branch like this, it would be friendlier for users to:

* Check in the correct version of configure
* Enable MELT by default, don't require an option
* Die in configure if a prerequisite is missing
* Have the PPL checks detect the situation where PPL is a system library

Otherwise whatever error messages there might be are just lost in the
noise.

Tom

Re: MELT tutorial on the wiki

[Tom Tromey]

Tom> I looked into this a little.  It looks like the PPL checks don't work
Tom> properly in the case where PPL is a system library.  I guess I need
Tom> --with-ppl=/usr ... I will try that later.

This worked but now I get an error because melt_generated_dir is not
defined in gcc/Makefile.  I don't know what value it ought to have.

/usr/bin/install: cannot create regular file `/warmelt-first-3.c': Permission denied


Tom

Re: MELT tutorial on the wiki

[Basile STARYNKEVITCH]

Tom Tromey wrote:
> Tom> I looked into this a little.  It looks like the PPL checks don't work
> Tom> properly in the case where PPL is a system library.  I guess I need
> Tom> --with-ppl=/usr ... I will try that later.

I don"t know really how to fix that quickly! I must confess that 
autoconf related files in GCC scares me a big lot. BTW, I really cannot 
imagine why GCC still required autoconf 2.59 specifically, and not 2.63. 
What is so specific about 2.59?

> 
> This worked but now I get an error because melt_generated_dir is not
> defined in gcc/Makefile.  I don't know what value it ought to have.

Thanks for the bug report. In fact, melt_generated_dir should be the 
same as melt_source_dir

I just committed rev 150330 of MELT branch to fix that. Tom, could you 
be patient & kind enough to try again! Many thanks!

> 
> /usr/bin/install: cannot create regular file `/warmelt-first-3.c': Permission denied
> 
> 
> Tom
My public apologies for the bug!

Regards.

-- 
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 mines, sont seulement les miennes} ***

Re: MELT tutorial on the wiki

[Dave Korn]

Tom Tromey wrote:

> I looked into this a little.  It looks like the PPL checks don't work
> properly in the case where PPL is a system library.  I guess I need
> --with-ppl=/usr ... I will try that later.

  Were you using a --prefix?  The PPL checks (by design I think) only look for
PPL in your prefix.

    cheers,
      DaveK

Re: MELT tutorial on the wiki

[Basile STARYNKEVITCH]

Dave Korn wrote:
> Tom Tromey wrote:
> 
>> I looked into this a little.  It looks like the PPL checks don't work
>> properly in the case where PPL is a system library.  I guess I need
>> --with-ppl=/usr ... I will try that later.
> 
>   Were you using a --prefix?  The PPL checks (by design I think) only look for
> PPL in your prefix.

Sorry DaveK, are you talking of only the MELT branch or of the current 
gcc trunk (future 4.5)? In the latter (trunk) case, what is the 
rationale for checking only in the prefix?

I have to clean up a bit my MELT's gcc/configure.ac, but I cannot 
understand why apparently the trunk's gcc/configure.ac does not set any 
HAVE_ppl flag.

Why is there no
if test "x${PPPLLIBS}" != "x" ; then
    AC_DEFINE(HAVE_ppl, 1, [Define if PPL is in use.])
fi
near line 4110 of the trunk's gcc/configure.ac ?

IMHO, such a test and such a generated #define makes a lot of sense (at 
least inside plugins).

Regards.


-- 
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 mines, sont seulement les miennes} ***

Re: MELT tutorial on the wiki

[Dave Korn]

Basile STARYNKEVITCH wrote:
> Dave Korn wrote:
>> Tom Tromey wrote:
>>
>>> I looked into this a little.  It looks like the PPL checks don't work
>>> properly in the case where PPL is a system library.  I guess I need
>>> --with-ppl=/usr ... I will try that later.
>>
>>   Were you using a --prefix?  The PPL checks (by design I think) only
>> look for PPL in your prefix.
> 
> Sorry DaveK, are you talking of only the MELT branch or of the current
> gcc trunk (future 4.5)? 

  Trunk.

> In the latter (trunk) case, what is the
> rationale for checking only in the prefix?

  I do not know it; I have merely observed the behaviour.  It may even not be by
design for all I know, though I suspect it makes sense - where else would you
look but in the prefix?  Prefixes exist to create separation between packages.

> I have to clean up a bit my MELT's gcc/configure.ac, but I cannot
> understand why apparently the trunk's gcc/configure.ac does not set any
> HAVE_ppl flag.
> 
> Why is there no
> if test "x${PPPLLIBS}" != "x" ; then
>    AC_DEFINE(HAVE_ppl, 1, [Define if PPL is in use.])
> fi
> near line 4110 of the trunk's gcc/configure.ac ?

  I imagine nobody has needed one yet.

> IMHO, such a test and such a generated #define makes a lot of sense (at
> least inside plugins).

  It certainly does.  I'm sure there's no reason not to add it.

    cheers,
      DaveK

Re: MELT tutorial on the wiki

[Ralf Wildenhues]

* Basile STARYNKEVITCH wrote on Sat, Aug 01, 2009 at 08:10:24AM CEST:
> I don"t know really how to fix that quickly! I must confess that
> autoconf related files in GCC scares me a big lot. BTW, I really
> cannot imagine why GCC still required autoconf 2.59 specifically,
> and not 2.63. What is so specific about 2.59?

I will post patches to move to 2.64 and Automake 1.11; they are ready
(I only need to finish writing the emails) but I'm off-list for the
next week starting now.  :-)

Cheers,
Ralf

Re: MELT tutorial on the wiki

[Paolo Bonzini]

> For example, gdb has function that in the past could return null, but
> which now cannot.  So, I'd like to find all places where the return
> result is checked.
>
> Or, gdb has a TRY_CATCH macro which expands to a couple of nested loops.
> It is not ok to 'return' or 'goto' from inside the inner loop, as this
> causes hard-to-find bugs.  So, it would be nice to find any place that
> tries this.
>
> Or, there is a data type in gdb that used to be freed using 'xfree', but
> which now requires a special function to be called instead.  So, it
> would be nice to find any place where xfree is passed an argument of
> this type.

MELT looks extremely cool!  You may want to use this too, however:

http://lwn.net/Articles/315686/

Paolo

Re: MELT tutorial on the wiki

[Basile STARYNKEVITCH]

Paolo Bonzini wrote:
>> For example, gdb has function that in the past could return null, but
>> which now cannot.  So, I'd like to find all places where the return
>> result is checked.
>>
>> Or, gdb has a TRY_CATCH macro which expands to a couple of nested loops.
>> It is not ok to 'return' or 'goto' from inside the inner loop, as this
>> causes hard-to-find bugs.  So, it would be nice to find any place that
>> tries this.
>>
>> Or, there is a data type in gdb that used to be freed using 'xfree', but
>> which now requires a special function to be called instead.  So, it
>> would be nice to find any place where xfree is passed an argument of
>> this type.
> 
> MELT looks extremely cool!  You may want to use this too, however:
> 
> http://lwn.net/Articles/315686/

This is about Coccinelle so http://coccinelle.lip6.fr/ is a better link.

Indeed, Tom Tromey might also try Coccinelle. However, MELT is a 
different beast: above all, it is tightly integrated inside GCC, and is 
designed & useful to write (or at least prototype) GCC passes (mostly in 
the middle end); while Coccinnelle is a tool unrelated to GCC (except 
for the input language, i.e. C).

Since MELT works on GCC internal representations, it should be able to 
deal with all the source languages GCC is able to compile.

So I would say that MELT is complementary to Coccinelle.

BTW, people interested in static analysis for C (not C++ or Ada) might 
look at FramaC http://frama-c.cea.fr/ which is unrelated to GCC (except 
for its use of the preprocessor).


I believe MELT could be best viewed as a tool for GCC plugins, either 
"analysis" plugins -which don't change the code and don't influence the 
GCC generated object code, or "transformation" or "optimisation" 
plugins, which do change the GCC code generation.

For people able to review patches, my most desirable patch is
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00507.html (a patch for 
gengtype). Currently, MELT can be compiled as a plugin to an unmodified 
GCC-trunk (ie 4.5) binary, but to compile MELT you need this patch 
(which improves the C code generated by gengtype in plugin mode).

Regards.


PS. In a few days, I'm leaving on vacation for almost 3 weeks without 
email access.

-- 
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 mines, sont seulement les miennes} ***

Re: MELT tutorial on the wiki

[Paolo Bonzini]

>> Tom> I looked into this a little. It looks like the PPL checks don't work
>> Tom> properly in the case where PPL is a system library. I guess I need
>> Tom> --with-ppl=/usr ... I will try that later.
>
> I don"t know really how to fix that quickly! I must confess that
> autoconf related files in GCC scares me a big lot.

Yes they are complicated but (unlike some other projects) people have a 
handle on them...

> BTW, I really cannot
> imagine why GCC still required autoconf 2.59 specifically, and not 2.63.
> What is so specific about 2.59?

Nothing, but just like Autoconf 2.50 should have been 3.0, similarly 
2.60 should have been a major version number as it changed datadir from 
/usr/share to /usr/share/package, among other things.

In fact, GCC moved smoothly from to first 2.5x it used to 2.59, but 
stopped there.

I shouldn't say so because I was one of the main contributors (with Ralf 
and with Eric Blake), but I'm sure that people on the list will 
appreciate Autoconf 2.64.  Which should have been another 3.0, even 
though the user-visible changes are not too many.

Paolo

Re: MELT tutorial on the wiki

[Tom Tromey]

>>>>> "Dave" == Dave Korn <dave.korn.cygwin@googlemail.com> writes:

Dave> Were you using a --prefix?  The PPL checks (by design I think) only
Dave> look for PPL in your prefix.

Dave>   I do not know it; I have merely observed the behaviour.  It may
Dave> even not be by design for all I know, though I suspect it makes
Dave> sense - where else would you look but in the prefix?  Prefixes
Dave> exist to create separation between packages.

That didn't seem to be what the code on Basile's branch does.

But, if this is what the PPL checks do actually do somewhere, then they
are broken.  Prefix is for specifying the install tree -- specifying how
the build is done is handled by other options.

Tom

Re: MELT tutorial on the wiki

[Tom Tromey]

>>>>> "Paolo" == Paolo Bonzini <bonzini@gnu.org> writes:

Paolo> MELT looks extremely cool!  You may want to use this too, however:
Paolo> http://lwn.net/Articles/315686/

Yes, I'm also looking at Coccinelle and TreeHydra.

As this is strictly a spare-time project, I am trying to find the
approach that requires the least effort on my part.

Coccinelle has the advantage that it is already packaged on Fedora.
However, the documentation is not excellent (AFAICT there is a grammar
and a bunch of examples, but nothing else) and that makes it difficult
to use.  Also it does not seem to handle GDB's heavily macroized code
very well (maybe there's a way ... but again, the docs).

TreeHydra looks very promising but it seems complicated to build.  It
wasn't clear which patches ought to be applied.  I'm going to get it
built one of these weeks...

I was hoping that because all the code was on a branch, MELT would be
the simplest to get working.  Now I've spent more time on it than on the
other two combined ;)

Tom

Re: MELT tutorial on the wiki

[Tom Tromey]

Basile> Thanks for the bug report. In fact, melt_generated_dir should be the
Basile> same as melt_source_dir

Basile> I just committed rev 150330 of MELT branch to fix that. Tom, could you
Basile> be patient & kind enough to try again! Many thanks!

Thanks, that worked.
Now to actually try MELT... exciting.

Tom

Re: MELT tutorial on the wiki

[Basile STARYNKEVITCH]

Tom Tromey wrote:
> Basile> Thanks for the bug report. In fact, melt_generated_dir should be the
> Basile> same as melt_source_dir
> 
> Basile> I just committed rev 150330 of MELT branch to fix that. Tom, could you
> Basile> be patient & kind enough to try again! Many thanks!
> 
> Thanks, that worked.
> Now to actually try MELT... exciting.
> 


There are still missing stuff in MELT. In particular, not every GIMPLE 
feature is currently interfaced, because my way of coding is to 
progressively add stuff inside MELT to deal with a particular question 
(or even a test case).


Tom, and anyone other brave & kind enough to try MELT, knowing well GCC 
internals, feel free to add more code inside MELT. Anyone with write 
access to GCC subversion, good knowledge & good will can add more code 
inside MELT (I explicitly invite brave people to enhance MELT).
This means essentially copy-pasting code (notably inside file 
gcc/melt/ana-base.melt). But please add a few comments in the code (if 
you patch it) and also in Changelog.MELT.

I'm leaving on holidays within two days.

Regards.

-- 
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 mines, sont seulement les miennes} ***

Re: MELT tutorial on the wiki

[Dave Korn]

Tom Tromey wrote:
>>>>>> "Dave" == Dave Korn <dave.korn.cygwin@googlemail.com> writes:
> 
> Dave> Were you using a --prefix?  The PPL checks (by design I think) only
> Dave> look for PPL in your prefix.
> 
> Dave>   I do not know it; I have merely observed the behaviour.  It may
> Dave> even not be by design for all I know, though I suspect it makes
> Dave> sense - where else would you look but in the prefix?  Prefixes
> Dave> exist to create separation between packages.
> 
> That didn't seem to be what the code on Basile's branch does.
> 
> But, if this is what the PPL checks do actually do somewhere, then they
> are broken.  Prefix is for specifying the install tree -- specifying how
> the build is done is handled by other options.

  Ah, I think I misunderstood what's going on.  If you specify --with-ppl, what
happens:

> AC_ARG_WITH(ppl, [  --with-ppl=PATH         Specify prefix directory for the installed PPL package
>                           Equivalent to --with-ppl-include=PATH/include
>                           plus --with-ppl-lib=PATH/lib],, with_ppl=no)
> AC_ARG_WITH(ppl_include, [  --with-ppl-include=PATH Specify directory for installed PPL include files])
> AC_ARG_WITH(ppl_lib, [  --with-ppl-lib=PATH     Specify the directory for the installed PPL library])
> 
> case $with_ppl in 
>   no)
>     ppllibs=
>     ;;
>   *)
>     ppllibs="-L$with_ppl/lib -lppl_c -lppl -lgmpxx"
>     pplinc="-I$with_ppl/include $pplinc"
>     LIBS="$ppllibs $LIBS"
>     ;;
> esac

... is that it looks in /lib and /include, which is fairly likely to succeed -
but only because you'll also have $prefix/lib and $prefix/include in the -L and
-I settings anyway (when compiling stages 2/3 and target libs).  Change your
--prefix setting to some other tree where you don't have a PPL installation and
all of a sudden using plain "--with-ppl" will fail, and you may think it's
because it is looking for ppl in $prefix, when in fact the answer is that it
should complain about an empty --with-ppl with no argument.

    cheers,
      DaveK

Re: MELT tutorial on the wiki

[Ralf Wildenhues]

Hello,

* Dave Korn wrote on Sat, Aug 01, 2009 at 08:41:10AM CEST:
> Tom Tromey wrote:
> 
> > I looked into this a little.  It looks like the PPL checks don't work
> > properly in the case where PPL is a system library.  I guess I need
> > --with-ppl=/usr ... I will try that later.
> 
>   Were you using a --prefix?  The PPL checks (by design I think) only look for
> PPL in your prefix.

Just by the way, while it superficially sounds intuitive, I find this a
slightly problematic "feature".  For example when you're cross-compiling,
intending to do a DESTDIR install, and what you pass as --prefix is
inhabited by $build system files and libraries and so on.

My two cents.

Cheers,
Ralf

MELT tutorial on the wiki

[Basile STARYNKEVITCH]

Hello All

I added a (still incomplete) MELT tutorial on the wiki:
http://gcc.gnu.org/wiki/MELT%20tutorial

It tells you how to do a hello world in MELT.

Regards.

-- 
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 mines, sont seulement les miennes} ***