Problem reported by a downstream Cygwin user inadvertently
misconfiguring a package cross-build with mingw toolchain:
libtool with mingw hangs building openocd in
func_convert_core_msys_to_w32:
https://cygwin.com/pipermail/cygwin/2021-June/248791.html
The issue exists in libtool build
On Fri, 25 Jun 2021, Dietmar May wrote:
Is this a holdover from 13 year old mingw behavior? or related somehow
to running autotools in a cmd.exe environment (like Microsoft's original
NT "posix" subsystem, a port of gnu commands to run "natively" under
cmd.exe)?
Libto
_result=$1
}
SUMMARY
func_convert_core_msys_to_w32 in
/usr/share/libtool/build-aux/ltmain.sh
has an extraneous '/' in the call to
( cmd //c echo "$1" )
causing make to hang indefinitely
when configured with
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
The project builds successfu
SUMMARY
func_convert_core_msys_to_w32 in
/usr/share/libtool/build-aux/ltmain.sh
has an extraneous '/' in the call to
( cmd //c echo "$1" )
causing make to hang indefinitely
when configured with
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
The project builds successfull
Severity: minor
Hi Ludo,
Ludovic Courtès schreef op do 29-04-2021 om 13:52 [+0200]:
> [...]
> The ‘libtool’ script provided by the ‘libtool’ package is usually
> unused. The modus operandi for Libtool is that packages generate their
> own ‘libtool’ script at configure ti
Hi Maxime,
Maxime Devos skribis:
> $ cat $(guix build libtool)/bin/libtool
> Some relevant output:
[...]
> However, during linking, (at least during the compilation of libtomsmath
> IIRC),
> libtool uses LTCC instead. Thus, when a package X has libtool in
> native-inp
Hi,
[CC'ing to libtool mailing list, maybe they can shed some light on the matter
of how libtool can be used as a cross-compiler. This concerns the definition
of the libtool package in guix.]
$ cat $(guix build libtool)/bin/libtool
Some relevant output:
> # A C compiler.
> LTC
Thank you :)
Le lundi 05 avril 2021 à 04:33 -0400, Mike Frysinger a écrit :
> On 05 Apr 2021 09:35, Benoit Gschwind wrote:
> > Thank you for the highlight.
> >
> > Is .incbin considedred as preprocessor instruction ?
>
> if you're using assembler directives like .incbin, that isn't
>
On 05 Apr 2021 09:35, Benoit Gschwind wrote:
> Thank you for the highlight.
>
> Is .incbin considedred as preprocessor instruction ?
if you're using assembler directives like .incbin, that isn't preprocessing,
so .s is OK. usually when people say -I from CFLAGS/CXXFLAGS, they want the
a project that include assembler file ".s".
> >
> > Libtool seems to work with them and call gcc as follow:
> >
> > /bin/sh ../libtool --mode=compile gcc -Og -ggdb -march=native -
> > c -o
> > myfile.lo ../../src/myfile.s
> >
> > But it does no
On 02 Apr 2021 12:54, Benoit Gschwind wrote:
> I trying to build a project that include assembler file ".s".
>
> Libtool seems to work with them and call gcc as follow:
>
> /bin/sh ../libtool--mode=compile gcc -Og -ggdb -march=native -c -o
> myfile.lo ../../s
Hello,
After inspecting the generated Makefile I found out the AM_CCASFLAGS
that work for me :)
Best regards
Le vendredi 02 avril 2021 à 12:54 +0200, Benoit Gschwind a écrit :
> Hello,
>
> I trying to build a project that include assembler file ".s".
>
> Libtoo
Hello,
I trying to build a project that include assembler file ".s".
Libtool seems to work with them and call gcc as follow:
/bin/sh ../libtool--mode=compile gcc -Og -ggdb -march=native -c -o
myfile.lo ../../src/myfile.s
But it does not inherit the AM_CXXFLAGS nor AM_CFLAGS
Hi ,
The patch pasted below is VxWorks patches for libtool. Anyone can help to
review and merge it? Thanks.
>From 8976b51c86491aa283ba8b5691d82e6b1b2cef57 Mon Sep 17 00:00:00 2001
From: Peixing Xin mailto:peixing@windriver.com>>
Date: Tue, 19 Jan 2021 17:56:00 +0800
Subjec
URL:
<https://savannah.gnu.org/patch/?9996>
Summary: Patch libtool for macOS 11.0 (aka darwin20)
Project: GNU Libtool
Submitted by: fxcoudert
Submitted on: Mon 16 Nov 2020 03:22:20 PM UTC
Category
On OS/2, a path separator is ';' not ':'. So use $PATH_SEPARATOR.
* build-aux/ltmain.in (func_exec_program) [shlibpath_var]:
Replace ':' with $PATH_SEPARATOR.
(func_mode_link) [shlib_search_path]: Likewise.
* m4/libtool.m4 (func_munge_path_list): Likewise.
---
build-aux/ltmain.in | 4 ++--
This fixes clang cross-compilations targeting darwin where if we don't
pass compiler_flags to clang, it assumes it's compiling for the host and
will fail to link with a "file format not recognized" error.
* m4/libtool.m4 (_LT_DARWIN_LINKER_FEATURES): Pass compiler_flags to
partial linking
Even though it runs on Windows, Cygwin uses UNIX paths.
The _WIN32 macro may still be defined when using Win32 APIs
however.
Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
build-aux/ltmain.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/build-aux/ltmain.in
On 3/9/20 9:01 PM, Simon Marchi wrote:
>> Hello libtool folks,
>> Any ideas about this? Something confused the file magic command?
>> dlltool --identify does show libdl.a is associated with cygwin1.dll for
>> example.
>
> Hi,
>
> I stumbled on this and d
On 3/1/20 11:00 AM, Marco Atzeri wrote:
>>
>> Last file checked: /lib/libpthread.a
>>
>> Is that correct? Do you have the complete command line? Is this
>> happening on both archs or just i686?
>>
>
> both archs.
> The error is likely coming from libt
.
What does this issue have to do with libtool?
I have not had any problems when compiling GraphicsMagick under msys2
and GraphicsMagick is also using libtool and using the Windows
spawnvp() function.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen
Hi, i encountered 2 similar errors in an attempt to build check-0.14.0
and popt-1.16 on latest msys2.
...
./.libs/lt-ex_output.c: In function 'main':
./.libs/lt-ex_output.c:319:16: warning: implicit declaration of function
'_spawnv'; did you mean 'spawnv'? [-Wimplicit-function-declaration]
319
The Free Software Foundation has changed the GNU Mailman settings on
this list. The short version is that any subject prefix or message
footer has been removed, allowing us to turn off DMARC from munging.
Any list administrator for this list is free to change these settings
back, instructions are
With 64bit MSVC cl.exe, and since VS 2012 even with 32bit, binary files
may contain (C)ommon symbols. Their name likely is not valid to be used
as symbol name in the C programming language, and should be ignored in
the global symbol pipe. This does fix test cases 27-29, 31-37 and 109.
*
Using '_nm__' to match symbols from GNU ld to enable special data import
treatment on windows targets does rely on the leading underscore being
stripped from the __nm_ prefix rather than the subsequent symbol name.
This does fail on 64bit Windows targets, because there is no leading
underscore
/listinfo/libtool
uri wrote:
> On 2019-06-24 09:55, Roumen Petrov wrote:
>>
>> And projects builds just fine!
>> Conclusion - there is no defect neither in libtool nor in automake nor
>> in project autotool files.
>>
>> Reporter still does not provide feedback with informatio
On 6/23/19 2:56 PM, Yuri wrote:
On FreeBSD libtool can't find operator new[] because it is in C mode:
libtool: link: cc -fno-strict-aliasing -fopenmp -ftree-vectorize
-pthread -O2 -pipe -fno-omit-frame-pointer -fstack-protector-strong
-fno-strict-aliasing -fno-strict-aliasing -fstack
ttp://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
___
https://lists.gnu.org/mailman/listinfo/libtool
On 2019-06-24 09:55, Roumen Petrov wrote:
And projects builds just fine!
Conclusion - there is no defect neither in libtool nor in automake nor
in project autotool files.
Reporter still does not provide feedback with information from
configuration time (requested in a previous post
++ code:
CXX alice
CXXLD bob
And projects builds just fine!
Conclusion - there is no defect neither in libtool nor in automake nor
in project autotool files.
Reporter still does not provide feedback with information from
configuration time (requested in a previous post) => resolution is -
bro
, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
___
https://lists.gnu.org/mailman/listinfo/libtool
On 2019-06-23 17:29, Bob Friesenhahn wrote:
I doubt that libtool can be smart enough to intuit when the C++
compiler needs to be used for linking when the program being linked is
C. The only way it could tell this is via library dependencies. Just
supplying the library dependencies
On Sun, 23 Jun 2019, Yuri wrote:
Those variables could be used to tune build process.
For instance CXX=my-c++ ./configure ... could be used to change C++
compiler.
It seems to know that c++ is the C++ compiler, but then uses cc anyway:
I doubt that libtool can be smart enough to intuit
/listinfo/libtool
could be used to tune build process.
For instance CXX=my-c++ ./configure ... could be used to change C++
compiler.
Roumen
___
https://lists.gnu.org/mailman/listinfo/libtool
/mailman/listinfo/libtool
Yuri wrote:
On FreeBSD libtool can't find operator new[] because it is in C mode:
libtool: link: cc -fno-strict-aliasing -fopenmp -ftree-vectorize
-pthread -O2 -pipe -fno-omit-frame-pointer -fstack-protector-strong
-fno-strict-aliasing -fno-strict-aliasing -fstack-protector-strong -o
://lists.gnu.org/mailman/listinfo/libtool
On Sun, 23 Jun 2019, Yuri wrote:
On FreeBSD libtool can't find operator new[] because it is in C mode:
How to switch libtool to the C++ mode?
Are you using expected file extensions for C++ code? Is your main
program a C++ module or a C module?
Bob
--
Bob Friesenhahn
bfrie
On FreeBSD libtool can't find operator new[] because it is in C mode:
libtool: link: cc -fno-strict-aliasing -fopenmp -ftree-vectorize
-pthread -O2 -pipe -fno-omit-frame-pointer -fstack-protector-strong
-fno-strict-aliasing -fno-strict-aliasing -fstack-protector-strong -o
RNALfold
On 5/23/19 3:04 PM, Thomas Jahns wrote:
some MPI's its --shome:link and for others -link_info, you could then
I meant --showme:link, of course.
Thomas
___
https://lists.gnu.org/mailman/listinfo/libtool
___
https://lists.gnu.org/mailman/listinfo/libtool
this, and this
library is built with missing MPI library linkage, and therefore with
dangling symbols.
The conversation: https://github.com/FFTW/fftw3/issues/169
Thank you,
Yuri
___
https://lists.gnu.org/mailman/listinfo/libtool
On 2019-05-12 16:12:47 +0200, Bruno Haible wrote:
> Bumping the libtool version of a shared library according to
> <https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html>
> seems to be harder than expected: Both the gettext-0.19.8 and gettext-0.20
> r
Bumping the libtool version of a shared library according to
<https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html>
seems to be harder than expected: Both the gettext-0.19.8 and gettext-0.20
release suffer from a wrongly computed triple (mistakes done by dif
Resolves bug 17750.
* build-aux/ltmain.in (func_mode_link): In the flags to be passed through
unchanged, also pass -static-* and -fcilkplus.
Signed-off-by: Vincent Lefevre
---
build-aux/ltmain.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/build-aux/ltmain.in
GS and tests for PIC flags -*- Autotest
-*-
+
+# Copyright (C) 2019 Free Software Foundation, Inc.
+#
+# This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free
On Thu, 14 Mar 2019, reshmi ravindranathan wrote:
1. Please advice if there are any specific licenses for commercial
applications. Please share if any.
2. Is it possible to get some community edition of libtool
Please read the license at the top of ltmain.sh. It includes:
# As a special
On 3/14/19 11:11 AM, reshmi ravindranathan wrote:
> Dear Team,
>
> I would like to understand the usage of libtool in commercial applications
> from a license perspective. We are planning to use libtool for one of our
> application for commercial purpose. We will be using the l
Dear Team,
I would like to understand the usage of libtool in commercial applications
from a license perspective. We are planning to use libtool for one of our
application for commercial purpose. We will be using the libtool directly
without doing any modification. We have been searching
Hi Paul,
Paul "LeoNerd" Evans wrote:
[SNIP]
Alternatively, am I looking at this from the wrong direction? Maybe the
problem is that the exporting library isn't providing -Wl,-rpath in
its .pc file, to assist anyone else who wasn't using libtool to link it
(such as is the case here
It does feel
> rather fragile however, as I'm second-guessing around what libtool
> would do.
Alternatively, am I looking at this from the wrong direction? Maybe the
problem is that the exporting library isn't providing -Wl,-rpath in
its .pc file, to assist anyone else who wasn't using libt
On Thu, 7 Feb 2019 15:20:32 +0100
Thomas Jahns wrote:
> Have you tried setting something like
>
> CC='libtool cc'
> CFLAGS='--mode=compile -some -other -flags -youd -use'
> LDFLAGS='--mode=link -some -further -link -flags'
I've been looking at that, and it doesn't seem to
Hello Paul,
On 2/6/19 2:21 PM, Paul "LeoNerd" Evans wrote:
Nowthen - my actual question concerns what happens when I am not using
libtool to build my program. Such a case is common when building
C-level integration libraries for dynamic languages (Perl in my case).
I can't g
Hi all,
A *slightly* offtopic question here but I'm hoping someone will be able
to offer some assistance.
First off, the all-libtool case for comparison. If I install some
libtool-based library, it drops some files in (for example)
$HOME/lib - these files primarily are the libfoo.so* collection
> On Jan 8, 2019, at 3:48 PM, Gary V. Vaughan wrote:
>
> Hi Christopher,
Sorry Christoph - autocorrect fail :-(
> My current employer does not sign FSF disclaimers, so I have not been able to
> work on libtool for the last 4 years. I’m Cc:ing the libtool list where yo
Hi Christopher,
My current employer does not sign FSF disclaimers, so I have not been able to
work on libtool for the last 4 years. I’m Cc:ing the libtool list where you
might find someone who can help.
However, the intent of the exceptions is to allow you to build your software
using
Hi all,
Arch Linux wants to have a reproducible libtool packages as part of an
effort to make the whole distribution reproducible. [1] Debian carries a
custom patch, which removes the offending non-reproducible part
(hostname). My request is that the patch of Debian would be applied in
libtool
://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/libtool/patches/?only_with_tag=MAIN
Regards,
Sevan Janiyan
From 31fbdcb94c0af7c3554dc94e836409d48d0d7d7e Mon Sep 17 00:00:00 2001
From: Sevan Janiyan
Date: Wed, 14 Nov 2018 00:03:31 +
Subject: [PATCH] Add support for Minix. Configuration clones
On Tue, Aug 14, 2018 at 1:54 AM Matthias Klose wrote:
>
> > $ sudo apt install libtool-devel
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > E: Unable to locate package libtool-devel
> > $ type lib
> $ sudo apt install libtool-devel
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to locate package libtool-devel
> $ type libtool
> bash: type: libtool: not found
-devel package names are usually found on
Hi Bruce,
Bruce Korb wrote:
$ ./configure
.
checking for libltdl... no
configure: error: GNU libltdl (Libtool) not found, see README.
This error is for "libtool dynamic loader library" ltdl. Perhaps you
system distribute separate libtool and libltdl packages.
$ type li
Bruce Korb writes:
$ ./configure
.
checking for libltdl... no
configure: error: GNU libltdl (Libtool) not found, see README.
$ type libtool
bash: type: libtool: not found
$ sudo apt install libtool
Reading package lists... Done
Building dependency tree
Reading state information
gt; $ ./configure
> > .
> > checking for libltdl... no
> > configure: error: GNU libltdl (Libtool) not found, see README.
> > $ type libtool
> > bash: type: libtool: not found
> > $ sudo apt install libtool
> > Reading package lists... Done
> &
$ ./configure
.
checking for libltdl... no
configure: error: GNU libltdl (Libtool) not found, see README.
$ type libtool
bash: type: libtool: not found
$ sudo apt install libtool
Reading package lists... Done
Building dependency tree
Reading state information... Done
libtool is already
On Tue, 17 Jul 2018, Eric Bavier wrote:
Hello Libtoolers,
I noticed that at least the last two distributions of libtool (2.4.5 and 2.4.6) contain
"._*" files in the tarballs. AFAICT these are from OS X's tar, which "uses
AppleDouble files to store extended attributes and ACLs
Hello Libtoolers,
I noticed that at least the last two distributions of libtool (2.4.5 and 2.4.6)
contain "._*" files in the tarballs. AFAICT these are from OS X's tar, which
"uses AppleDouble files to store extended attributes and ACLs'.
These files are only meaningful on
In regard to: Re: What happened to libtool transitive DSOs?, Bob...:
On Thu, 21 Jun 2018, John Calcote wrote:
Hi Bob. It's an ubuntu distro release - Linux Mint 18. Why would they do
that?
GNU Linux and the GNU linker support implicit library dependencies.
Sorry to jump
Magick.org/___
https://lists.gnu.org/mailman/listinfo/libtool
n/listinfo/libtool
: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool
On 2018-06-27 09:44, Roumen Petrov wrote:
Hello Alice,
Alice Wonder wrote:
Hello,
[SNIP]
Software (audacity)
[SNIP]
libtool: link: unable to infer tagged configuration
libtool: link: specify a tag with `--tag'
[SNIP]
LIBTOOL=/opt/gnu/bin/libtool
libtool is generated script
I think the problem must be with audacity.
I tried building several other packages with the new gcc, including orc
from the GStreamer project that requires libtool to build and I made
sure (in mock buildroot) that only the /opt/gnu/bin/libtool I built was
available - and they compiled, passed
You are somehow mixing parts of libtool from different versions. --tag has
been required since version 1.5, so some part of what you've built uses
something even older, circa 2002. First, try re-generating the configury
for this project using newish tools. 'autoreconf" might do it. Yo
warn_unused_result
[-Wunused-result]
chdir(folder);
^
/bin/sh ./libtool--mode=link g++-L/opt/gnu/lib64 -L/lib64
-L/usr/lib64 -o libFileDialog.la -rpath /usr/lib64
libFileDialog_la-FileDialog.lo gtk/libFileDialog_la-FileDialogPrivate.lo
-lgtk-3 -lgdk-3
but it is very useful to OS distributions which want to update
libraries (or groups of libraries) via a package manager without
needing to update dependent applications or libraries.
The normal libtool operation is to record all of the involved
libraries as dependencies since they are all added to the link
On Thu, 21 Jun 2018, Paul T. Bauman wrote:
This is correct and bit us as well when Debian-based systems changed this.
Our very hackish work around was to insert the following in our configure.ac
immediately after AC_OUTPUT():
perl -pi -e 's/link_all_deplibs=no/link_all_deplibs=yes/' libtool
Hi Bob. It's an ubuntu distro release - Linux Mint 18. Why would they do
that?
On Thu, Jun 21, 2018, 9:56 AM Bob Friesenhahn
wrote:
> On Thu, 21 Jun 2018, John Calcote wrote:
> >
> > After upgrading to libtool 2.4.2, I find that I now have to specify the
> > additiona
On Thu, Jun 21, 2018 at 11:56 AM Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
> On Thu, 21 Jun 2018, John Calcote wrote:
> >
> > After upgrading to libtool 2.4.2, I find that I now have to specify the
> > additional secondary .la files that are list
On Thu, 21 Jun 2018, John Calcote wrote:
After upgrading to libtool 2.4.2, I find that I now have to specify the
additional secondary .la files that are listed in the primary .la files'
dependency_libs property, or I get a link error indicating missing DSOs on
the command line (and I can see
One of the coolest features (I thought) of libtool was it's ability to
allow specification of only the .la files directly required by a library or
program when linking.
I had code that used libtool 2.2 a while back that worked fine this way. A
program P required library A.la, which itself
Looks like your system is missing ‘sed’? and maybe ‘echo’. Could you check the
lines mentioned and see which utilities libtool is trying to invoke?
Eric Bavier, Scientific Libraries, Cray Inc.
From: Libtool [mailto:libtool-bounces+bavier=cray@gnu.org] On Behalf Of
irshadahmed desai
Sent
Hi,
I am working on 32 to 64 bit migration/porting of code. i was facing below
libtool errors. could you please help me out is there any thing i need to
upgrade 64 bit tool chain specific libtool to resolve below errors. i did
not faced any errors while compiling with 32 bit.
../libtool: line
Hi.
Can somebody explain what -no-fast-install does?
On 26.03.2018 20:48, Basin Ilya wrote:
> Ok, can libtool create both binaries at build stage, the debug one instead of
> the wrapper script and the installable one in .libs/program?
>
> 26.03.2018 20:46, Simon Richter
nu.org/mailman/listinfo/libtool
I seek a mode in which libtool would use no wrapper scripts and do the
following:
- `make all` would create a binary with the debug rpath, just like the
`-no-install` option does
- `make install` would install a binary without the debug rpath, just like
without options at all.
The expected
that depend on the changes I have made
in library A.
These tests for B are using libtool wrapper scripts, so that they can
run against the uninstalled changes of the library they belong to.
However, the wrapper scripts forcefully insert my system path to
LD_LIBRARY_PATH before my own LD_LIBRARY_PATH, which
Hi,
I would like create my executable using libtool by linking non-libtool
object files along with libtool generated object files. I see that there is
an option "-objectlist file".
The non-libtool object files (.o files) are outside of my project. I don't
want to compile them inst
Hi,
I would like create my executable using libtool by linking non-libtool
object files along with libtool generated object files. I see that there is
an option "-objectlist file".
The non-libtool object files (.o files) are outside of my project. I don't
want to compile them inst
Hello!
I would like to know, how the .la files are used in libtool.
What I would like to do is replace the libdir line using an environment
variable, because I'm working on a diverse double compilation project, and
having the absolute path of the installation directory encoded is not
convenient
There is also a similar problem when using clang's compiler-rt for
builtins. In that case, the internal library is
/usr/lib64/clang/5.0.0/lib/linux/libclang_rt.builtins-x86_64.a.
Mesa graphics library links some libraries with -nostdlib option and relies
on libtool to supply the internal
/clang/5.0.0/lib/linux/libclang_rt.asan-x86_64.a
Looking at the source code at
http://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4#n7556 ,
libtool does not handle use of static libraries.
dnl Parse the compiler output and extract the necessary
dnl objects, libraries and library flags
are invariant
> relative to the binary can still work.
This is not the case in general: libraries are installed by the user
in $HOME/lib, but binaries can be anywhere under the $HOME directory.
> > > will do just what's needed (for most people on this list libtool
> > > does so for them).
&
X's behavior, unless managed very carefully, can create
serious security holes by looking in those directories for libraries by
default. This is the reason for the libtool relink after install step,
which isn't necessary on Linux but is vital on platforms that have
AIX-like behavior (and has various issue
at the
same time, e.g. for parallel computing on a network of machines.
I don't know of any site with such a setup, seems like to little thought went
into planning somewhere.
will do just what's needed (for most people on this list libtool
does so for them).
libtool is used to compile libraries
On 2017-06-01 08:30:43 -0500, Bob Friesenhahn wrote:
> This requires that libtool re-link upon installation if the temporary rpaths
> are not wanted. If the temporary rpaths are left in place, then
> reliability, performance, and security issues are left baked into the
&
iven when the library is on NFS, where
the mount point (e.g. $HOME directory) depends on the machine?
Note that it is important that several machines can be used at the
same time, e.g. for parallel computing on a network of machines.
> will do just what's needed (for most people on this list li
On 05/31/2017 01:15 PM, Vincent Lefevre wrote:
On 2017-05-31 11:58:05 +0200, Thomas Jahns wrote:
On 05/30/2017 06:30 PM, Vincent Lefevre wrote:
On 2017-05-30 17:39:14 +0200, Thomas Jahns wrote:
I repeat: don't set LD_LIBRARY_PATH, that's the real problem, libtool not
working for you is just
On 2017-05-31 11:58:05 +0200, Thomas Jahns wrote:
> On 05/30/2017 06:30 PM, Vincent Lefevre wrote:
> > On 2017-05-30 17:39:14 +0200, Thomas Jahns wrote:
> > > I repeat: don't set LD_LIBRARY_PATH, that's the real problem, libtool not
> > > working for you is just a sympto
201 - 300 of 5838 matches
Mail list logo
