LLVM MinGW binaries on Vista issue

I'm attempting to use the above as described here

http://stackoverflow.com/questions/1816469/llvm-mingw-installation-on-vista

...and getting the following error when attempting "llvm-gcc -o hello.exe hello.c"

llvm-gcc: CreateProcess: No such file or directory

I've heard it may be due to the way GCC is passing args to CreateProcess as in this thread

http://readlist.com/lists/lists.sourceforge.net/mingw-users/1/7113.html
http://readlist.com/lists/lists.sourceforge.net/mingw-users/1/7180.html

Is this the cause or is there something else I need to due with the LLVM binaries?

Jon

I'm attempting to use the above as described here

http://stackoverflow.com/questions/1816469/llvm-mingw-installation-on-vista

...and getting the following error when attempting "llvm-gcc -o hello.exe hello.c"

llvm-gcc: CreateProcess: No such file or directory

I've heard it may be due to the way GCC is passing args to CreateProcess as in this thread

http://readlist.com/lists/lists.sourceforge.net/mingw-users/1/7113.html
http://readlist.com/lists/lists.sourceforge.net/mingw-users/1/7180.html

Is this the cause or is there something else I need to due with the LLVM binaries?

Is there a more appropriate forum for getting this type of question answered?

Jon

Hello

Is this the cause or is there something else I need to due with the LLVM binaries?

Yes, this might be a possible issue. I'm not sure whether apple's gcc
4.2 (which llvm-gcc 4.2 is based originally on) has that vista
workaround patches.

Unfortunately, I don't have vista box around to check / debug this issue.

> Is this the cause or is there something else I need to due with the LLVM binaries?

Yes, this might be a possible issue. I'm not sure whether apple's gcc
4.2 (which llvm-gcc 4.2 is based originally on) has that vista
workaround patches.

Unfortunately, I don't have vista box around to check / debug this issue.

What's the next step given that, as much as I'd like to, I can't send you a vista box?

I'm feeling the patch-the-sources-and-try-compiling-it-yourself answer (which I had hoped to avoid) coming on :wink:

Any way to get this added to the 2.7 mingw binary release TODO list for proper confirmation/fixing by the LLVM experts?

Thanks, Jon

What's the next step given that, as much as I'd like to, I can't send you a vista box?

If you're feeling particularly adventurous, this might be interesting

http://technet.microsoft.com/en-us/evalcenter/cc442495.aspx

Jon

I'm attempting to use the above as described here

http://stackoverflow.com/questions/1816469/llvm-mingw-installation-on-vista

...and getting the following error when attempting "llvm-gcc -o hello.exe hello.c"

llvm-gcc: CreateProcess: No such file or directory

I also get the same issue when trying to run the LLVM MinGW binaries on an XP box, which indicates I'm doing something fundamentally wrong as binaries have been offered all the way back to LLVM 1.8.

Is anyone successfully running the 2.6 binaries as-is on any windows box?

Is the expectation that the install dance for windows should be similar to installing the binaries from http://mingw.org/ or http://www.tdragon.net/recentgcc/

If someone is successfully running these binaries, I'd appreciate a link or quick summary, and I'll volunteer to submit a doco patch for the Getting Started Guide for this issue.

Jon

Hello

Is anyone successfully running the 2.6 binaries as-is on any windows box?

Yes. They are running successfully since LLVM 1.8 as-is. The usual test
for mingw binaries includes e.g. Qt compilation via llvm-gcc.

> Is anyone successfully running the 2.6 binaries as-is on any windows box?
Yes. They are running successfully since LLVM 1.8 as-is. The usual test
for mingw binaries includes e.g. Qt compilation via llvm-gcc.

Anton,

First, thank you for taking the time to reply.

Looking at the type of issues discussed on this list, this thread cleary doesn't belong here. It is little more than noise. That said, it's not clear where it should be worked. Quite frankly, this should already be documented in the Getting Started doc. Either I missed it or it's not there.

Since the mingw binaries are compiling Qt on windows, then my issue should likely be one of:

* incorrect PATH setup...currently using "c:\llvm;c:\llvm-gcc\bin;C:\Windows\system32;c:\Windows;c:\Windows\System32\Wbem"
* incorrect dir structure...currently using "c:\llvm" and "c:\llvm-gcc" as peers...no spaces in dirs...should they be nested?
* missing dependency...e.g. is MSys with a correct /etc/fstab required?

Would you reply with the configuration (llvm* dir layout, PATH, OS flavor, required dependencies) for the test system successfully using the binaries to build Qt?

Assuming the info fixes things on my system, what doc should I mod (FAQ, Getting Started, ??) in order to make this more clear? I'm assume submitting a standard diff is preferred.

Thank you,
Jon

Hello, Jon

The main idea of llvm-gcc is to be a drop-in replacement of gcc. So,
if you know how to install & run gcc on your system, you should be
able to do the same with llvm-gcc (thus no "Getting Started" entry).
Basically the only "packaging differences" wrt normal gcc is that
we're shipping w32api & mingw-runtime packages with llvm-gcc. Surely,
you still need binutils installed (to get linker + assembler).

