making cygwin nightly builds available?

Hi,

I'm looking into LLVM, and I must say it looks supremely cool. However,
I'm having a hard time getting anywhere with it, since I don't have a linux
machine here, and cygwin seems like a bit of a second-class citizen.

The instructions to build the cygwin binaries are outdated, so I have
to just make some guesses as to what the right thing to do is, and
I'm apparently not guessing right. (For example, extensive mention is
made of a directory "cfrontend/src" which doesn't seem to exist. Perhaps
it's what's now called llvm-gcc?)

Forgive me for saying so, but I don't really want to spend any time
*building* llvm; I want to *use* it. I've spent four days trying
to get a usable set of executables, and no luck so far. Yes, I pulled
everything from CVS; yes, I built my own binutils. I'm still trying, but
four days is a long time for no success.

Anyway, I notice that last night's cygwin nightly build suceeded;
could I just pretty please have those binaries? Some projects
I've seen have a "download nightly build" section for the
adventurous; mightn't you do the same? This would be hugely
useful until there's a forehead-build (or better yet, forehead-install)
for llvm on cygwin.

Marshall Spight

Hi Marshall,

LLVM *is* cool .. just not on cygwin! :slight_smile:

Sorry for the sad state of the cygwin build. I had hoped to have it
cleaned up by now but many other things have been taking my time.
Although the build has been succeeding in recent days, I'm not sure it
will buy you anything. NONE of the nightly tests pass on cygwin. Until I
can get some time to figure out why that is happening, I doubt the
binaries will be of any help to you.

I'll be looking at this in the coming weeks. Cygwin build support is
scheduled for LLVM 1.5 (March). When I get binaries that pass the
nightly test, I'll make them available on my download page. You can
reach that at http://illuvium.net/

FYI, work progresses on the Win32 native port which you might also find
interesting. It might even get done before the cygwin stuff. Jeff Cohen
is working on that. Perhaps he can indicate the status of that effort.

Reid.

Sorry for the sad state of the cygwin build. I had hoped to have it
cleaned up by now but many other things have been taking my time.
Although the build has been succeeding in recent days, I'm not sure it
will buy you anything. NONE of the nightly tests pass on cygwin.

<ulp!>

Until I
can get some time to figure out why that is happening, I doubt the
binaries will be of any help to you.

Ah, well. I think the right thing for me to do for the time being may
be to work on my interpreter, and come back later to the task
of targetting llvm.

I'll be looking at this in the coming weeks. Cygwin build support is
scheduled for LLVM 1.5 (March). When I get binaries that pass the
nightly test, I'll make them available on my download page. You can
reach that at http://illuvium.net/

Thanks. That would be cool.

FYI, work progresses on the Win32 native port which you might also find
interesting. It might even get done before the cygwin stuff. Jeff Cohen
is working on that. Perhaps he can indicate the status of that effort.

I recall reading on the llvm archives somewhere that there are significant
performance issues with the cygwin platform. True? If so, the Win32 native
version would probably be preferable. Actually, if it packages and deploys
better, (as in, no requirement to install anything cygwin,) which I
suspect it will,
that alone would be reason to prefer the native version.

Meanwhile I may just go get me a redhat machine.

Are the linux binaries only for the llvm-gcc part, or can you also get binaries
for the vanilla llvm part? It's hard to tell from the download page.

If I may offer a humble suggestion from a prospective "customer", may
I suggest that you *remove* options from the various build and download
instructions? The best build-from-source instructions are something like
"./configure; make all; make install"-- each instruction of the form
"either do this or else do this"; "either put these here or put them here"
reduces the chance of a successful build for the newcomer.

Anyway, congratulations on your success so far and I hope you continue
to rock.

Marshall Spight

I recall reading on the llvm archives somewhere that there are
significant performance issues with the cygwin platform. True?

True.

Are the linux binaries only for the llvm-gcc part, or can you also get
binaries for the vanilla llvm part? It's hard to tell from the
download page.

The binaries are only for llvm-gcc.

If I may offer a humble suggestion from a prospective "customer", may
I suggest that you *remove* options from the various build and download
instructions? The best build-from-source instructions are something like
"./configure; make all; make install"-- each instruction of the form
"either do this or else do this"; "either put these here or put them here"
reduces the chance of a successful build for the newcomer.

Thanks for the input, we'll do our best to simplify/clarify those
instructions.

Anyway, congratulations on your success so far and I hope you continue
to rock.

On behalf of everyone, if I may, thanks! :slight_smile:

Hello, Reid.

You wrote Friday, January 21, 2005, 11:14:41 PM:

FYI, work progresses on the Win32 native port which you might also find
interesting. It might even get done before the cygwin stuff. Jeff Cohen
is working on that. Perhaps he can indicate the status of that effort.

There is too much work to do native Win32 builds.
I've tried to get llvm compiled on mingw32 using the latest snapshot
of gcc from cvs + some mingw specific patches.
A (very brief) list of suggested patches:

