similar to: [LLVMdev] Error building with Mingw on Win7

On 6/22/2010 2:47 PM, J. Garrett Morris wrote: > Hello everyone, > > I've run across a problem building LLVM 2.7 with Mingw on Win7. When > I try make VERBOSE=1, it churns away happily for a while and then > produces: > > /c/Perl/bin/perl /c/Programs32/llvm-2.7/utils/GenLibDeps.pl -flat /c/Programs > 32/llvm-2.7/obj/Release/lib "/mingw/bin/nm">

Kenneth Boyd <zaimoni at zaimoni.com> writes: [snip] >> That does not really surprise me about CMake, but then mingw is not a >> primary compiler on Windows, more so is VC++ or Intel, either way a >> bug should be submitted to the CMake devs. > I do not want to troll the CMake devteam, so I will not submit the bug > report without a full-blown patch. The CMake

Hi, I'm trying to build clang under MingW, but I'm getting a number of errors. Could anyone provide some hints as to what you had to do? I got some tips from http://blogs.tedneward.com/2008/02/24/Building+LLVM+On+Windows+Using+MinGW32.aspx, but using the newer packages, as it's a bit old. The ./configure seems to run without errors. The first run of make aborts with errors like:

Óscar Fuentes wrote: > The CMake devteam is very responsive about bug reports. They will > certainly appreciate your bug report, no patch required. > I still don't think I have enough detail to file a bug report (not sure exactly what they need to know about my system configuration to make it testable). I did go ahead (just now) and ask the main CMake mailing list which files I

Kenneth Boyd <zaimoni at zaimoni.com> writes: >> I'm seeing a failure related to circular library references while >> building LLVM with CMake and MSYS. This didn't happen on the >> past. Building with the configure script works, so it seems something >> related to CMake. Do you have any insight on this? >> > I'll get back on this tonight or

SevenThunders wrote: > > > Someone reported this earlier but the situation remains unchanged. > > -Matt > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > Thanks for getting it back up so quickly. Now if I

Kenneth Boyd <zaimoni at zaimoni.com> writes: >>> * I am seeing desynchronization between the configure-generated >>> Makefiles and the CMakeFile.txt files. [e.g., llc; makefile doesn't >>> have asmprinter, CMakeFile.txt does]. That much I should be able to >>> construct a patch for "blind", if no-one gets to it first. >>>

Óscar Fuentes wrote: > Kenneth Boyd <zaimoni at zaimoni.com> writes: > > [snip] > >> My internal priority for that CMake patch is low, as I need only minimal >> patching to use the autoconf-generated configure script to build LLVM. >> Right now it's just llvm.config.in.in that needs patching (the failsafed >> GenLibDeps.pl script went in

Óscar Fuentes wrote: > Kenneth Boyd <zaimoni at zaimoni.com> writes: > >> * I am seeing desynchronization between the configure-generated >> Makefiles and the CMakeFile.txt files. [e.g., llc; makefile doesn't >> have asmprinter, CMakeFile.txt does]. That much I should be able to >> construct a patch for "blind", if no-one gets to it first.

John Thompson wrote: > Hi, > > I'm trying to build clang under MingW, but I'm getting a number of > errors. Could anyone provide some hints as to what you had to do? I > got some tips from > http://blogs.tedneward.com/2008/02/24/Building+LLVM+On+Windows+Using+MinGW32.aspx, > but using the newer packages, as it's a bit old. > > The ./configure seems

My 7 zip file manager says that the mingw binary is corrupt for llvm 1.9. I suppose that means that those of us running windows have no hope of getting llvm right now? Someone reported this earlier but the situation remains unchanged. -Matt

Óscar Fuentes wrote: > Kenneth Boyd <zaimoni at zaimoni.com> writes: > > > ..... >> From the existence of the dependency-tracker scripts, it obviously was >> a problem for autoconf as well. >> > > This seems a different issue, but are those dependency-tracker scripts > for tracking dependencies among cpp files and its headers? CMake gives >

Kenneth Boyd <zaimoni at zaimoni.com> writes: >> 1) either CMake becomes the de facto standard for LLVM, deprecating >> autoconf&&gmake and thus requiring the developers to update the >> CMakeLists.txt files to compile their sources... >> > Sorry, but this is a noticeable obstacle for CMake becoming the de-facto > standard for LLVM. Writing a new

OvermindDL1 wrote: > On Sat, Oct 11, 2008 at 7:30 AM, Kenneth Boyd <zaimoni at zaimoni.com> wrote: > >> At the absolute minimum, simple counting of the success/failure/internal >> error results requires three different exit codes, and a test driver >> capable of tallying them up and reporting all failures (unexpected >> success, unexpected failure, and

Jeffrey Yasskin wrote: >> Would you try the patch at >> http://codereview.appspot.com/download/issue968046_1.diff? It should >> make the BSDs fall into the same path as Linux, and since you use gnu >> ld, that should work for you. >> > > Ping? > Sorry for the delay. Here is what I am getting after applying the patch: gmake[2]: Leaving directory

Óscar Fuentes wrote: > Kenneth Boyd <zaimoni at zaimoni.com> writes: > > >>>> Isn't is possible for cmake just to glob everything in the corresponding >>>> directory? >>>> >>>> >>> Yes, but then the build would not notice a change on the file >>> structure. You'll need to explicitly invoke

Anton Korobeynikov wrote: > Hello, Jonathan > > >> I thought I'd messed up something related to the linker, >> but I couldn't explain why XP would work using the same steps. >> > The only thing comes to my mind seeing this: perl from msysDTK works > differently (somehow) on Vista, thus llvm-config is broken which leads > to missed libraries,

Hi Nathan, > The latter being what GenLibDeps.pl expects to see. All else being > equal though, it might be better to change GenLibDeps.pl to recognize > the first version: > --- GenLibDeps.pl (revision 78653) > +++ GenLibDeps.pl (working copy) > @@ -100,7 +100,7 @@ > print " <dt><b>$lib</b</dt><dd><ul>\n";

Duncan Sands wrote: > Hi Nathan, > > >> The latter being what GenLibDeps.pl expects to see. All else being >> equal though, it might be better to change GenLibDeps.pl to recognize >> the first version: >> --- GenLibDeps.pl (revision 78653) >> +++ GenLibDeps.pl (working copy) >> @@ -100,7 +100,7 @@ >> print "

Hi all, I've encountered a couple of minor build issues on Solaris that have crept in since 2.5, fixes below: 1. In lib/Target/X86/X86JITInfo.cpp, there is: // Check if building with -fPIC #if defined(__PIC__) && __PIC__ && defined(__linux__) #define ASMCALLSUFFIX "@PLT" #else #define ASMCALLSUFFIX #endif Which causes a link failure due to the non-PLT