* incorrect PATH setup...currently using "c:\llvm;c:\llvm-gcc\bin;C:\Windows\system32;c:\Windows;c:\Windows\System32\Wbem"

Looks ok. However, llvm itself is not required.

* incorrect dir structure...currently using "c:\llvm" and "c:\llvm-gcc" as peers...no spaces in dirs...should they be nested?

No. LLVM itself is not required at all, however, no

* missing dependency...e.g. is MSys with a correct /etc/fstab required?

No, msys is not required (like for normal gcc)

Would you reply with the configuration (llvm* dir layout, PATH, OS flavor, required dependencies) for the test system successfully using the binaries to build Qt?

1. Just ordinary Windows XP SP2 box. No additional stuff installed
2. mingw gcc is installed in the c:\mingw, binutils is unpacked into
the same dir, thus c:\mingw\bin is added to PATH
3. LLVM sources are located in the c:\llvm\src, build directory is
c:\llvm\build, nothing added to PATH
4. llvm-gcc lives in c:\llvm-gcc\bin, nothing added to PATH

If you have problems with invocation of gcc / llvm-gcc it's usually
helps to add -v flag to cmdline to see, what it tries to executed.

Hope this helps.

The main idea of llvm-gcc is to be a drop-in replacement of gcc. So,
if you know how to install & run gcc on your system, you should be
able to do the same with llvm-gcc (thus no "Getting Started" entry).
Basically the only "packaging differences" wrt normal gcc is that
we're shipping w32api & mingw-runtime packages with llvm-gcc. Surely,
you still need binutils installed (to get linker + assembler).

Ahh. After extracting "binutils-2.20-1-mingw32-bin.tar.gz" into the llvm-gcc dir, I'm up and running.

What threw me was the projects inclusion of 2 of the 3 other pieces that make up a typical manual install of mingw or http://www.tdragon.net/recentgcc/ I saw the runtime and w32api stuff in my very quick scan of the llvm-gcc dir and didn't bother to confirm binutils :frowning:

I still would like to see this packaging info made a bit more visible outside the ML, as well as a note clarifying whether the binary setup is still valid when the w32api, mingw-runtime, and binutils packages are updated (independently of llvm-gcc) with newer binary versions from mingw.org.

It would be really helpful for those of us who currently only have a teeny bit of time to start looking at LLVM and are really bad at keeping our curiousity in check :slight_smile:

Take me up on my offer to submit a doc patch...point me to the proper html source and I'll send you a diff for review.

Jon

Hello, Jon

What threw me was the projects inclusion of 2 of the 3 other pieces that make up a typical manual install of mingw or http://www.tdragon.net/recentgcc/ I saw the runtime and w32api stuff in my very quick scan of the llvm-gcc dir and didn't bother to confirm binutils :frowning:

Well, binutils are quite different:
1. It's GPL-licensed, thus we need to provide sources as well, which
is bit inconvenient
2. You need to have headers & libs in predefined dirs to let gcc /
llvm-gcc pick them w/o any additional options, this is not case of
binutils - you just need stuff in path

Take me up on my offer to submit a doc patch...point me to the proper html source and I'll send you a diff for review.

Just grab the GettingStarted.html page, seems to be pretty convenient place.

Thanks!

Hi Jon,

Just in case it's not clear, the svn for that page is part of the llvmCore project. Specifically,

https://llvm.org/svn/llvm-project/llvm/trunk/docs/GettingStarted.html

Thanks for offering to help with the documentation. Making things clearer for new users is always a good thing.

Regards,
   Jim

Just in case it's not clear, the svn for that page is part of the
llvmCore project. Specifically,

https://llvm.org/svn/llvm-project/llvm/trunk/docs/GettingStarted.html

Thanks for offering to help with the documentation. Making things
clearer for new users is always a good thing.

Regards,
   Jim

If I do a sparse checkout like

svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm-trunk --depth empty
cd llvm-trunk
svn up --depth files docs

and send you mods via an "svn diff" as an attachment using GTK+ based http://sylpheed.sraoss.jp/en/ will that work?

