libraries depend on -lm and if shared libraries depending on -lm are
linked with, then a linkage dependency with -lm is implicitly added,
hiding the underlying issue.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer
On Wed, 31 Jan 2024, Bob Friesenhahn wrote:
bin/bash ./libtool --tag=CXX --mode=link g++-10 -no-undefined
-export-symbols-regex ".*" -version-info 27:4:24 -L/usr/local/lib
-Wl,-rpath,/usr/local/lib -o magick/libGraphicsMagick.la -rpath
/usr/local/lib [ list of .lo files ]
L/usr/local/lib
-Wl,-rpath,/usr/local/lib -o magick/libGraphicsMagick.la -rpath
/usr/local/lib [ list of .lo files ] -lm
An I misunderstanding something, or is this a bug in libtool? What am
I missing in order for this to work?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://w
and there is no
reasonable means available to verify that the support still works.
Support which is not periodically tested likely does not work any
more.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
On Thu, 23 Nov 2023, Antonin Décimo wrote:
As a side question: is libtool still maintained?
I also note that the latest version isn't reported on the webpage
(2.4.7 instead of 2.4.6).
Which web page (e.g. URL, documentation file in libtool git) are you
talking about?
Bob
--
Bob Friesenhahn
all of the autotool stuff.
Maybe this will make a difference.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
d
already be working with the original FSF libtool.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
loader path.
Likewise, it is pointless to install a library which will never be
used.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users
pt and provided to the libtool command line, even
while it optimizes other unneeded options away.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
over built-in
optimizations in libtool.
As a user, I strongly suggest that libtool honor user-supplied options
to the configure script and provided to the libtool command line, even
while it optimizes other unneeded options away.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, htt
this as an indication that the GNU Libtool
is back under active development? If so, is there a roadmap and/or set of
timeframes for future GNU Libtool work?
From the above, it sounds like you are interested in being a libtool developer.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
software
that they can easily use.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
is exceedingly helpful when it is desired to be able to
support static builds and it also helps for compiling shared libraries
(DLLs) under Microsoft Windows.
So it is worth considering using dlopen() directly.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users
.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
and its
test suite works without installing the software. It does not use
libltdl's static-module "preloaded" feature.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
libtool behavior regarding explicit
dependencies (via ".la" files) whereas leveraging implicit
dependencies are usually prefered by distribution maintainers.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintaine
it assures that the objects were compiled
properly to be used in the library they are linked into.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems
collide with these patches so they can not be easily
applied.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
an official libtool
maintainer would help move the project forward and make it easier to
integrate your own ideas.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http
compiler's library
installation, then the system will search the normal places for the
libraries unless you add an -rpath option to the build.
Of course if ldconfig is aware of your compiler's library installation
then that causes problems if you are using multiple compilers.
Bob
--
Bob
s run-time libraries are installed under
/usr/lib/x86_64-linux-gnu (e.g.
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1).
The wrapper scripts are used for running programs in the build tree.
They are not meant to be installed.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.sim
,
while static is just LIB. VC links with LIB regardless.
That makes sense. The key issue is if the consumer of the header file
wants/needs to have dllimport/dllexport enabled.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick
the distinct impression that static libraries are rarely used
under Windows any more.
While useful for debugging, a lot of projects just don't produce them
any more.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
it is possible/likely that both static and DLL
are available at the same time and compiler will choose one of them
according to its own rules, and especially if libtool is not used for
linking against that library.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users
fortunately, existing libraries may have implicit dependencies baked
into them which will not go away without rebuilding them.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key
on this
library, then it would fail to link, or fail to run if the library can
not be found.
The compilation toolchain you are using is set up to not put its
libraries in the default system directories. As a result, the
libstc++.so.6 file needs to be found somehow.
Bob
--
Bob Friesenhahn
bfrie
full linkage that it does. A common work-around is to
remove the ".la" files that libtool produces and installs.
It is possible that GCC itself is pre-programmed (e.g. via the spec
file) to record this information when it links with the C++ standard
library.
Bob
--
Bob Friesenhahn
bfrie
ows programs without any "POSIXization".
Cygwin is a Unix emulation environment so it uses Unix-style paths.
In the past, MinGW users often used MSYS.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://
On Fri, 25 Sep 2020, Oleg Smolsky wrote:
On 2020-09-25 09:28, Bob Friesenhahn wrote:
With convenience libraries, there may be a necessary build order but the
object files are not 'linked' before going into the convenience libraries
(as a proper library would be) so all linking is when
reating a proper non-recursive build takes work.
For me, it has been completely worth it. GraphicsMagick is perhaps
not the best example for how to do things since Automake has improved
its capabilities since I made GraphicsMagick's build non-recursive.
Bob
--
Bob Friesenhahn
bfrie...@simpl
for use in shared libraries or DLLs. Quite often
objects need to be built in special ways (e.g -fPIC,
dllexport/dllimport declarations) in order to work in shared
libraries.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick
y, then the dependent
program won't run.
You should confirm if the libtool you are using is as delivered from
the FSF release, or if it is a modified version. Modified versions
which change how library dependencies are treated abound.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
.
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
) but I have not seen a
speed benefit to properly written code.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
ions often patch out this capability, and they don't
distribute ".la" files.
Unfortunately, --as-needed may not be 100% reliable since it only
reliably detects direct dependence on library symbols, and not
"transitive" dependence.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.t
On Sat, 4 Jan 2020, Russ Allbery wrote:
wf...@niif.hu writes:
Bob Friesenhahn writes:
That sounds like a great idea. However, there is a problem that
linking on some systems does depend on already installed libraries (or
will end up using them) and so the libraries need to be installed
in a particular order.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
continued to be developed,
but has not been released.
Autoconf 2012
libtool 2014
Automake 2017
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org
would defeat the purpose of being a portability tool.
Sometimes it is better to force the using software to conform to the
limitations.
Libtool must also work for static linking. It seems to me that your
issue also impacts static linking.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us
certainly miss most of the
picture, so I sincerely appreciate your "piping up". Let's hope others
will join with time with their insights.
As far as I am aware, libtool is currently "between maintainers" and
needs fresh volunteers to become a libtool maintainer.
Bob
--
B
m the only person on this list who
has piped up with some sort of a response. :-(
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfrie
roblem you are seeing.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
libraries will be automatically selected by the compiler.
On a typical GNU Linux or FreeBSD system, all C++ software is built
using the same C++ runtime libraries (at some specified C++ standard
level). This is accomplished through brute force by the OS package
maintainers.
Bob
--
Bob
ble as time goes by.
C++ supports exceptions and C does not. If the run-time used does not
provide an exception handling framework then there will be a core dump
either when the C++ exception is initially thrown, or at the boundary
of C/C++.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, h
not be thrown into C code unless
a special compiler option is used so that C supports the exception
framework. Without this you are likely to get a core dump.
C++ is very good at using C code but C code is not very good at
using C++ code.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us
++ compiler so that the
correct standard level and libraries are used.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public
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
s much faster on modern systems.
If your project is already fully built, then typing 'make' again
should return almost immediately without doing any work at all. If
your project does any work at all due to typing 'make' a second time,
then it is defective.
Bob
--
Bob Friesenhahn
bfrie...
continually, and it is not
reasonable to support them all.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
it as part of a "proprietary"
application. There are usage models where this is not true.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simples
that there are useful instructions in the libtool source
repository.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman
so that patches contributed by volunteers
and accepted in the repository already get a more widespread distribution.
Volunteers with the necessary energy, time, and resources are
necessary in order to perform this function.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman/listinfo/libtool
'.
These files are only meaningful on OS X, and don't seem like they should be
distributed. Probably not a huge deal, just thought I'd point it out.
This is a known issue and it is unlikely to happen again.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org
e possible to match on that
final literal underscore. This might expose differences in behaviors
between egreps.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.Graphics
line.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman/listinfo/libtool
with. The reason why they do not like this is that if they
introduce a different library which has different dependencies then
they would like the dependencies to be entirely determined by the new
library.
This is a very long-standing point of contention.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us
that libtool is not adding the transitive
dependencies like it used to. Why was this change made?
Are you using libtool 2.4.2 as distributed by the FSF or are you using
a modified libtool distributed by an OS vendor? Some OS vendors
modify libtool like this on purpose.
Bob
--
Bob Friesenhahn
option.
The setting might need to be remembered in the installed .la files in
order to know if libraries this library depends on are also prepared
for the feature, and for libraries that depend on this library can
know that they can use the feature.
Bob
--
Bob Friesenhahn
bfrie
you from doing what you want in your
configure script by adding to CFLAGS and/or LDFLAGS variables. Just
make sure that enabling or depending on this feature does hinder
portability to systems which do not support the feature.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
me locate the place where I could modify the escaping?
Are you saying that your system includes colons in its
filesystem paths? That would definitely be problematic.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer
default values for most variables set or used by configure and
may be used to remember any settings found in the generated
config.status script.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
ll usually select bash on Solaris
sytems. The selected shell is set in the CONFIG_SHELL environment
variable and the user is able to over-ride this.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.Graphics
t configure-time.
Regardless of what happens with libtool in the long term, the
situation for LLVM's LLD will be much better if it pretends to be GNU
ld since it takes years to deploy a new libtool release across OS
distributions. Clang pretends to be GCC in many ways.
Bob
--
Bob F
is not determining that the path
is a system library path.
Check the output of './libtool --config'. Particularly,
sys_lib_dlsearch_path_spec. Maybe it is wrong.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
of issues under Microsoft Windows, which does
not seem to offer sufficient control of where files come from.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
On Mon, 27 Jun 2016, Bob Friesenhahn wrote:
The good news is that libtool will already automatically link dependency
libraries when you build something which depends on 'A' and the .la file for
'A' is present. In other words, libtool should handle the problem
automatically as long as you
nk using
something other than libtool. This is a core function of libtool.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists
to ignore it when the module is built (as it does) and then
the application using the module would need to link with -lgcc.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
in the link line may be a bug (possibly a bug in GCC).
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman/listinfo/libtool
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman/listinfo/libtool
libtool?
I would guess that it does not know what to do based on your host
specification. Perhaps 'androideabi' vs 'gnu' throws it off.
Does Android use the same shared library conventions as GNU/Linux?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users
code
that Ubuntu offers. Ubuntu is obligated to provide you with the
source code since this is a GPL-licensed package. If they have not
made it clear to you how to obtain the source code, then there is a
problem.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/
udes people who
just received a tarball and are not the developer of the software.
Another core principle is that defaulting to imperfect success is
better than utter failure.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Main
on any OS) in its makefiles for as long as I can
remember.
No harm was encountered due to this.
This discussion is feeling rather Shakespearian.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.Graphics
ether static will be created and whether
shared will be created. So "make" must ether create requested versions
or fail.
These are 'enable' options. Use of 'enable' implies "best effort".
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesy
ply any additional dependency
libraries if there otherwise would be undefined symbols.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
__
modify libtool such that
dependency libraries are not included and they delete all .la files.
The reason for intentionally losing dependency information is because
the specific dependencies cause packaging problems.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org
. It is thought that errors are bad and
successful compilation is good.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman
is in the best position to support their own compiler and
platform.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org
Libtool normally queries GCC to learn what libraries it would normally
apply and carefully applies them anyway.
Is this not working for you?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,
on the system.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman/listinfo/libtool
that ranlib is not actually necessary.
You could change to the directory where the other cross-tools are and
do
ln -s /bin/true arm-blues-linux-gnueabi-ranlib
Altnerately, you could find a correct ranlib binary and make sure that
it is named appropriately.
Bob
--
Bob Friesenhahn
bfrie
with a hard-coded
run-path (-RLIBDIR or -Wl,-rpath,/libdir'), or using environment
variables like LD_LIBRARY_PATH.
As a developer, I find using the run-path to be most
reliable/convenient, but this may not be suitable when creating
packaged binaries for installation.
Bob
--
Bob Friesenhahn
for
cross-compilation since some tests are impossible when cross-compiling
and so appropriate defaults need to be supplied.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
, Makefile, or somehow induced into the execution
environment?
It seems that CPPFLAGS was constructed improperly, adding similar
stuff over and over rather than just once.
Bob
Vincent Torri
On Wed, Mar 25, 2015 at 8:39 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us
wrote:
On Wed, 25
is not intended to be an optimizer. If it drops or re-orders
options (as happens sometimes), then the build may fail.
A list of arguments which is already too long when libtool is invoked
is already a lost cause.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users
.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman/listinfo/libtool
.
I see the same issue with 2.4.5, but not with 2.4.4 (and earlier).
The 'file' command describes these as AppleDouble encoded Macintosh
file.
It does not seem possible that these files were listed for inclusion
in the release so they must be an artifact of the 'tar' program used.
Bob
--
Bob
common shells (e.g. dash, ksh, zsh).
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman/listinfo/libtool
On Fri, 6 Feb 2015, Robert Yang wrote:
On 02/06/2015 12:12 PM, Bob Friesenhahn wrote:
I am not seeing quite the difference between libtool releases that you are
although I see a big slowdown starting with 2.4.3. These timings are for
optimized builds of GraphicsMagick on a 12-core GNU/Linux
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman/listinfo/libtool
it is executed? That would certainly
lead to a huge slowdown.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org
can specify LIBTOOL
in the environment (see the Makefiles) such that it points to the
uninstalled libtool in a libtool build tree.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
were using before?
Libtoolize is not normally considered to be part of package build time
since packages usually already come 'libtoolized' (using some random
version of libtool).
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick
need more help here, then you would need to tell us the libtool
version you are using, and the operating system you are running it on.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
ldconfig might produce output based on local system
configuration (e.g. additional search directories) rather than based
on the standard for that OS release/distribution. The built binaries
might then not run if put on another system from the same OS
release/distribution.
Bob
--
Bob Friesenhahn
.
This solves the problem (automatic addition of -rpath) caused by
libtool on GNU/Linux. It is not truely portable since it can not
solve automatic tool behavior on other operating systems.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen
be considered an install/copy-only option to support
packaging.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman
me the
opportunity to solicit a bit of outside help with patching the
remaining few stubborn regressions I haven't had time to devote to
over the last 9 months.
Thank you for being fearless and for doing the work to cut the
release.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
1 - 100 of 1009 matches
Mail list logo
