search for: executable_path

...the library (who now need to pass special flags to their linker) and unless there's a pressing need for them, most libraries avoid the practice. Indeed, the use of @rpath in LLVM seems to have been a bit confusing and has undergone dozens of changes over time, with reverts, changes to and from @executable_path (a related but different relative path inside the macOS loader), and so on. Here's the commit that seemed to introduce it: https://github.com/llvm-mirror/llvm/commit/fb24ccfa32c12dc7ab12b70f2c3db404dbab7581 Here's one of the reverts of the reverts: https://github.com/llvm-mirror/llvm/commi...

...l LLVM into the GCC_INSTALL_PREFIX. --- CMakeLists.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 9ec3e33..c85a028 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -450,7 +450,12 @@ if (APPLE) set(CMAKE_INSTALL_RPATH "@executable_path/../lib") else(UNIX) if(NOT DEFINED CMAKE_INSTALL_RPATH) - set(CMAKE_INSTALL_RPATH "\$ORIGIN/../lib") + if(DEFINED GCC_INSTALL_PREFIX) + set(CMAKE_INSTALL_RPATH "${GCC_INSTALL_PREFIX}/lib") + else() + set(CMAKE_INSTALL_RPATH "\$ORIGIN/../lib"...

AFAIK, ld does not use DYLD_LIBRARY_PATH to lookup libLTO.dylib but contains a reference to @executable_path/../lib/libLTO.dylib. The only way I managed to load a different LTO library than the default one is to create a symlink pointing to the actual ld binary (as returned by 'xcrun -find ld') and making sure the library I want to load is placed at ../lib/libLTO.dylib relatively to this symlink....

We do it by setting DYLD_LIBRARY_PATH. That overrides the normal @executable_path lookup. On Nov 12, 2013, at 10:09 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > AFAIK, ld does not use DYLD_LIBRARY_PATH to lookup libLTO.dylib but contains a reference to @executable_path/../lib/libLTO.dylib. > > The only way I managed to load a different LTO library...

...an be found at https://github.com/Homebrew/homebrew/issues/47149 From what I can tell, this is a result of lines 561-564 of the CMakeLists.txt in the main LLVM repo: set(CMAKE_BUILD_WITH_INSTALL_RPATH ON) if (APPLE) set(CMAKE_INSTALL_NAME_DIR "@rpath") set(CMAKE_INSTALL_RPATH "@executable_path/../lib") Is there a reason these variables are hardcoded? -Alex

For dogfooding the compiler I normally use is a LTO bootstrap of clang. On linux that is simple to do that since clang passes the correct plugin to the linker. On OS X ld64 uses libLTO.so it finds via DYLD_LIBRARY_PATH. Should clang set that before running the linker? Is there a better way for clang to tell the linker which libLTO.so to use? Cheers, Rafael

...gt; CMakeFiles/LLVMObject.dir/RecordStreamer.cpp.o > CMakeFiles/LLVMObject.dir/SymbolicFile.cpp.o > CMakeFiles/LLVMObject.dir/SymbolSize.cpp.o -lxar > ../libLLVMBitReader.dylib ../libLLVMCore.dylib ../libLLVMMC.dylib > ../libLLVMMCParser.dylib ../libLLVMSupport.dylib > -Wl,-rpath, at executable_path/../lib > > and thus the linkage for llvm-objdump is directly linked against > libxar as in the default static lib build. Only the > -DLLVM_LINK_LLVM_DYLIB:BOOL=ON build attempts to resolve the symbols > from libxar using an indirect linkage on libxar in libLLVM.dylib. >...

...MObject.dir/ObjectFile.cpp.o CMakeFiles/LLVMObject.dir/RecordStreamer.cpp.o CMakeFiles/LLVMObject.dir/SymbolicFile.cpp.o CMakeFiles/LLVMObject.dir/SymbolSize.cpp.o -lxar ../libLLVMBitReader.dylib ../libLLVMCore.dylib ../libLLVMMC.dylib ../libLLVMMCParser.dylib ../libLLVMSupport.dylib -Wl,-rpath, at executable_path/../lib and thus the linkage for llvm-objdump is directly linked against libxar as in the default static lib build. Only the -DLLVM_LINK_LLVM_DYLIB:BOOL=ON build attempts to resolve the symbols from libxar using an indirect linkage on libxar in libLLVM.dylib. Jack >> >>...

...object.o process.o procfs.o ptrace.o queue.o region.o registry.o request.o semaphore.o serial.o signal.o snapshot.o sock.o symlink.o thread.o timer.o token.o trace.o unicode.o user.o window.o winstation.o -L../libs/wine -lwine ../libs/port/libwine_port.a && install_name_tool -change @executable_path/`../tools/relpath /Users/fridbert/winegit/bin /Users/fridbert/winegit/lib`/libwine.1.dylib @executable_path/../libs/wine/libwine.1.dylib wineserver || rm -f wineserver Undefined symbols: "_sched_setscheduler", referenced from: _set_thread_priority in thread.o ld: symbol(s) not fou...

...;> -Wl,-dead_strip CMakeFiles/llvm-objdump.dir/llvm-objdump.cpp.o >> CMakeFiles/llvm-objdump.dir/COFFDump.cpp.o >> CMakeFiles/llvm-objdump.dir/ELFDump.cpp.o >> CMakeFiles/llvm-objdump.dir/MachODump.cpp.o -o ../../bin/llvm-objdump >> ../../lib/libLLVM.dylib -Wl,-rpath, at executable_path/../lib -lxar >> >> eliminates the bootstrap failure. >> >>> >>> Kev >>> >>>> On May 24, 2016, at 10:28 AM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: >>>> >>>> On Tue, May 24, 2016 at 1:24 PM, Jack...

...;> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/CMakeLists.txt b/CMakeLists.txt >> index 9ec3e33..c85a028 100644 >> --- a/CMakeLists.txt >> +++ b/CMakeLists.txt >> @@ -450,7 +450,12 @@ if (APPLE) >> set(CMAKE_INSTALL_RPATH "@executable_path/../lib") >> else(UNIX) >> if(NOT DEFINED CMAKE_INSTALL_RPATH) >> - set(CMAKE_INSTALL_RPATH "\$ORIGIN/../lib") >> + if(DEFINED GCC_INSTALL_PREFIX) >> + set(CMAKE_INSTALL_RPATH "${GCC_INSTALL_PREFIX}/lib") >> + else() >...

I'm far from an expert on the subject matter. Maybe some app that was written for Linux/BSD or whatever is looking at a LD_LIBRARY_PATH on its own and its nothing to do with the OS? I've never tried messing with LD_LIBRARY_PATH on OSX, but its not *supposed* to do anything normally. The OS Relies on DYLD_LIBRARY_PATH. If you change it, you have to make sure it encompasses every single

...,-headerpad_max_install_names -L/sw/lib -Wl,-dead_strip CMakeFiles/llvm-objdump.dir/llvm-objdump.cpp.o CMakeFiles/llvm-objdump.dir/COFFDump.cpp.o CMakeFiles/llvm-objdump.dir/ELFDump.cpp.o CMakeFiles/llvm-objdump.dir/MachODump.cpp.o -o ../../bin/llvm-objdump ../../lib/libLLVM.dylib -Wl,-rpath, at executable_path/../lib -lxar eliminates the bootstrap failure. > > Kev > >> On May 24, 2016, at 10:28 AM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: >> >> On Tue, May 24, 2016 at 1:24 PM, Jack Howarth >> <howarth.mailing.lists at gmail.com> wrote: >&g...

...names -L/sw/lib > -Wl,-dead_strip CMakeFiles/llvm-objdump.dir/llvm-objdump.cpp.o > CMakeFiles/llvm-objdump.dir/COFFDump.cpp.o > CMakeFiles/llvm-objdump.dir/ELFDump.cpp.o > CMakeFiles/llvm-objdump.dir/MachODump.cpp.o -o ../../bin/llvm-objdump > ../../lib/libLLVM.dylib -Wl,-rpath, at executable_path/../lib -lxar > > eliminates the bootstrap failure. > >> >> Kev >> >>> On May 24, 2016, at 10:28 AM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: >>> >>> On Tue, May 24, 2016 at 1:24 PM, Jack Howarth >>> <howart...

Hi Jack, Just a guess here, this may be the bug Chris helped me out with in the use of the include file xar/xar.h which is not C++ safe. I needed to wrap my include via: #ifdef HAVE_LIBXAR extern "C" { #include <xar/xar.h> } #endif I think we may need some help from Chris to track this down. I’ll bug him in a bit to see if he can help us on this. Kev > On May 24, 2016, at

...ipts. << DescPackaging: << The file libLTO.dylib in %p/lib/llvm/lib can be used to replace the libLTO.dylib in /Developer/usr/lib from Xcode 3.1.2 to enable full LTO support at -O4 in the compilers of the llvm-gcc42 package. Note that the fink maintainer mode doesn't understand the @executable_path/../lib/libLTO.dylib syntax in libLTO.dylib's otool -L output. << Homepage: http://llvm.org/ Maintainer: None <fink-devel at lists.sourceforge.net> <<

On Tue, May 24, 2016 at 1:24 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 1:22 PM, Jack Howarth > <howarth.mailing.lists at gmail.com> wrote: >> On Tue, May 24, 2016 at 12:08 PM, Reid Kleckner <rnk at google.com> wrote: >>> Kevin Enderby added those symbol uses in r270491. It has a cmake >>> feature test, and

On 04/10/2010 08:01 PM, Jack Howarth wrote: > > bash-3.2$ GCC=/sw/bin/gcc-4 CC=gcc-4 CXX=g++-4 CFLAGS=-I/sw/include CXXFLAGS=-I/sw/include LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config make > g++-4 -c -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -MD -MP -DIN_GCC -DREVISION=\"100954M\"

On Sat, Apr 10, 2010 at 01:52:18PM +0200, Duncan Sands wrote: > Hi Jack, > > > Is anyone building dragon-egg on darwin? > > Anton built it once. There were some problems with dynamic libraries: gcc's > plugin support requires the use of dynamic libraries, and the configure logic > it uses thinks that darwin does not support dynamic libraries! So it is >