Note the doc/* files came in to my local repo as CRLF based. I'm guessing their LF on your systems.

Anything special I need to do for edit/diffing for the patch so you don't have to deal with EOL nonsense?

Jon

Just in case it's not clear, the svn for that page is part of the
llvmCore project. Specifically,

https://llvm.org/svn/llvm-project/llvm/trunk/docs/GettingStarted.html

Thanks for offering to help with the documentation. Making things
clearer for new users is always a good thing.

Regards,
  Jim

If I do a sparse checkout like

svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm-trunk --depth empty
cd llvm-trunk
svn up --depth files docs

and send you mods via an "svn diff" as an attachment using GTK+ based http://sylpheed.sraoss.jp/en/ will that work?

I'm not very familiar with that tool, but if it's using "svn diff" to generate the patch, I have no reason to believe it won't work just fine. If for some reason there's issues, we can always talk it through then and figure out an alternative. Just generate the patch file and send it to the list as an attachment (not inline in the message) and things should work OK.

Note the doc/* files came in to my local repo as CRLF based. I'm guessing their LF on your systems.

Anything special I need to do for edit/diffing for the patch so you don't have to deal with EOL nonsense?

Most folks are on a *nix type system, with OSX and Linux being the most common, I think. svn generally handles the EOL conversions transparently, so it's not something I tend to notice much. I don't think there's anything special you'll need to do in that regard when preparing a patch. Worst case, a quick run of it through dos2unix or equivalent should clear up any problems with that. I'm sure if there's some magic invocation that simplifies things, Anton or another of our more Windows savvy folks will speak up and let us know.

Regards,
    -Jim

Hello, Jon

Note the doc/* files came in to my local repo as CRLF based. I'm guessing their LF on your systems.

Anything special I need to do for edit/diffing for the patch so you don't have to deal with EOL nonsense?

Well... you can always tell svn to use some predefined EOL format for
checkout. You need to add some additional stuff to
~/.subversion/config file

> If I do a sparse checkout like
>
>> svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm-trunk --
>> depth empty
>> cd llvm-trunk
>> svn up --depth files docs
>
> and send you mods via an "svn diff" as an attachment using GTK+
> based Sylpheed - lightweight and user-friendly e-mail client will that work?
>

I'm not very familiar with that tool, but if it's using "svn diff" to
generate the patch, I have no reason to believe it won't work just
fine.

sylpheed is a GTK+ mail client that doesn't try to be more than it needs to be. Very nice filtering and other things.

Attached is my draft patch from svn diff. GVIM tells me it's in *nix mode, but double check and let me know if any of the text needs to be changed. I focused just on the binary install of MinGW32/x86 for the front end by integrating the *nix and Windows data. As I get more experience with the MinGW32 LLVM binaries I may submit future doco patches.

Jon

win-llvm-gcc-install.patch (4.74 KB)

Hi Jon,

Attached is my draft patch from svn diff. GVIM tells me it’s in *nix mode, but double check and let me know if any of the text needs to be changed. I focused just on the binary install of MinGW32/x86 for the front end by integrating the *nix and Windows data. As I get more experience with the MinGW32 LLVM binaries I may submit future doco patches.

Thanks again for having a look at this. Definitely worthwhile additions and should help other new users on Windows more easily get up and running. The patch applied cleanly for me on OSX, so whatever process you used works fine.

Below are a few comments. Apologies in advance for the nit-picky nature of some of them.

  • Note: If the binary extension is ".bz" use bunzip2 instead of gunzip.
  • +
  • Note: Windows users should use 7-Zip or similar
  • +
  • Note: Windows users see Install GCC Front End for more info
  • Add llvm-gcc's "bin" directory to your PATH variable.
  • For parallel structure here, please use active voice. For example, “On windows, use …” Also nit-picky, but add a period at the end of the sentence. The cross-reference to “Install the GCC Front End” is missing “the” in the title. It probably is worth making this a hyperlink in the original #4 bullet point rather than a separate note since it applies to all, not just Windows users.

    -

    To install the GCC front end, do the following:


    +

    To install the GCC front end, do the following (for Windows users you’ll want to use an
    +archive tool like 7-zip that can handle gzipped tars):

    Instead of “for Windows users you’ll want to”, perhaps something like, “on Windows, use”.

    +

    As a convenience for Windows users, the front end binaries for MinGW/x86 include
    +versions of both the w32api and mingw-runtime binaries required for proper operation.
    +However, the binary binutils package from MinGW is
    +required in order to have a fully functioning binary LLVM GCC front end installation. While

    +not quite the same as a fully manual MinGW installation, it should be quite similar to those
    +who have used MinGW on Windows systems.


    +
    +

    Windows users need to do the following in order to complete the front end installation:


    +

    Since the necessity of obtaining the binutils is referenced in the above paragraph, this can probably be simplified to something like, “To install binutils on Windows:”.

    Regards,
    Jim

    Below are a few comments. Apologies in advance for the nit-picky
    nature of some of them.

    Updated version attached with all your feedback, and others, hopefully fixed.

    No applogies needed, attention to the details is always great. How often does documentation get the short shrift that we would never think of giving to code :wink:

    Jon

    win-llvm-gcc-install-v2.patch (6.53 KB)

    Excellent! Checked in as r91603. Thank you.

    Regards,
       -Jim

    > What threw me was the projects inclusion of 2 of the 3 other pieces that make up a typical manual install of mingw or http://www.tdragon.net/recentgcc/ I saw the runtime and w32api stuff in my very quick scan of the llvm-gcc dir and didn't bother to confirm binutils :frowning:
    Well, binutils are quite different:
    1. It's GPL-licensed, thus we need to provide sources as well, which
    is bit inconvenient

    To make it easier to use the LLVM-GCC MinGW32 binary and meet your GPL licensing requirements, could you embed the MinGW binutils binary as-is in the LLVM-GCC MinGW32 and update the LLVM docs to point to the MinGW SourceForge download site for those wanting the MinGW binutils source?

    Is the GPL the only reason why binutils isn't currently included in the LLVM-GCC MinGW32 binary?

    http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites

    Jon