1. Fix file open mode everywhere! Some llvm tools open files for binary
output as text files(!). This leads to corrupted files almost everywhere.
(BytecodeWriter, Archive, Linker, ...)
2. Fix CRLF issues, where possible (Archive, etc)
3. Need complete Win32/Path.cpp rewrote to handle all types of paths
:frowning:
4. Change __MINGW define to __MINGW32__, which is official now
5. Cfrontend build is little bit tricky, but I have it compiled. The
main problems are due to several bugs in mingw's sh.exe
implementation, which stops building libstdc++ and many others.
Solution: add correct include path to configure script, fix makefile
(gcc throws error, if get -I without any path), fix several config
bugs (rand48, some in libstdc++).
6. Add stubs for functions in the debugger support library (fork,
waitpid, etc.). I have implementation for some of that functions, but
not for all.
7. Add -lpsapi -limagehlp to ExtraLibs to all tools' makefiles.
....
\infty [Some dummy things, I've forgotten]

As result: mingw port seems don't work now, but can in the nearest
future.

I have patches for some problems I've listed, but I need to sync them
with the latest cvs snapshot. I'll send them, when I will be less
busy.

PS: I've successfully build llvm on cygwin with gcc-3.4.4 without any big problems,
maybe only just dummy fixes.

Marshall Spight wrote:

FYI, work progresses on the Win32 native port which you might also find
interesting. It might even get done before the cygwin stuff. Jeff Cohen
is working on that. Perhaps he can indicate the status of that effort.
   
I recall reading on the llvm archives somewhere that there are significant
performance issues with the cygwin platform. True? If so, the Win32 native
version would probably be preferable. Actually, if it packages and deploys
better, (as in, no requirement to install anything cygwin,) which I
suspect it will,
that alone would be reason to prefer the native version.

It's true. The native win32 version does not use cygwin in the slightest. It's built with Microsoft Visual Studio. If you have that, it's trivial to build (double click the solution then run "build solution"), but it does require that you have bison, sed, and flex on your machine. Prebuilt binaries are available on illuvium.net.

It's usable so long as you are writing your own front end. There are serious technical issues standing in the way of getting llvm-gcc built natively on Windows. Also, only the JIT or interpreter is usable at this time. I haven't gotten around to getting assembler output yet that can be built with NASMW.

I am doing the port using Microsoft's Visual Studio, not mingw. I cannot address mingw-specific problems, but someone here (Henrik) has successfully built with mingw.

Reid, the binary/text mode is a valid issue. I have successfully used a bytecode file on Windows that was created on Unix, but I must have been lucky.

I don't understand why Win32/Path.cpp needs a complete rewrite to handle all types of paths. What types of paths are not being handled?

Trying to get the debugger support library to compile is a waste of time. There is no way it will work on Windows because it actually *uses* fork(). Stubbing it out so it compiles or links will not accomplish anything. A new implementation using the Win32 debugging API is required for it to work. You're welcome to write one :slight_smile:

Anton Korobeynikov wrote:

Strike that... the prebuilt binaries are not likely to be of any use to you. You'll need Visual Studio .NET 2003 to build it yourself.

Jeff Cohen wrote:

Hi Anton,

I'm the one who tries to build the mingw version of the llvm stuff in cooperation with the other llvm people.

If you would be so kind to ship your list for building the llvm-gcc part we would appriciate it. Or, even better: join the llvm development team.

Henrik.

----Original Message Follows----

Hello, Reid.

You wrote Friday, January 21, 2005, 11:14:41 PM:

FYI, work progresses on the Win32 native port which you might also find
interesting. It might even get done before the cygwin stuff. Jeff Cohen
is working on that. Perhaps he can indicate the status of that effort.

There is too much work to do native Win32 builds.
I've tried to get llvm compiled on mingw32 using the latest snapshot
of gcc from cvs + some mingw specific patches.
A (very brief) list of suggested patches:

1. Fix file open mode everywhere! Some llvm tools open files for binary
output as text files(!). This leads to corrupted files almost everywhere.
(BytecodeWriter, Archive, Linker, ...)
2. Fix CRLF issues, where possible (Archive, etc)
3. Need complete Win32/Path.cpp rewrote to handle all types of paths
:frowning:
4. Change __MINGW define to __MINGW32__, which is official now
5. Cfrontend build is little bit tricky, but I have it compiled. The
main problems are due to several bugs in mingw's sh.exe
implementation, which stops building libstdc++ and many others.
Solution: add correct include path to configure script, fix makefile
(gcc throws error, if get -I without any path), fix several config
bugs (rand48, some in libstdc++).
6. Add stubs for functions in the debugger support library (fork,
waitpid, etc.). I have implementation for some of that functions, but
not for all.
7. Add -lpsapi -limagehlp to ExtraLibs to all tools' makefiles.
....
\infty [Some dummy things, I've forgotten]

As result: mingw port seems don't work now, but can in the nearest
future.

I have patches for some problems I've listed, but I need to sync them
with the latest cvs snapshot. I'll send them, when I will be less
busy.

PS: I've successfully build llvm on cygwin with gcc-3.4.4 without any big problems,
maybe only just dummy fixes.

Hello, Jeff.

You wrote Saturday, January 22, 2005, 3:57:28 AM:

Reid, the binary/text mode is a valid issue.

This set of flags worked for me:
std::ios_base::out | std::ios_base::trunc | std::ios_base::binary
Yes, there are open issues with std::ios_base::binary, but llvm are
not affected with them now.

I have successfully used a bytecode file on Windows that was created
on Unix, but I must have been lucky.

Yes, it is so, but if you try to write any file on Windows, or, even
more, just try to read library file, you'll get an invalid result.
(Library file will fail, because its header is defined as
"<arch>\n",...).

I am going to use ios_base::binary as a short term workaround.

Anton Korobeynikov wrote: