search for: libfoo

Hi list, Say a package has a dependency for libfoo.so.1, and 2 (or more) packages provide libfoo.so.1, how does yum decide which package to install to meet the dependency?

On Fri, 21 Jul 2017, Matthew Miller wrote: > On Fri, Jul 21, 2017 at 04:19:20PM +0100, Phil Perry wrote: >> Say a package has a dependency for libfoo.so.1, and 2 (or more) >> packages provide libfoo.so.1, how does yum decide which package to >> install to meet the dependency? > > It has a series of heuristics: > > http://yum.baseurl.org/wiki/CompareProviders That's fabulous. You mean Phil could have fixed my issue b...

...and Gold linkers do not support this feature and take in account only the last -init/-fini options. % cat foo.c int a = 0; void foo() { a += 1; } void bar() { a += 2; } % cat main.c extern int a; int printf(const char *, ...); int main() { printf("a: %d\n", a); } % gcc -fPIC -shared -o libfoo.so -Wl,-init,foo -Wl,-init,bar foo.c % gcc main.c -L. -lfoo -Wl,-rpath,. % ./a.out 2 % gcc -fPIC -shared -o libfoo.so -Wl,-init,bar -Wl,-init,foo foo.c % ./a.out 1 What is the reason of this incompatibility? The question is caused by attempt to support DT_INIT/DT_FINI dynamic table tags. The tabl...

The attached unified diff fixes configure so that all --with-libfoo options are allowed to be --with-libfoo=PATH. If the option is specified with a PATH, only that PATH is searched for the library. If it is specified as =yes or with no argument, it tries without modifying anything, and then tries looking in /usr/local. The SunOS5 targets no longer add /usr/loca...

...de. 2. Keep the warning for linking dynamic libraries in LinkLibraries.cpp I still don't have a good solution to the problem of -L paths that include bytecode versions of the native libraries we're trying to link. Consider the following situation... A directory in our -L path has a libFoo.so native library that we need to link. It also contains a libBar.so bytecode library. Another directory in our -L path has a bytecode version of libFoo.so and a native version of libBar.so. What do we do? llvm-g++ -Wl,-native -shared -o libtest.so test.o -L/foobar -lfoo -L/barfoo -lbar /...

On 04/16/2014 05:33 PM, m.roth at 5-cent.us wrote: > And no, do *NOT* use epel and repoforge - they very frequently have > conflicts, due to prerequisites of packaging. Does the use of yum priorities take care of this concern? Thanks, Ken

gccld would barf if you tried to specify the full pathname of an archive on the command line to gcc, (e.g., instead of gcc ... -L/full/path/to -lFOO you say gcc ... /full/path/to/libFOO.a) which many GNU Makefiles try to do. This patch fixes that. Ok to commit? -- gaeke at uiuc.edu gccld.cpp: Fix typo in header. Add IsArchive static method. Roll LoadLibraryFromDirectory() into LoadLibrary(), and factor LoadLibraryExactName() out of the result. Instead of treating the cur...

Hi, I have conventional directory structure for a pass taken from project examples. I want to build a tool which makes usage of a shared library which is included in the project. This means that I have library here: # lib/foo/*.cc and after compilation the library is placed here # Debug/lib/libfoo.so My tool is located here: # tool/test_foo # cat tool/Makefile LEVEL = ../ TOOLNAME=test_foo LIBS += -lfoo When I build the tool: # (cd tool && make) llvm[0]: Compiling test_foo.cc for Debug build llvm[0]: Linking Debug executable test_foo ... undefined reference ... collect2: ld return...

...amuel Thibault wrote: > Ian Campbell, le Tue 08 Sep 2015 17:15:40 +0100, a ?crit : > > Is it at all possible (even theoretically) to take a shared library > > (which > > is relocatable as required) and to do a compile time static linking > > pass on > > it? i.e. use libfoo.so but still do static linking? > > ? gcc test.c -o libtest.so -shared -Wl,--relocatable > /usr/bin/ld.bfd.real: -r and -shared may not be used together Sorry, my suggestion was a bit garbled, to say the least... I meant more "link an application against it statically even though it...

Hi all, and thanks for everyone's work on the 4.0 release! There's been recent discussion on the OpenSC mailing list about getting better/updated smartcard support into OpenSSH. Originating from an OpenSSH package maintainer's desire to keep dependencies to a minimum, the idea to load OpenSC dynamically popped up. Now the question is whether this is an approach that would be favored

...hen did the following: 1. Set CC to clang. 2. Set CXX to clang++. 3. Run cmake and let it figure out that its using Clang on Windows. 4. Build and realize that the link doesn't work because CMake pulls in the wrong libraries (per default it uses Microsoft naming conventions: foo.lib instead of libfoo.a). 5. Search good old Google and find this VERY helpful article: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/42398 6. Fix CMake as per the above. 7. Build and realize that the CMake pulls in the right libraries but still a torrent of errors are reported: ..\libBackend.a(Backen...

