makes the Makefile.am a little more readable.
Libtool "convenience libraries" are evil. If a project is using
Automake, then using a non-recursive build will allow avoiding such
things and dramatically improve build times. Automake is not
required, but it makes the task easier.
Bo
On 5/13/24 20:52, Bruno Haible wrote:
Bob Friesenhahn wrote:
Automake does have a critical bug in that for a target which only optionally
has C++ sources, that target is always linked using C++. Without this issue,
the trick of including an empty optional C++ source file in the build would
Automake, I feel that there is too much
effort, and future risk.
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
tag
is presumably overridden by CXX.
The end result fails.
Is there a way to solve this problem beyond replicating many modified
Makefile.in hunks into Makefile.am?
I am faced with backing out my attempt for yet another time. :-(
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
g to test based on the C++ compiler, then it should
also assure that linkage of dependent programs is done using the C++
compiler.
I now know how to solve this issue as pertains to GraphicsMagick. It
seems that this disparity between C and C++ may cause harm for other
software as well. Th
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 ]
quot; -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 ] -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...
to regenerate
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
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
ystem 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/
e priority 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.
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
s.
Libtool 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.simplesy
bltdl and it has its own module loader smarts.
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
ules 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
is not aware of your 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 mu
e that the compiler'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.dal
,
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
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,
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
want
while linking.
Unfortunately, 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.Graph
ds 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 Friesen
perform the 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
--
B
Windows 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,ht
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 i
ng is when the
final library or program is linked using the objects from the
convenience libraries.
Using convenience libraries does provide the benefit of avoiding the
"deadly embrace" which might be encountered when using shared
libraries with cross-dependencies.
wise
to be aware that creating 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
--
built appropriately 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/bfri
the dependent library, 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...@
efined by
XOPEN), not Windows APIs.
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://w
of "dead" code) 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...@simpl
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
nd
linked 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
t recently. Autoconf has 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, htt
ature 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.
ol, I 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.
en libtool is supposed to do the right
thing.
At this point I am wondering why I am 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,ht
n the link line and that may be the
cause of the problem 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
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
On Tue, 21 May 2019, Thomas Jahns wrote:
On 5/16/19 5:00 PM, Bob Friesenhahn wrote:
Convenience libraries are evil. Convenience libraries slow down your build
process dramatically and they cause 'make' not to be aware of the actual
underlying dependencies, so that it does much more
el build which builds 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 defe
to expand 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/publ
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
e 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/ma
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
ACLs'.
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://w
mething going on with that. Greedy matching would likely
absorb a final underscore so it might not be possible to match on that
final literal underscore. This might expose differences in behaviors
between egreps.
Bob
--
Bob Friesenhahn
bfrie...@simple.dal
link 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.da
n see 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 Friese
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
meone help 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
site) may be used
to set 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/
GraphicsM
introduce changes
which break libtool or which cause binutils programs to output
irritating messages.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.Graphics
re will 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.Gra
at 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 helpful for the case of when
configure is testing for features.
Some/many OS distributions intentionally do not distribute the .la
files.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
libtool 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/
GraphicsM
y aware 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.Graphics
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
automati
long as you don't do something to
intentionally break it (e.g. delete the .la file) or link 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,
ed 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.GraphicsMagic
pearance 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
ess.
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
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.sim
same 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.simplesy
includes 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/
ed whether 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.t
(used 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.Gra
o supply 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/
_
. Instead
it provides a working generalized solution which is usually "good
enough".
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.Graphics
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/ma
nally 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.simplesystem
provide consistent functionality across platforms and not do
things which encourage usages in one dominant platform which do not
work on the others.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Main
software.
Fujitsu 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/
w do I make this happen?
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/
Grap
ork
for the other architecture was installed 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
'.
3. Assuming 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
--
B
e software 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
--
system
libraries/headers.
Not every configure script is appropriately prepared 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.simplesy
cript, 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
wrote:
On Wed, 25 Mar 2015, Vincent
limit.
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
ool 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
ey must be an artifact of the 'tar' program used.
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
work with other 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
conf --version' every time 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/
___
You 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.GraphicsMagic
elease you 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/bfri
.
If you 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.Graphics
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
1 - 100 of 920 matches
Mail list logo
