search for: release_22

...got to install bison before compiling llvm, but configure did not complain about this. After I installed bison and tried over, the build worked perfectly. So I'm guessing this is a bug in the configure scripts somewhere. I use linux on x86 with gcc 4.2.2 and as said llvm from svn llvm/branches/release_22 Baldrick helped me realize what was wrong (by building the same checkout and confirming it worked) and encouraged me to write about it here. - Tomas

...to date] master -> llvm.org/master = [up to date] release_1 -> llvm.org/release_1 = [up to date] release_16 -> llvm.org/release_16 = [up to date] release_20 -> llvm.org/release_20 = [up to date] release_21 -> llvm.org/release_21 = [up to date] release_22 -> llvm.org/release_22 = [up to date] release_23 -> llvm.org/release_23 = [up to date] release_24 -> llvm.org/release_24 = [up to date] release_25 -> llvm.org/release_25 = [up to date] release_26 -> llvm.org/release_26 = [up to date] release_27 -> llv...

...d. > The git mirrors only contain what's in trunk in the SVN repos. I think it contains branches of several previous releases: $ git branch -r llvm-upstream/master llvm-upstream/release_1 llvm-upstream/release_16 llvm-upstream/release_20 llvm-upstream/release_21 llvm-upstream/release_22 llvm-upstream/release_23 llvm-upstream/release_24 llvm-upstream/release_25 llvm-upstream/release_26 llvm-upstream/release_27 llvm-upstream/release_28 llvm-upstream/release_29 llvm-upstream/svn-tags/RELEASE_1 llvm-upstream/svn-tags/RELEASE_20 llvm-upstream/svn-tags/RELEASE_21 l...

...sform_name substitutions. This problem was likely introduced within this change +if test "$program_transform_name" = s,x,x,; then Revision *43990*<http://llvm.org/viewvc/llvm-project?view=rev&revision=43990>- ( view<http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/release_22/configure?revision=43990&view=markup>) (download<http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/release_22/configure?revision=43990>) (annotate<http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/branches/release_22/configure?annotate=43990>) - [select for diffs]<http:...

...-> llvm.org/master > = [up to date] release_1 -> llvm.org/release_1 > = [up to date] release_16 -> llvm.org/release_16 > = [up to date] release_20 -> llvm.org/release_20 > = [up to date] release_21 -> llvm.org/release_21 > = [up to date] release_22 -> llvm.org/release_22 > = [up to date] release_23 -> llvm.org/release_23 > = [up to date] release_24 -> llvm.org/release_24 > = [up to date] release_25 -> llvm.org/release_25 > = [up to date] release_26 -> llvm.org/release_26 > = [up to date]...

On 2011-08-29 04:21, Kurt Lidl wrote: > While I agree bootstrapping a new mirror from scratch is time and > resource consuming, this can be largely avoided by making a seed > of the svn tree available. (Basically, I think that looks like > a compressed tar file of the svn repository.) Or, a svnadmin dump > of the repo could be made available for the adventurous. Having the same

...Z) referenced in function "public: __thiscall `anonymous namespace'::ForcePassLinking::ForcePassLinking(void)" (??0ForcePassLinking@?A0xe41c907a@@QAE at XZ) 1>C:\work\s\llvm\win32\\bin\Win32\Debug/opt.exe : fatal error LNK1120: 1 unresolved externals It'd be fine for me to use RELEASE_22 tag, but since cfe doesn't have a matching tag, this doesn't quite work. I tried checking out cfe of the same date as RELEASE_22 tag and got errors of clang mismatching llvm header files. I realize that msvs build is not of high priority but whoever shuffles the files around and changes t...

..."branches = branches/*:refs/remotes/origin/*" > into something like "branches = branches/*:refs/remotes/branches/*" This is exactly what was done on llvm.org. Here is an example fron clang.git: fetch = trunk:refs/heads/master tags = tags/{RELEASE_20,RELEASE_21,RELEASE_22,RELEASE_23,RELEASE_24,RELEASE_25,RELEASE_26,RELEASE_27,RELEASE_28,RELEASE_29,RELEASE_30,RELEASE_31}:refs/heads/svn-tags/* branches = branches/{release_20,release_21,release_22,release_23,release_24,release_25,release_26,release_27,release_28,release_29,release_30,release_31}:refs/heads/* -...

Hi Anton, On Thu, Apr 26, 2012 at 4:05 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Sebastian, > >> I just saw that the git branch remotes/origin/release_31 has been created >> for llvm.  Unfortunately it is missing the right context: right now I can only >> see 11 patches in that branch with the last patch having no parent. >> >> Could

On Wed, Aug 17, 2011 at 01:47:02PM -0700, Benjamin Kramer wrote: > On 17.08.2011, at 11:36, Kurt Lidl <lidl at pix.net> wrote: > > > Why can't I mirror the whole tree? > > The original reason for this limitation was that complete checkouts > put a lot of stress on the server. While I agree bootstrapping a new mirror from scratch is time and resource consuming,

...he same undefined reference error if I call the llvm::createXXXPass and llvm::verifyXXX functions although I included all the files like in the Kaleidoscope tutorial. Everything else works fine though. I'm compiling my project with gcc-4.2 and llvm-config with --libs all and I'm using the RELEASE_22 tag from subversion and Eclipse CDT with managed make (on Ubuntu 32bit). This is the full command that's executed to link the project and its output: g++-4.2 `/home/stefan/projects/llvm/Debug/bin/llvm-config --ldflags --libs` `pkg-config --libs glibmm-2.4` -o"mojo" ./src/mojo.o ./s...

...end. > The git mirrors only contain what's in trunk in the SVN repos. I think it contains branches of several previous releases: $ git branch -r llvm-upstream/master llvm-upstream/release_1 llvm-upstream/release_16 llvm-upstream/release_20 llvm-upstream/release_21 llvm-upstream/release_22 llvm-upstream/release_23 llvm-upstream/release_24 llvm-upstream/release_25 llvm-upstream/release_26 llvm-upstream/release_27 llvm-upstream/release_28 llvm-upstream/release_29 llvm-upstream/svn-tags/RELEASE_1 llvm-upstream/svn-tags/RELEASE_20 llvm-upstream/svn-tags/RELEASE_21 l...

...the external tests, those should be included as well. Note that this testing regimen requires validators to build and test llvm-gcc as well as the native LLVM tools. The tags themselves should live under the tags tree. One possible tagging scheme looks like this: trunk tags ... RELEASE_21 RELEASE_22 RELEASE_23 validated ALL development_24 r54582 X86 development_24 r53215 r54100 r54582 X86-64 (? maybe covered by x86) ... PowerPC ... Alpha ... Sparc ... Mips ... ARM ... CellSPU...