...Clang questions should be asked in other ML. > 3. Run cmake and let it figure out that its using Clang on Windows. > 4. Build and realize that the link doesn't work because CMake pulls in the > wrong libraries (per default it uses Microsoft naming conventions: foo.lib > instead of libfoo.a). It seems like you're not targeting mingw32, but MS toolchains. Stuff won't work smooth here and major WIP. Everything else below can be ignored. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...t, main.c: ----------------- extern void foo(); int main() { foo(); return 0; } ---------------- foo.c --------------- #include <stdio.h. void foo() { printf("hello\n"); return; } ---------------- And the command lines: llvm-gcc -c -o main.o main.c gcc -o foo.o foo.c ar rcs libfoo.a foo.o llvm-gcc -Wl,-native main.o -L. -lfoo It's *OK* Thanks in advance for solving my problem. :) And I personally think it may possiblely puzzle other users, maybe it deserves its place in FAQ or in man page for LLVM. On Friday 02 June 2006 13:13, Chris Lattner wrote: > On Fri, 2 J...

Dear all, I tried to install rgl package on my linux machine fc5, I got an error. Here I run R as user, $ R > options(repos=c(CRAN="http://cran.at.r-project.org/")) > install.packages("rgl", lib="/home/subianto/local/lib/R/library/site-packages", dependencies=TRUE) trying URL 'http://cran.at.r-project.org/src/contrib/rgl_0.67-2.tar.gz' Content type

...foo") in a source file, then on a linker that supports framework linking the linker would add to the link the first matching file trying: ./foo <first library search path>/foo <second library search path>/foo .. <nth library search path>/foo <first library search path>/libfoo.so <second library search path>/libfoo.so .. <nth library search path>/libfoo.so <first library search path>/libfoo.a <second library search path>/libfoo.a .. <nth library search path>/libfoo.a <first framework search path>/foo.framework/foo <second library s...

...t;> Yes but the (distro?) tools relies on the soname for linking and the >> soname was updated. > > Is soname an attribute that is stored somewhere within the shared library, or does > it refer to the name of the shared object file? It is stored inside (and built with -Wl,-soname,libfoo.so.0) For example, in Debian (and Ubuntu), we consider that a library in /usr/lib/* without a soname is an error. Example: $ objdump -p /usr/lib/x86_64-linux-gnu/libLLVM-3.4.so.1 |grep SONAME SONAME libLLVM-3.4.so.1 Cheers, Sylvestre

...ine. This is linker options. Now it might be that on a specific platform (e.g. MSVC) you can represent #pragma comment(lib, "foo") using linker options; however, in general they are distinct. I would like the following behaviour for ELF:.. #pragma comment(lib, "foo") => add libfoo.a to the link. #pragma comment(lib, "foo.a") => add foo.a to the link #pragma comment(lib, "c:\\foo.a") => add c:\foo.a to the link .. but there is no existing ELF linker command line option that maps to this behaviour; so, it is better to have a separate representation....

...s on the soname for linking and the >>>> soname was updated. >>> >>> Is soname an attribute that is stored somewhere within the shared library, or does >>> it refer to the name of the shared object file? >> It is stored inside (and built with -Wl,-soname,libfoo.so.0) >> For example, in Debian (and Ubuntu), we consider that a library in >> /usr/lib/* without a soname is an error. >> >> Example: >> $ objdump -p /usr/lib/x86_64-linux-gnu/libLLVM-3.4.so.1 |grep SONAME >> SONAME libLLVM-3.4.so.1 >> &gt...

I have tried to invoke a transformation/optimization pass using -mllvm, without success. I might be missing something. For example I have a shared/dynamic library which contains LLVM passes. I used to invoke them with llvmc like this: >>*llvmc mycode.c -o mycode.o -c -opt -Wo,=-load,libFoo.dylib,-Foo* Can this style of optimization be executed using -mllvm argument? Thx, PMon On Sun, Mar 4, 2012 at 3:48 PM, Tobias Grosser <tobias at grosser.es> wrote: > On 03/04/2012 02:32 PM, Harel Cain wrote: > > Thanks, but I'm not sure I understand. I see no such flag in c...

On Fri, Jul 21, 2017 at 04:19:20PM +0100, Phil Perry wrote: > Say a package has a dependency for libfoo.so.1, and 2 (or more) > packages provide libfoo.so.1, how does yum decide which package to > install to meet the dependency? It has a series of heuristics: http://yum.baseurl.org/wiki/CompareProviders -- Matthew Miller <mattdm at fedoraproject.org> Fedora Project Leader