search for: library_names

$(llvm-config --libs | tr " " "\n" | grep gtest) returns: -lgtest_main -lgtest instead of non-valid: -lLLVMgtest_main -lLLVMgtest It also fixes: $(ld): cannot find -lLLVMgtest $(ld): cannot find -lLLVMgtest_main --- unittests/Makefile.unittest | 2 +- utils/llvm-build/llvmbuild/componentinfo.py | 4 ++-- utils/llvm-build/llvmbuild/main.py |

[ Please CC me I ma not subcribed to this mailing-list ] [ CC Tom and Hans as LLVM/stable maintainers ] Hi, I want to understand the version handling in LLVM/Clang/LLD. Normally, I build from "release/10.x" Git branch by using the tool tc-build from ClangBuiltLinux project. With "llvm-10.0.1-rc1" Git tag I was able to setup a llvm-toolchain consisting of the projects

On Wed, May 20, 2020 at 5:06 PM Tom Stellard <tstellar at redhat.com> wrote: > > On 05/19/2020 09:05 PM, Sedat Dilek wrote: > > Hi Tom, > > > > thanks and congrats for LLVM 10.0.1-rc1 release. > > > > [1] shows 2 assets. > > 10.0.0 RCs had a lot of more assets. > > I am missing the llvm-project-10.0.1rc1.tar.xz tarball. > > > > Will

...ogen.sh && ./configure --enable-static --disable-shared && make It worked earlier, and it works now with the current git sources. In this case libFLAC.la contains the following lines: # The name that we can dlopen(3). dlname='' # Names of this library. library_names='' # The name of the static archive. old_library='libFLAC.a' When ./configure is called without arguments, these lines contain: # The name that we can dlopen(3). dlname='libFLAC-8.dll' # Names of this library. library_names='libFLAC.dll....

Why does Ruby-1.9.2-p0 require an additional ../ for relative paths when compared to the same code for ruby1.8? if RUBY_VERSION < ''1.9'' require File.dirname(__FILE__) + library else require_relative File.dirname(__FILE__) + ''/..'' + library end -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core"

On Wed, May 20, 2020 at 11:12 PM Tom Stellard <tstellar at redhat.com> wrote: > > On 05/20/2020 09:53 AM, Sedat Dilek wrote: > > On Wed, May 20, 2020 at 5:06 PM Tom Stellard <tstellar at redhat.com> wrote: > >> > >> On 05/19/2020 09:05 PM, Sedat Dilek wrote: > >>> Hi Tom, > >>> > >>> thanks and congrats for LLVM

On 9/1/06, Chris Lattner <sabre at nondot.org> wrote: > On Fri, 1 Sep 2006, Michael McCracken wrote: > > I wanted to know if I should submit patches with comments around them > > like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to > > the tree. I'd like to make it as easy as possible to apply these, so > > let me know any rules I

Hi, I have a first quick patch and a question. The patch links f951 with g++ when LLVM is enabled. It's at the end of this email. I wanted to know if I should submit patches with comments around them like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to the tree. I'd like to make it as easy as possible to apply these, so let me know any rules I should be following.

On Fri, 1 Sep 2006, Michael McCracken wrote: > Hi, I have a first quick patch and a question. The patch links f951 > with g++ when LLVM is enabled. It's at the end of this email. Thanks, applied! > I wanted to know if I should submit patches with comments around them > like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to > the tree. I'd like to

Hi Tom, thanks and congrats for LLVM 10.0.1-rc1 release. [1] shows 2 assets. 10.0.0 RCs had a lot of more assets. I am missing the llvm-project-10.0.1rc1.tar.xz tarball. Will you provide them later or is there a new development/workflow decision I do not know of? BTW, the source zip and tar.gz tarballs show no sizes. I am using Mobile LTE/UMTS to download stuff from the Internet. For now I

Hi ! Here is the situation. I created a pass in lib/Transforms/Obfuscation. I added a createFlattening() in IPO.h and in my code to be able to use it in PassManagerBuilder.cpp (lib/Transforms/IPO) in the method PopulateModulePassManager() so I can add my pass to standard passes. It all works if I add all my files in the lib/Transforms/IPO directory. But I want to keep them away in the

My application is so far mostly built from scaffold. When I edit an existing record (I''ve turned off validation) the update method is called. I get this error: NoMethodError in <module>/<controller>#update You have a nil object when you didn''t expect it! You might have expected an instance of Array. The error occured while evaluating nil.+ I get the same error when

Erik de Castro Lopo wrote: > Ozkan Sezer wrote: > >> My apologies, obviously sent an old testing patch. Correct one is >> attached (declspec2.diff). Compilation tested using MinGW (gcc-3.4.5, >> binutils-2.20), and MinGW-w64 (gcc-4.5.4, binutils-2.21.90.) > > lvqcl, > > Can you please validate this new patch? It works, but only if i call ./configure without

Hi, In buildling XPS using LLVM's makefile system, I'm finding that there's a few things lacking in our support for LLVM-based projects. The items below should help but may require changes to project makefiles. I thought I'd check before just going and doing it. 1. Various autoconf generated variables (e.g. abs_top_srcdir) are set in the makefiles but not used. They

The proposed makefile changes have been committed. If you are working from CVS head and you use the LLVM Makefile System in your own project, please make a note of the following: 1. If your makefiles use any BUILD_* variables, they now need to be prefixed with PROJ_ instead of BUILD_. For example, BUILD_SRC_ROOT is now PROJ_SRC_ROOT. 2. There are additional requirements

The proposed makefile changes have been committed. If you are working from CVS head and you use the LLVM Makefile System in your own project, please make a note of the following: 1. If your makefiles use any BUILD_* variables, they now need to be prefixed with PROJ_ instead of BUILD_. For example, BUILD_SRC_ROOT is now PROJ_SRC_ROOT. 2. There are additional requirements for projects.

The llvm.cs.uiuc.edu site does not seem to be updating at the moment so it contains the old instructions. If you're looking for the new instructions on the Projects.html page, you can view them here: http://illuvium.net/docs/Projects.html Reid. On Sat, 2005-01-15 at 18:30, Reid Spencer wrote: > The proposed makefile changes have been committed. If you are working > from CVS head and

I think there''s a logical mistake in ActionViews text_helper.rb. The TextHelper modul defines the methods textilize and textilize_without_paragraph in a begin rescue block that calls require_library_or_gem "redcloth". The problem is, that this call will always fail and the methods will never be defined when you install RedCloth as a plugin under vendor/plugins. That is

...to `__ns_initparse' ./.libs/libUpTools.so: undefined reference to `__ns_parserr' collect2: ld returned 1 exit status make[1]: *** [testUpLog] Error 1 make[1]: Leaving directory `/tmp/UpTools-8.5.3' make: *** [check-am] Error 2 library.la file contains: dlname='libUpTools.so.0' library_names='libUpTools.so.0.0.0 libUpTools.so.0 libUpTools.so' old_library='libUpTools.a' inherited_linker_flags='' dependency_libs=' -L/usr/lib64 -L/lib64 -L/usr/lib64/mysql -lpq -lmysqlclient -lssl -lpthread' weak_library_names='' current=0 age=0 revision=0 installed=...

...ckes # libxapian.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.18 (1.1220.2.245 2005/05/16 08:55:27) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libxapian.so.8' # Names of this library. library_names='libxapian.so.8.0.0 libxapian.so.8 libxapian.so' # The name of the static archive. old_library='libxapian.a' # Libraries that this one depends upon. dependency_libs=' -L/usr/i686-pc-linux-gnu/bin -L/usr/i686-pc-linux-gnu/lib /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libstdc++.la...