> >
> > I've put the pre-release tar balls here:
> > http://llvm.org/prereleases/1.7/
> >
>
> The build failed on i686-pc-linux-gnu.
[snip error message]
Ialready figured it out. I ran the build in the source dir.
Please note that you are not providing us enough information. To report
an error of the form "the build is broken", please specify:
* Your platform (in this case, what Linux distro/version/etc.)
* Your version of g++
* Your version of autoconf/automake/binutils/et al.
* How did you run "configure"
* How did you run "make"
Perhaps your flex is generating invalid C++ code (for the compiler you
are using)? Your post didn't mention whether that code was valid, nor
did it include a snippet of the code in question. For example,
bison-1.875 had problems in the past: http://llvm.org/bugs/show_bug.cgi?id=302
The build succeeded this morning (true, it ran from CVS, but you can
also find the day when the tree was tagged and see the build log from
then as well): http://llvm.org/testresults/X86/
Also, the nightly tester runs with srcdir == objdir.
Im using debian testing and gcc4.1 prerelease 20060414. the llvm tool
only build is ok. cfrontend build dies with an ICE when building the
runtime. I will take a look at it again tomorrow.
This came up when trying to compile the Python bindings
against llvm 1.7. File include/llvm/Transforms/Scalar.h
declares llvm::createPREPass(), which does not seem to
be implemented anywhere. Should I report this in llvmbugs?
The boost Python are not (yet) part of LLVM so I suppose it would make most sense to try to makes fixes/changes so they would work for 1.7 and then try to get them into LLVM CVS. It would be good in such a case to ask the author of the bindings again if he would allow this, because basicaly I think he has to agree to the LLVM lincense.
This came up when trying to compile the Python bindings
against llvm 1.7. File include/llvm/Transforms/Scalar.h
declares llvm::createPREPass(), which does not seem to
be implemented anywhere. Should I report this in llvmbugs?
Just to clarify myself: this is an issue with the LLVM sources,
not with the Python bindings.
The boost Python are not (yet) part of LLVM so I suppose it would make most sense to try to makes fixes/changes so they would work for 1.7 and then try to get them into LLVM CVS.
I tried compiling the bindings, and it seems that it
would not be too much work to compile them for 1.7.
I'm not familiar enough with LLVM to assess how complete
the bindings are.
Boost.Python does not handle void* directly, so any methods with
void* arguments or return values need a little bit of extra
attention. Otherwise I don't foresee any great difficulties.
It would be good in such a case to ask the author of the bindings again if he would allow this, because basicaly I think he has to agree to the LLVM lincense.
I don't think this will be a problem, since README.txt
already mentions the LLVM license...
In my opinion, the most sensible thing to do with the bindings
right now would be to put them up on a CVS server somewhere.
Is there a chance of getting them at uiuc as a separate tree?
Another alternative would be to use SourceForge or something
similar.
If our group decides to go with LLVM, then I'd be happy to work on
the bindings, but that choice is not entirely up to me.
Hi,
here's a brief update of the status of the python bindings. Recently
I've updated them with the API changes in LLVM 1.6 and split the
submodules (VMCore, ExecutionEngine, etc.) into separate builds,
making the dynamic libraries smaller.
I agree that the bindings should be in a CVS somewhere, and last year
there was some discussion of putting them in the llvm tree. The
python bindings are otherwise ready for the "projects" folder, and I
decided to change the license and assign copyright to UIUC for this to
happen, but there are persistent (linkage related?) crashes I haven't
had the time to solve so far. Also, I have quite little time for
this, so things have not exactly been flying forward
So, here attached is the latest package I sent to Eric last month.
Thank you for this mail. Personally I think the fact that is not stable yet is even more reason to put it in to CVS somewhere.
The file that you attached here and that you have send me is the one I forwarded to Pertti. My vote would be to not put it
into the LLVM cvs actually but in a seperate repository so it would be easier to assign commit-rights to developers.
But maybe the commit-rights could be set even to this specific llvm subproject on a per user basis, so you, Pertti and I could
commit to the bindings only, which would maybe be even better.
