similar to: [PATCH] ./run: Use 'prepend' function to build paths.

--- run.in | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/run.in b/run.in index 8fdf454..438a68c 100755 --- a/run.in +++ b/run.in @@ -140,15 +140,15 @@ export PERL_VALGRIND=1 export PERL_DESTRUCT_LEVEL=2 # For Python. -export PYTHON=@PYTHON@ +export PYTHON="@PYTHON@" prepend PYTHONPATH "$b/python/.libs" prepend PYTHONPATH

On Friday 13 February 2015 10:16:34 Richard W.M. Jones wrote: > Add a bash function 'prepend' for intelligently prepending elements to > paths. eg: > > prepend PYTHONPATH "/foo" > > would set PYTHONPATH to "/foo" or "/foo:<previous-contents-of-PYTHONPATH>" > > Tested by: > > (1) Building and testing libguestfs twice:

Mac OS X uses DYLD_LIBRARY_PATH rather than LD_LIBRARY_PATH. --- run.in | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/run.in b/run.in index a8c2904..bf7ea1b 100755 --- a/run.in +++ b/run.in @@ -77,13 +77,10 @@ fi

This simply compiles, passes tests, but is only able open a handle. This commit does not contain the full bindings. --- Makefile.am | 2 + configure.ac | 32 +++++ generator/GoLang.ml | 116 ++++++++++++++++++ generator/GoLang.mli | 19 +++ generator/Makefile.am

This simply compiles, passes tests, but is only able open a handle. This commit does not contain the full bindings. --- Makefile.am | 2 + configure.ac | 32 ++++ generator/GoLang.ml | 150 ++++++++++++++++++ generator/GoLang.mli | 19 +++ generator/Makefile.am

In Mac OS X native version: The R shell wrapper (bin/R) overrides default library search path with DYLD_LIBRARY_PATH and adds (among others) /usr/X11R6/lib. This causes problems when modules need (directly or indirectly) libraries from Apple's frameworks which are masked by X11. Examples for such packages are SJava and RGL. SJava needs JavaVM which in turn loads OpenGL framework. RGL

On 12 February 2015 at 18:42, Pino Toscano <ptoscano@redhat.com> wrote: [...] > We link to libcrypt because it provides crypt(), at least on GNU libc > and on the FreeBSD libc; it seems not the case on Mac OS X, looking > at your patch. > I'd say that this should turn into a proper configure check, trying to > use crypt() without extra libraries and if not possible with

* Replace LD_LIBRARY_PATH with DYLD_LIBRARY_PATH for Darwin * Remove the -lcrypt flag for Darwin (unsupported) --- configure.ac | 13 +++++++++++++ run.in | 10 +++++----- v2v/link.sh.in | 2 +- 3 files changed, 19 insertions(+), 6 deletions(-) diff --git a/configure.ac b/configure.ac index d68190a..295de11 100644 --- a/configure.ac +++ b/configure.ac @@ -582,6 +582,19 @@ fi

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

I''m trying to build the ruby-oci8 with the Oracle Instant Client on OS X. The Instant Client works, and the make seems to be ok with it up until OCIInitialize(). Anybody got this to work? [relevant output] /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby / Users/dmholmes/Desktop/ruby-oci8-1.0.0-rc2/ext/oci8/extconf.rb checking for load library path...

Well... this may be a red herring after all, but it's an interesting one! It turns out I have got DYLD_LIBRARY_PATH set. This gets exported to R (or rather, affects the loader that loads the R process?), and somehow mixes up the way symbols are exported. Something that applies to launching R from the command line (/usr/bin/R) AND via LaunchServices (open -a R). Once I noticed that invoking

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

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 than the default

Currently 'make install' installs the virt-p2v binary in /usr/libexec/virt-p2v on the host. It is never supposed to be run from there, even by another program, so use of /usr/libexec is incorrect. It is only supposed to be copied into USB keys / ISOs / etc created by virt-p2v-make-* scripts. The other problem with shipping a "naked" binary on the host is that packages built

Hi there! I am currently trying to compile hacks.git under OS X and I can't seem to get past the following error during 'make': Code: [...] gcc -o wineserver async.o atom.o change.o class.o clipboard.o completion.o console.o context_alpha.o context_i386.o context_powerpc.o context_sparc.o context_x86_64.o cursoricon.o debugger.o device.o directory.o event.o fd.o file.o handle.o

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

The test in question is clang-check-mac-libcxx-fixed-compilation-db.cpp which copies clang-check to a local directory to make sure clang can find libcxx via rpath. However, when built with shared libs, the copy of clang-check can't find any of it's libraries, so I'd like to either turn if off when BUILD_SHARED_LIBS=ON, or find a way to fix it. Thought about trying to use

From the RAqua faq just uploaded to CRAN (so it will take until tomorrow to appear) Panther notes After installing Panther (MacOSX 10.3) it turns out that package installation (either from sources or from binaries) can fail. If you get an error "like" this (this comes from source package installation) dyld: gcc version mismatch for library: /usr/local/lib/libiconv.2.dylib

Hi, It seems like a number of people on this list can install rgl but have problem loading it. I found myself in the same situation too. I have tried the workaround of removing /usr/X11R6/lib from DYLD_LIBRARY_PATH, but it doesn't seem to work for me, I am still getting the same error (that everyone else seems to get). Can anyone give me some ideas on what else to try? I have Mac OS 10.3.5,

James McKenzie wrote: > doh123 wrote: > > > I'm not sure LD_LIBRARY_PATH actually does anything on OSX... > > > > there are a lot of related things you can do though... just look at 'man dyld' > > > > > > > Doh123: > > Yes it does. Look it up for FreeBSD. > > Without it, the only directories that will be examined for