Re: lt_dlopen an uninstalled library

2021-11-25 Thread Bob Friesenhahn

On Thu, 25 Nov 2021, ilya Basin wrote:


Loading modules is an extremely security-sensitive issue so it makes sense to 
require that the specified path be absolute


I agree. Actually I haven't told the whole truth. My goal was to 
[mis]use libtool to load dynamically a regular library that is 
supposed to be in /usr/lib/ on Unix and at the same folder as .exe 
on Windows. The reason I don't link with it is my library depends on 
some other libraries that are not in the search path and my 
executable loads them first, then loads my library. This is why a 
wrapper script would solve it.


Years ago, Gary V. Vaughan (a key libtool developer) suggested to me 
that dlopen() is quite portable across Unix-like systems (even Apple's 
OS X) and that libltdl is not really necessarily needed in order to 
load dynamic modules/modules.  This leaves Microsoft Windows for which 
it it is relatively easy to use its similar facilities via 
LoadLibrary()/FreeLibrary().


It is true that libltdl will help on systems where library 
dependencies do not work properly, or where special compiler options 
must be used, and it can be used to emulate a loadable module in 
static builds.


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.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt



Re: lt_dlopen an uninstalled library

2021-11-24 Thread Bob Friesenhahn

On Thu, 25 Nov 2021, ilya Basin wrote:


Hi Bob. I configured the GM build with '--with-modules', ran `make check` 
successfully. Then truncated the built .so files inside the 'coders/' dir to 
break it. Then reproduced the failure in gdb

   [il@reallin GM]$ export 
MAGICK_CONFIGURE_PATH='/home/il/builds/GM/config:/home/il/builds/GM/config'
   [il@reallin GM]$ export MAGICK_CODER_MODULE_PATH='/home/il/builds/GM/coders'
   [il@reallin GM]$ gdb --args ./tests/.libs/lt-constitute -storagetype char 
/home/il/builds/GM/tests/input_truecolor.miff bgr

So it turned out that the test program relies on the full path to 
the modules dir passed to the program and it calls lt_dlopen() with 
the full path. I guess I'll have to set the test environment in 
Makefile.am. Thanks.


It is interesting that this is what was causing problems for you. 
Loading modules is an extremely security-sensitive issue so it makes 
sense to require that the specified path be absolute, or written like 
./foo.la.


Regardless, GraphicsMagick does some things differently than perhaps 
the original libtool/libltdl objectives since it tries not to be too 
dependent on libltdl 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



Re: lt_dlopen an uninstalled library

2021-11-23 Thread Bob Friesenhahn

On Mon, 22 Nov 2021, ilya Basin wrote:


Hi List.
I'm making a program with plugins as shared libraries and when I run `make 
check` I want my program to load the uninstalled plugins using lt_dlopen().

I expected that passing `-dlopen libname.la` to libtool would force 
the generation of a wrapper script setting the proper 
LD_LIBRARY_PATH (just like regular linking with a shared .la does). 
However, an ELF binary is generated and and attempt to call 
lt_dlopen("libname.la") fails with "File not found". It only 
succeeds if the filename contains "./.libs/". What am I doing wrong?


I am not sure what the correct answer is.  Normally loadable modules 
do not have "lib" prefixes and so normally one does not use a "lib" 
prefix in conjunction with -module.  Use of "lib" prefixes is for 
shared libraries indended to be linked with using a linker (for 
software compilation).


When libtool builds shared libraries and modules, it puts them in a 
".libs" subdirectory.  The ".la" file in the build directory should be 
enough for libltdl to load the module from the hidden ".libs" 
subdirectory.  When the module is installed, the a new ".la" file is 
created which is correct for the installed form, and the module may be 
re-linked while being installed.


Feel free to look at GraphicsMagick (http://www.GraphicsMagick.org/) 
source code for ideas.  GraphicsMagick uses lots of modules 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



Re: [patch #9687] bugfix: make -export-dynamic imply --whole-archive

2021-11-21 Thread Bob Friesenhahn

On Sun, 21 Nov 2021, Alex Ameen wrote:


Overall I think we're on the same page. I understand that `libtool' is 
ultimately intended to provide cross-platform consistency as a portability 
wrapper around each platform's various compilers, linkers, and loaders. It is 
certainly not my intention to promote a specific tool or platform over 
another.


I am glad that our new maintainer is philosophically on the same page 
and also has excellent skills.


I think that (similar to the influence of GNU/FSF philosophies on 
software development) libtool should help guide application developers 
to to use the most portable approaches while achieving their own 
objectives.  From this standpoint, libtool (and Autotools in general) 
are not just 'tools' (like 'ld') but help guide users (developers) so 
that if they follow guidelines, and what the tools intend to promote, 
their applications are most likely to be portable and still work well.


If the development/porting problem is looked at using Venn diagrams, 
then there would be a proportion of features/solutions in common 
amongst modern targets and those should be the features/solutions 
which are promoted by Autotools.  In some cases the description of 
what is wanted can be at a high enough level that the desired 
low-level behavior can be accomplished entirely differently on 
different targets (because of how they work).


In Autotools, the above has worked well, although there have been many 
complaints over the years about 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 Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt



Re: [patch #9687] bugfix: make -export-dynamic imply --whole-archive

2021-11-21 Thread Bob Friesenhahn

On Sat, 20 Nov 2021, Alex Ameen wrote:

Thanks for the follow up, this gave me a much clearer idea of the underlying 
issue that you're trying to solve. I really do appreciate you taking the time 
to help improve `libtool'.


You're absolutely right that `libtool' completely bungles the use of 
`--whole-archive' and `--no-whole-archive' which I see as a high priority 
issue. In several build systems I've built in the past I have needed to apply 
manual patches to `libtool' to work around this, and I plan on merging 
changes to fix this soon ( I'm taking my time to create test cases ).


I don't pretend to understand the associated issues, but please take 
care that libtool does not promote solutions which only work with GNU 
ld (or linkers designed to perfectly emulate GNU ld) on a limited set 
of targets.


Libtool is a portability solution to encourage development of software 
which is able to compile and run on many targets, even if the authors 
of the software have never experienced those targets.


Linking static libraries into shared libraries is a complex topic and 
is a reason why libtool offers the clumsy/inefficient "convenience 
library" mechanism since 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.org/users/bfriesen/public-key.txt



Re: Organization of ltmain.in into sub-files

2021-10-18 Thread Bob Friesenhahn

On Mon, 18 Oct 2021, Alex Ameen wrote:


This sounds great to me, I'd love to lend a hand.

I had filled out the form a few weeks ago when I sent in patch for 
`/usr/bin/file' references, so that might still be sitting in the queue for 
review. If not, let me know and I can file a new request.


The problem is that there are no libtool maintainers to service your 
requests. :-(


This means that you would need to contact the GNU organization to 
express your interest in becomming a libtool maintainer.


There are many pending bug reports with patches to be integrated. Your 
own work may 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



Re: Organization of ltmain.in into sub-files

2021-10-18 Thread Bob Friesenhahn

On Sun, 17 Oct 2021, Alex Ameen wrote:


I thought I had seen in some TODO notes that other maintainers had been
working on reorganizing `ltmain.in', so I wanted to poke my head in and see
if there was an existing branch doing this sort of works, or if this was
something that anyone thinks would be useful as a project branch? Right now


Your work sounds like an excellent idea.  The major problem for the 
libtool project right now is that (as far as I am aware) there have 
not been active maintainers for years.  It seems like you have the 
skills required for this task.  Becoming 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://www.simplesystems.org/users/bfriesen/public-key.txt



Re: [EXTERNAL] Re: LD_LIBRARY_PATH in wrapper scripts

2021-08-22 Thread Bob Friesenhahn

On Sat, 21 Aug 2021, Oleg Smolsky wrote:


So, if libtool does not believe that /usr/lib/x86_64-linux-gnu is in
the default search path, it adds it.


Right, and my compiler is in /opt/gcc-11/ and so that addition to
LD_LIBRARY_PATH is wrong. The system's compiler is older than what we use
and the forced (older )version of libstdc++ breaks the executable.


You should talk to the person who built and installed this compiler. 
I recollect that it was you. :-)


Does

  gcc -print-search-dirs

produce correct/useful output for your compiler?

If the system's 'ldconfig' 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 multiple compilers.


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



Re: LD_LIBRARY_PATH in wrapper scripts

2021-08-21 Thread Bob Friesenhahn

On Sat, 21 Aug 2021, Oleg Smolsky wrote:



Hello there! We have an autotools-based build system setup with a custom GCC 
where we take all build- and run-time dependencies (except for glibc)
from /opt. Things have worked well on Ubuntu 16, yet I'm hitting a funky issue 
when building on Ubuntu20 (libtool 2.4.6-14 according to dpkg). The
issue comes down to one of the wrapper scripts that contains this gem:

    # Add our own library path to LD_LIBRARY_PATH
    
LD_LIBRARY_PATH="/usr/lib/x86_64-linux-gnu:/home/oleg/project/_obj/.libs:/opt/gcc-11/lib/../lib64:$LD_LIBRARY_PATH"

Most of our libs are statically linked with exception of just one. So 
tests/apps that use that shared lib end up with libtool wrappers... and they
work correctly on Ubuntu16 (libtool 2.4.6-0.1 according to dpkg). It seems that 
libtool version just does not stamp out this extra variable...

The manual fix is to remove the "/usr/lib/x86_64-linux-gnu" bit from the 
LD_LIBRARY_PATH above... and yet I have no idea where it came from or
whether there is a way to influence its composition from a Makefile.am file.


I think that libtool tries to deduce the default run-time linker 
search path (e.g. as used/provided to ldconfig, and also documented in 
the 'ld.so' manual page) and it also tries to learn where the 
compiler's own libraries are installed.


So, if libtool does not believe that /usr/lib/x86_64-linux-gnu is in 
the default search path, it adds it.


Note 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.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

Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project

2021-08-11 Thread Bob Friesenhahn

On Wed, 11 Aug 2021, Alexei Podtelezhnikov wrote:





And as I prefer DLL compared to static lib, I know what to do :-)


I have the distinct impression that static libraries are rarely used under 
Windows any more.


Perhaps I am off base here. Isn’t this why DLL comes paired with a LIB wrapper, 
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 Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project

2021-08-11 Thread Bob Friesenhahn

On Wed, 11 Aug 2021, Vincent Torri wrote:


The only solution I can see is : forcing to have only one specific
library. either static or shared, and throw an error if the wrong lib
is chosen at configure time.

And as I prefer DLL compared to static lib, I know what to do :-)


I have 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://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt



Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project

2021-08-10 Thread Bob Friesenhahn

On Tue, 10 Aug 2021, Vincent Torri wrote:


Perhaps better solution is use of -export-symbols.


As I have said, the problem is not the lib itself. There is no problem
with the lib. The problem is with the binary : when I compile it,
there is no way to know if the library, that the binary uses, is a
static library or shared library (know == having a macro to
distinguish shared lib and static lib)


This is a good point.  For GraphicsMagick we just had to deal with it 
and provide an external way to know how the library was expected to 
have been compiled.


This is fragile since 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/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt



Re: [EXTERNAL] Re: Unhelpful automatic 3rd-party library linkage

2021-06-30 Thread Bob Friesenhahn

On Tue, 29 Jun 2021, Oleg Smolsky wrote:

Are you absolutely sure that the above is true?  You specified c++17
when compiling your application.  Are the libstdc++ ABI's the same
across GCC versions and C++ language versions?



Well, I want to claim that I am absolutely sure :) My understanding is that
there have been no ABI breaks in the GCC/libstdc++ ever (even noting the
5.x move to the Standard-compliant std::string). The general principle is
to let people/distros upgrade gcc/libstdc++ in the OS and let the old apps
continue running.


That is a good thing.


:) I am the person who maintains the compilers (installed into /opt/gcc-xx)
and 3rd-party libs (installed into /opt/3p) at our shop. I don't care to
update the system's compiler or libs as we don't use them at all. That is,
our build system uses our compiler and only links to the 3rd-party
dependencies from /opt.


Been there.  Done that. :-)


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.



Right, I figured this very point out just a couple hours ago - the extra
flags/libs (along with the -lzmq transformation) come from the ".la" file.
I've rebuilt the lib, purged the file and things look good now for my build.

Could you shed some light on how this .la file is supposed to be used? I
see that it tries to be helpful by capturing the dependencies... but it
seems to destroy the standard `-lfoo` contract. IE it appears that it
reduces the level of abstraction needlessly for artifacts that are
distributed/stored. Is this ".la" thing meant only for build systems where
the whole tree is built from scratch at the same time?


It is true that the .la files encode all of the library dependencies 
which were current at the time.  This is the most common complaint 
regarding libtool.


If this was not supported for static compilation, then static 
compilation would not be possible.  Systems which do not support 
implicit dependencies in shared libraries also need this.


A model whereby libtool can know which explicit dependencies are 
desired and which should not not be recorded/replayed was never 
proposed.


As a result, it has become common for ".la" files to be deleted or 
edited (they are simple text files) in order to achieve the goals of 
binary distributions.


In your case it seems you are in complete control. You could put the 
most recent libstdc++ library in a common area and modify the ".la" 
files to refer to that one instead.  If necessary provide a modifed 
GCC spec file to assure that the compiler itself does what you 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.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt



Re: Unhelpful automatic 3rd-party library linkage

2021-06-29 Thread Bob Friesenhahn

On Tue, 29 Jun 2021, Oleg Smolsky wrote:


...and I have figured out the source of the mystery linker flags: zmq build
leaves libzmq.la file which contains this:

# Libraries that this one depends upon.
dependency_libs=' -lrt -lpthread /opt/gcc-10/lib/../lib64/libstdc++.la'

It looks like automake/libtool finds this file (BTW, when is it found?) and
transforms `-lzmq` into a whole bunch of things (with explicit .so names
and dependencies)...


Yes, that is part of the function of libtool. In fact (as you can 
see), the libstdc++.la file was provided with the compiler.


These are features that you may love or hate depending on what you are 
doing.


For example, if the information necessary to find the library is 
missing (and it is not in the default system library search path), 
then the program would fail to run!


If a program attempts to link with a library which depends 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...@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



Re: Unhelpful automatic 3rd-party library linkage

2021-06-29 Thread Bob Friesenhahn

On Tue, 29 Jun 2021, Oleg Smolsky wrote:


It looks like GCC9 references come from libzmq:

$ ldd /opt/3p/lib/libzmq.so | grep libstd
   libstdc++.so.6 => /opt/gcc-9/lib/../lib64/libstdc++.so.6
(0x7f95f8d9f000)

Obviously the 3rd-party library was built a while ago with GCC9. At the
time it was linked to the compiler's runtime... but now the main
application has moved to GCC11 and I'm linking to the runtime that is
correct right now.

It looks like automake/libtool try to be helpful and check the library's
dependencies... but that gets in the way as the new libstdc++ is a strict
superset of the old one. They maintain ABI compatibility and so scenarios
like these are supported.


Are you absolutely sure that the above is true?  You specified c++17 
when compiling your application.  Are the libstdc++ ABI's the same 
across GCC versions and C++ language versions?



Is there a way to suppress dependency tracking for the 3rd-party libraries?
I wish Libtool/automake was not trying to be smart and simply passed
"-lzmq" directly to the linker. Yet instead, the actual .so file is
discovered and then its libstdc++.so is linked. This is just wrong for the
scenario at hand.


Assuming that the whole system does not have these directories in the 
default search path (e.g. via ldconfig), it appears that this is a 
recorded implicit dependency which is encoded in the library itself. 
The only way to remove such an implicit dependency is to rebuild the 
library (e.g. libzmq.so) with different options.


If the persons who delivered the compilers to you expected that the 
C++ library was truely reusable, then they would not have have put 
everything under /opt/gcc-foo directories (also suggesting that these 
directories are removable).  Instead they would have put the C++ 
run-time libraries in a standard system location.  For example, under 
Ubuntu Linux, I see that libstdc++.so.6 is at 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 which is a common system 
directory.


As far as I am aware, there is no option to request that libtool 
not 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
--
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



Re: libtool hangs in func_convert_core_msys_to_w32 when cross-compiling with mingw under cygwin

2021-06-25 Thread Bob Friesenhahn

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)?


Libtool was last released in 2014.  Nothing has changed since then. 
:-)



Can libtool just ditch all of the back and forth path conversions, and
simplify all of this?


I am not sure what the current situation is now but MinGW 
compilers/tools used to accept Windows paths only because they were 
native 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,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt



Re: [EXTERNAL] Re: Q: library dependencies

2020-09-25 Thread Bob Friesenhahn

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 the final library or 
program is linked using the objects from the convenience libraries. 


Hi Bob, how would I make a "proper" library? Would that change the 
composition logic for my DAG of dependencies?


I find info on these topics at
https://www.gnu.org/software/libtool/manual/libtool.html#Static-libraries

According to the docs "If you omit both -rpath and -static, libtool 
will create a convenience library that can be used to create other 
libtool libraries, even shared ones."


and then

"When GNU Automake is used, you should use noinst_LTLIBRARIES instead 
of lib_LTLIBRARIES for convenience libraries, so that the -rpath 
option is not passed when they are linked."


Convenience libraries and static libraries do not technically have 
"dependencies" since they only represent a compilation step (no 
linking).  If a static library may also be built as a shared library 
then it may have dependencies and should be described as such.


The final shared library or program itself surely has "dependencies" 
since otherwise it might not successfully link due to unresolved 
symbols.


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



Re: [EXTERNAL] Re: Q: library dependencies

2020-09-25 Thread Bob Friesenhahn

On Fri, 25 Sep 2020, Oleg Smolsky wrote:


Well, AFAIK any well-formed .a file (an archive) is a static lib. And these
can be passed to the linker. Are you saying that libtool extracts the
individual .o files instead passing -lfoo (for libfoo.a)?


Exactly!  It might as well be a tar file except that the 'ar' archiver 
knows how to add/update/remove files from it and that is not possible 
with a tar file.  The ability to do incremental updates of the archive 
file is important as objects are built/rebuilt.  The 'make' program 
itself already understands archive files.



The convenience library does not do anything regarding mutiply-defined
symbols (at the C language level) while linking.  If there is a
conflict then the linker should normally fail.


I find the situation puzzling. My project has just over a hundred of these
LT convenience libraries and there are several places where collisions
result in renaming. Yet nowhere do I see multiply defined symbols.


Probably the "renaming" is the naming of the extracted object files. 
The object/library symbols can not be renamed.


Over a hundred convenience libraries sounds like quite a lot!


If libtool/automake scripts do not do dedup... I can only guess that the
linker sees .o files inside multiple .a archives (or multiple .o files
coming from distinct directories via the command line) and performs dedup.
Is that getting closer to the truth?


When it extracts the files the file names can not collide.  Automake 
can help with this by producing unique naming.



My setup is a large, non-recursive thing with "include" statements. On the

top of that I am trying to understand the issues and costs imposed by the
convenience libraries. My primary ask is transitive dependencies between
the libs as I have more than 100 of them (and several dozen apps and
hundreds of tests).


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 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.


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



Re: [EXTERNAL] Re: Q: library dependencies

2020-09-25 Thread Bob Friesenhahn

On Thu, 24 Sep 2020, Oleg Smolsky wrote:

Libtool convenience libraries are not "real" static libraries. 
Instead they are object files stored in an archive file.  Prior to use 
(when linking using libtool) the objects are extracted and passed to 
the linker directly (perhaps with renaming to assure there are no 
over-writes during the extraction).  While libtool convenience 
libraries are certainly "convenient" they can dramatically slow down 
the build.  It takes time to do the operations associated with the ar 
files, but most importantly it prohibits parallelism in the build.



So, I am not sure what can be done here. Could you clarify the following
please:
- Does the aforementioned renaming bloat the executable?


Bloating of the executable depends on the object files linked with it. 
Linkers may vary as to how smart they are at ignoring supplied objects 
where no symbols have been used.



- How is the linker able to resolve mutiply-defined symbols for the
duplicated nodes in the DAG?


The convenience library does not do anything regarding mutiply-defined 
symbols (at the C language level) while linking.  If there is a 
conflict then the linker should normally fail.



- Is there an alternative way to express inter-lib dependencies with
automake/libtool?


Using a non-recursive build and using Automake macros to express what 
is currently expressed as convenence libraries (using original object 
files in place rather than storing in 'ar' format and extracting over 
and over) will tremendously decrease build times.  Automake supports 
an include syntax which allows distributing build information in the 
project (e.g. putting it in subdirectories next to source files) yet 
incorporating in single build.  If everything is ruled by one 
non-recursive 'make', and the dependencies are properly cascading, 
then using Automake's non-recursive build capability will provide a 
huge boost to build performance, and particulary on modern multicore 
systems.


Since you are concerned about maintenance, then of course it is 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
--
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



Re: Can't make dll out of a static convenience library: This system cannot link to static lib

2020-07-10 Thread Bob Friesenhahn

On Sat, 4 Jul 2020, basini...@gmail.com wrote:


Hi. I'm trying to build mingw-w64-gnutls 3.6.12 on Archlinux. At some point it 
wants to make a C++ dll out of a C convenience static library and a C++ object 
file, but libtool omits the static library and link fails with undefined 
reference.
I don't understand why libtool omits the static library, because if I call g++ 
directly the dll is created just fine. I had to manually add `-lssp` to the 
command line, but I'm not sure if that's the cause.


Libtool assumes that static libraries do not contain objects which are 
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/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt



Re: Linking with -lname key

2020-06-07 Thread Bob Friesenhahn

On Sun, 7 Jun 2020, Vict wrote:


Hello. Sorry if I didn't study the documentation well, but I don't understand
the following aspect: why does libtool not link to its own la archives when
linking with a -lname key?


Since you mention /usr/local/lib, can you confirm that LDFLAGS 
includes -L/usr/local/lib or that this argument was otherwise supplied 
to libtool?



Let's link a test program with libmy:
$ libtool --tag=CXX --mode=link g++ -o test_app  test_app.o -lmy
test_app does not become dependent on libflt and libEGL (they are not in the
dynamic section labeled "NEEDED".
Linking test_app with absolute path to libmy does:
$ libtool --tag=CXX --mode=link g++ -o test_app  test_app.o
   /usr/local/lib/libmy.la

but relying on absolute path is bad. I can’t know in advance
where the library will be installed (/usr/lib, /usr/local/lib, ...).


By "know in advance", do you mean that as a software developer you 
can't know the configuration of some other system while building, or 
do you mean that the libraries may be installed to some random 
locations?


Note that when libtool is used to install libraries, it may re-link 
the libraries so that the results are different than with 
"--mode=link".


You should also consider that the operating system may or may not 
search the directory containing the shared libraries.  If it does not 
search the directory (e.g. /usr/local/lib in your case) and there is 
no run search path in 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...@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

Re: libtool related compile issue on msys2

2020-02-09 Thread Bob Friesenhahn

On Sun, 9 Feb 2020, Torsten Kühnel wrote:


Hi, i encountered 2 similar errors in an attempt to build check-0.14.0
and popt-1.16 on latest msys2.


Msys2 targets native Windows APIs.  I suggest consulting Microsoft's 
API documentation.



...
./.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 |   rval = (int) _spawnv (_P_WAIT, lt_argv_zero, (const char * const *) 
newargz);
 |^~~
 |spawnv

A bit more detailed on https://pastebin.com/VKnYxXXm


It seems like a Windows header file which declares spawnv is not being 
included.



For libcheck the problem can be solved by using cmake to build it. But
autotools/automake build system should work, too, as long as it is supported.

What i hope will be until the end of the universe :)

Configuring with any CFLAGS=-D_XOPEN_SOURCE=500 or such did not solve the 
problem.
Any help apreciated.


It would be senseless for -D_XOPEN_SOURCE=500 to help for Msys2 
because this is an option for POSIX APIs (specifically APIs defined 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://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: checking command to parse /usr/bin/nm -B output from gcc object... failed

2020-01-07 Thread Bob Friesenhahn

On Tue, 7 Jan 2020, Nick Bowler wrote:


On 1/7/20, Martin Liška  wrote:

nm -B detection fails to be detected with -flto and -fno-common CFLAGS:


I don't know what vintage this documentation is (the copyright says it 
is from 2020 so it seems to be the latest), but the page at 
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html says this 
about "-fcommon"


"The default is -fno-common, which specifies..."

GCC 9.2 documentation says that the default is target dependent, which 
suggests that some targets use no-common by default.



I'm not 100% sure which libtool features will be affected by this
configuration failure.  It doesn't fatally stop the configure script.
Probably dlpreopen won't work at all?


Are there many users of dlpreopen()?


It's also unfortunate that since there is no way to directly reference
symbol values in standard C, a common way to do so is with dummy array
or function declarations, and lo and behold LTO apparently breaks this
too...


LTO often causes strange issues.  It needs to be used with care.

Thus far I have seen LTO reduce the output executable size (sometimes 
substantially if there is a lot 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

Re: transitive shared library dependencies and installation

2020-01-05 Thread Bob Friesenhahn

On Sun, 5 Jan 2020, wf...@niif.hu wrote:


On the other hand, this overlinks the final binary:

$ objdump -p .libs/translib | fgrep NEEDED
 NEEDED   liba.so
 NEEDED   libb.so
 NEEDED   libc.so.6

libb.so is unneeded here (but is present in the installed program as
well).  Coincidentally, the most prominent search result
https://wiki.mageia.org/en/Overlinking_issues_in_packaging mentions that
"this is fixed using a patch from Debian" for libtool.

What's your position on this?  Is overlinking a problem or not?  (It
causes problems for distributions.)  Should everybody use --as-needed
globally to combat it?  Something else entirely?


This has been the most common complaint (in the GNU Linux world) I 
have heard about libtool.  There is a choice of working reliably and 
portably (with possible over-linking) or relying on implicit library 
dependencies (which are definitely not portable), or failing as you 
have encountered.  A similar complaint is that libtool uses 
information in installed ".la" files in order to link with all 
libraries that the program/library is dependent on.  Due to this, GNU 
Linux distributions 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.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



Re: transitive shared library dependencies and installation

2020-01-04 Thread Bob Friesenhahn

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 and
linked in a particular order.



Do you happen to know which systems these are?  Where are these
constraints documented?


It's been a very long time since I've built shared libraries for any
platform other than Linux, but my distant recollection is that AIX and
HP-UX encoded the full path to the dynamic library against which a binary
was linked.  Therefore, if you built an executable against uninstalled
libraries, the executable would have a reference to the build directory,
hence the explicit relinking step after installation to pick up the new
paths.  I seem to recall that we caused an outage for campus AIX systems
because of this; I'm less sure about HP-UX.

I don't remember whether this also applied to interdependencies between
shared libraries (or if those platforms even supported encoding
dependencies in shared libraries; a lot of platforms didn't).  I vaguely
recall that mutually-dependent shared libraries were actually impossible
on at least some UNIX platforms, and thus not portable.


The above matches my own memories.  I do not know the current level of 
usage for AIX or HP-UX but expect that they are still used for 
business purposes because at various times they were market leaders 
and offered the type of support that large businesses needed for 
critical systems.


Mutually-dependent shared libraries are to be avoided in any case.

Using Autotools, I do not recall any particular effort involved with 
supporting AIX, HP-UX, or even IRIX in GraphicsMagick builds.


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



Re: transitive shared library dependencies and installation

2020-01-04 Thread Bob Friesenhahn

On Sat, 4 Jan 2020, wf...@niif.hu wrote:

...
Above dependency explain all - lib_LTLIBRARIES is project (sample)
specific. Project should ensure order.


Fair enogh, but my point (which I didn't really emphasize) is that
installation could work in any order, if relinking didn't depend on
already installed libraries.  It's even necessary for mutually dependent
libraries.


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 and 
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



Re: transitive shared library dependencies and installation

2020-01-03 Thread Bob Friesenhahn

On Fri, 3 Jan 2020, Richard Purdie wrote:


Libtool must also work for static linking.  It seems to me that your
issue also impacts static linking.


I think the challenge that libtool has here is that many of these older
systems that libtool supports aren't so prevalent anymore.


This is true.  It is possible that support for some archaic compilers 
and systems should be removed since there is no way to verify that the 
support works anymore, and there might not be any more active users.


Regardless, libtool must continue to support static linking, even if 
deployment usually uses dynamic linking.  As a developer, I use static 
linkage for daily development yet recommend dynamic linkage for 
most deployments.



We have a number of libtool patches to sort cross compile issues which
really need discussion with upstream libtool. With the lack of
releases, our incentive to do that diminishes :(.


You can become part of upstream libtool and commit your fixes 
directly.



Finding new maintainers with the amount of knowledge of weird older
systems needed is going to be a struggle which only gets worse over
time :(


Most systems are not so weird.  Most problems with legacy targets have 
been due to shell and common utility differences/bugs (e.g. depending 
on 'bash' syntax or behavior of 'echo'.  These problems are due to the 
Autotools assumption that Autotools should be able to work with the 
shell and utilities that originally came with the system.


If it is impossible to find a representative target system to test on, 
then that is an indication that support should be deprecated.  Users 
of unpopular systems need to stand up for themselves and assist, even 
if only by providing remote access to test on the system.



I do worry about the future here as libtool is a key part of the
autotools fabric but its most likely to be wholesale replaced given how
things are trending.


The current trend is that all of Autotools at risk even though it 
still works pretty well.  Perhaps Automake is in best shape since it 
was released most 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, http://www.simplesystems.org/users/bfriesen/public-key.txt



Re: transitive shared library dependencies and installation

2020-01-02 Thread Bob Friesenhahn

On Thu, 2 Jan 2020, wf...@niif.hu wrote:


If Libtool were to depend on non-portable features, [...] then it
could not longer be described as a portability tool.


In my understanding, Libtool is a portability shim, providing a regular
interface for developers across systems with wildly varying features.
It already uses non-portable features, just different ones on different
architectures.  I don't say it should use -rpath-link generally, I only
suggested that it might be an efficient solution on systems supporting
it.  But I expect all systems supporting shared objects to allow using
and installing them some way, irrespective of their interdependencies.
Am I overly naive?


Certainly, libtool could use -rpath-link where it is supported but 
libtool provides a common feature set and if it is only possible to 
support a feature where -rpath-link is available, then offering the 
feature 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, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt



Re: transitive shared library dependencies and installation

2020-01-02 Thread Bob Friesenhahn

On Thu, 2 Jan 2020, wf...@niif.hu wrote:

True, but man ld states in the -rpath-link option description that the
directories specified by -rpath options are used with a very high
priority for locating required shared libraries.


This is interesting but I am not seeing any use of -rpath-link in
libtool.


Neither do I, but I think it would be a possible way out of this
situation.  I wonder what the reason could be for libtool not using it.


Libtool is a portability tool.  If it were to depend on non-portable 
features, then software would be implemented using it which is 
non-portable and the software developers might not be aware of it. 
If Libtool were to require GNU Linux, or GNU ld, or GNU gcc. or GNU 
libc, or ELF, then it could not longer be described as a portability 
tool.


Indeed, if one makes some assumptions and is willing to lose some 
portability then it is not difficult to use underlying tools directly, 
without using libtool at all.


At one time it was assumed that GNU software would reach the largest 
number of potential users by being implemented in a portable fashion. 
An alternative would have been to require that GNU software can only 
be compiled on GNU systems (this would have been impossible to start 
with since such a system did not exist) using GNU tools.



It's rather hard to get support for libtool, but I sorely need some,
because this issue hurts a real software project.  Since this is the
first time I seriously deal with libtool, 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.


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



Re: transitive shared library dependencies and installation

2020-01-02 Thread Bob Friesenhahn

On Thu, 2 Jan 2020, wf...@niif.hu wrote:


In this case libtool is a slave of Automake and Automake is
controlling the build and installation order.  This means that it
should be expected behavior.  Installation is serialized and thus
order matters.


But in case of a dependency cycle there's no correct order if libtool
insists on using the installation directory for the -L option for
relinking.  And the installation directory may contain an incompatible
version of the library anyway, just like it happens below.


Indeed, sometimes it is necessary to re-organize libraries and code in 
order to be successful given serialized linking.



and use it from liba, linking the final binary fails:

$ make
[...]
/bin/bash ./libtool  --tag=CC   --mode=link gcc  -g -O2 -avoid-version  -o 
translib translib.o a/liba.la
libtool: link: gcc -g -O2 -o .libs/translib translib.o  a/.libs/liba.so 
-Wl,-rpath -Wl,/tmp/translib/lib
/usr/bin/ld: a/.libs/liba.so: undefined reference to `b2'

As I understand it, the -rpath linker option on the above command makes
a/.libs/liba.so use the already installed (old) version of libb, which
lacks the b2 symbol.  What's the solution here?  Why isn't that -rpath
option "delayed" until the relinking phase?


The -rpath linker option did not cause the library to be used.


The above gcc linking command is successful if I omit the -rpath option.
(The built-in RUNPATH of liba.so contains the build directory first.
Just for the record: Debian's ld defaults to --enable-new-dtags.)


I am not sure exactly what --enable-new-dtags means, but Ubuntu 18.04 
LTS's manual page says that this is not its default.  This may 
indicate changing behavior.



The '-r' in -rpath stands for 'run' and thus it is a path stored in a
built shared library or executable which tells it where to search for
other libraries when th program is executed.


True, but man ld states in the -rpath-link option description that the
directories specified by -rpath options are used with a very high
priority for locating required shared libraries.


This is interesting but I am not seeing any use of -rpath-link in 
libtool.



Perhaps the controlling parameter is hardcode_into_libs.  If your
libtool comes from an OS distribution rather than from a FSF/GNU
tarball, then it is possible that its behavior may have been modified.


I don't know what to expect, here's what I can see:

$ ./libtool --config | fgrep hardcode_into_libs
hardcode_into_libs=yes


I am not seeing 'libb' mentioned on the link line and that may be the
cause of the problem you are seeing.


Sure enough, adding libb.la explicitly to the link command works around
the issue, but since the binary does not use libb directly, it doesn't
sound like a good solution to me, because it leads to overlinking.


Libtool can only know what has been passed to it via the command line 
and via the prior information it stored in the .la files (initially 
found due to the command line).


I have always found it to be good practice to include all dependency 
libraries in an Automake 'LIBADD' statement so that all dependency 
libraries are passed to libtool.  If the .la file passed to libtool 
mentions the dependencies, then 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,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt



Re: transitive shared library dependencies and installation

2020-01-01 Thread Bob Friesenhahn

On Wed, 1 Jan 2020, wf...@niif.hu wrote:

make[1]: Leaving directory '/home/wferi/ha/pacemaker/translib'
make: *** [Makefile:798: install-am] Error 2

No cyclic dependencies here, so this can be worked around by

-lib_LTLIBRARIES = a/liba.la b/libb.la
+lib_LTLIBRARIES = b/libb.la a/liba.la

in this case; is this expected (and documented) behavior?


In this case libtool is a slave of Automake and Automake is 
controlling the build and installation order.  This means that it 
should be expected behavior.  Installation is serialized and thus 
order matters.



and use it from liba, linking the final binary fails:

$ make
[...]
/bin/bash ./libtool  --tag=CC   --mode=link gcc  -g -O2 -avoid-version  -o 
translib translib.o a/liba.la
libtool: link: gcc -g -O2 -o .libs/translib translib.o  a/.libs/liba.so 
-Wl,-rpath -Wl,/tmp/translib/lib
/usr/bin/ld: a/.libs/liba.so: undefined reference to `b2'

As I understand it, the -rpath linker option on the above command makes
a/.libs/liba.so use the already installed (old) version of libb, which
lacks the b2 symbol.  What's the solution here?  Why isn't that -rpath
option "delayed" until the relinking phase?


The -rpath linker option did not cause the library to be used.  The 
'-r' in -rpath stands for 'run' and thus it is a path stored in a 
built shared library or executable which tells it where to search for 
other libraries when th program is executed.


The libtool configuration may be dumped using

  ./libtool --config

Perhaps the controlling parameter is hardcode_into_libs.  If your 
libtool comes from an OS distribution rather than from a FSF/GNU 
tarball, then it is possible that its behavior may have been modified.


I am not seeing 'libb' mentioned on 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



Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new

2019-06-26 Thread Bob Friesenhahn

On Wed, 26 Jun 2019, Roumen Petrov wrote:


but this is error-prone because

some other toolchains might use a different C++ library.


Oracle Solaris 11 with the Solaris Studio 12 compiler supports a large 
number of C++ runtime libraries as described at


  https://docs.oracle.com/cd/E37069_01/html/E37075/bkaje.html

When dealing with C++, one must know what one is doing.  The only 
portable way to link with C++ is by assuring that the main() function 
is in a C++ module.  If the C++ compiler is intentionally used to link 
using the other options supplied to the compiler, then the correct 
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 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

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new

2019-06-24 Thread Bob Friesenhahn

On Mon, 24 Jun 2019, Roumen Petrov wrote:


Reporter still does not provide feedback with information from configuration 
time (requested in a previous post) => resolution is - broken build 
environment.


I think the problem is an unreasonable expectation which is becoming 
more unreasonable 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, 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


Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new

2019-06-23 Thread Bob Friesenhahn

On Sun, 23 Jun 2019, Yuri wrote:


So is there an easy way to override this and always use C++ way of linking?


To do this you might need to set LD or CC to your C++ compiler.  A 
better way is to make your main program be C++ since that assures it 
can work.


Consider that C++ exceptions can 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, 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


Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new

2019-06-23 Thread Bob Friesenhahn

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 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 is not enough.


C++ introduces a new wrinkle in that there are now often 3 or 4 
different C++ variants available based on C++ standard level, and 
library options (e.g. different C++ STL library implementations).


Things have changed quite a lot in the past several years when it 
comes to C++.


In addition to being linked using the C++ compiler, the correct 
options would need to be passed to the C++ 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-key.txt

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new

2019-06-23 Thread Bob Friesenhahn

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...@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

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Avoid -Wl,--whole-archive

2019-05-16 Thread Bob Friesenhahn

On Thu, 16 May 2019, Tim Rühsen wrote:


Hi,

at GNU Wget2 we are just splitting a (shared) library into several
smaller ones, grouped by functionality.

We depend on gnulib and have a single libgnu.a. Each of the shared
libraries just need a certain set of functions from libgnu.a.

To avoid adding everything from libgnu.a to each of the libraries, we
would like to avoid "-Wl,--whole-archive ../lib/.libs/libgnu.a
-Wl,--no-whole-archive".


There is no requirement to use "convenience" libraries.  People who do 
things due to "convenience" are often classified as "lazy". :-)


If you have time to re-do your build structure, then I recommend using 
a non-recursive build and explicitly listing the objects which are 
needed by each library in the single Makefile.  Objects common to 
multiple libraries will then be built just once and supplied to the 
linker as a list of object files rather than fed to libtool like an 
"archive" file which is then split into object files actually supplied 
to the linker.


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 work 
than is required each type you invoke 'make'.  If you can enumerate 
the actual dependencies in the Makefile and avoid needless 
intermediate product generation, then you will achive a maximally 
parallel 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 defective.


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___
https://lists.gnu.org/mailman/listinfo/libtool


Re: GCC LTO options not correctly handled

2019-04-12 Thread Bob Friesenhahn

On Fri, 12 Apr 2019, Laurent Stacul wrote:


As I don't have the ownership on the project, I need to patch (and
provide a patch upstream). But this can be tedious on big projects, so
it would great if libtool don't filter the options like -fno-lto,
-fno-whopr.


The path of least resistance is to use the GCC -Wl, or -Wc, syntax to 
pass options to the linker or compiler, respectively.  This already 
works well with Autoconf, Automake, and libtool.


Adding support to libtool to support particular GCC options is the 
path of greatest resistance.


Compiler and linker options tend 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/public-key.txt

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Regd. use of libtool in commercial applications

2019-03-14 Thread Bob Friesenhahn

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 exception to the GNU General Public License,
# if you distribute this file as part of a program or library that
# is built using GNU Libtool, you may include this file under the
# same distribution terms that you use for the rest of that program.

There are also special exceptions if you use libltdl.

It is good that you are interested in complying with the license. 
You are responsible for reading the license text for each involved 
component and making sure that you follow the license.


I am not a lawyer, but it is my opinion that if you use libtool as it 
is intended to be used, you may use 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.simplesystems.org/users/bfriesen/public-key.txt

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Cut a new release?

2018-09-27 Thread Bob Friesenhahn

On Thu, 27 Sep 2018, Robert Boehne wrote:


I would be more than happy to cut a release, if only I could remember how.
I think the last version I released was 1.5.x - I'll look around but if
anyone on the list remembers where the instructions are - please help me
out ;)


I think 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/listinfo/libtool


Re: Cut a new release?

2018-09-21 Thread Bob Friesenhahn

On Fri, 21 Sep 2018, Samuel Tardieu wrote:

Libtool is in need of additional volunteers to serve as maintainers to
help catch up on the backlog of patches/issues and prepare another
release.


My question was solely about tagging and cutting a new release from the
current state of the repository 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://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Cut a new release?

2018-09-21 Thread Bob Friesenhahn

On Fri, 21 Sep 2018, Samuel Tardieu wrote:


Would it be possible to cut a formal release?


Libtool is in need of additional volunteers to serve as maintainers to 
help catch up on the backlog of patches/issues and prepare another 
release.


Are you able to volunteer to be a libtool maintainer?

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


Re: Apple OS ACL files in libtool distribution tarballs

2018-07-17 Thread Bob Friesenhahn

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'.

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/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Does libtool need to escape plus signs in egrep expressions?

2018-06-28 Thread Bob Friesenhahn

On Thu, 28 Jun 2018, Roumen Petrov wrote:

May be I misunderstand issue.

$ echo ' _head_ABC_a'  | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$'
 _head_ABC_a

$ echo ' _head_ABC_al'  | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$'
 _head_ABC_al

but:
$ echo ' _head__al'  | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$'
$ echo ' __head_ABC_al'  | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$'
$ echo ' _head_ABC_zl'  | egrep ' _head_[A-Za-z0-9_]+_[ad]l*$'




Are you sure this actually works?
I'm not expert in regular expressions but according above tests "plus" in RE 
works - see case _head__al .


It should match a run of alpha-numeric characters including 
underscores.  However, I do see that the expression includes a match 
of literal underscore and then there is a literal underscore so there 
might be something 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.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___
https://lists.gnu.org/mailman/listinfo/libtool


Re: What happened to libtool transitive DSOs?

2018-06-21 Thread Bob Friesenhahn

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. 
When a library which implicit library dependencies is linked, the 
libraries it depends on to successfully link are automatically added 
by the linker, but are not additionally recorded as dependencies.


The implicit dependencies (and explicit dependencies) are again used 
when the program is started by ld.so.


Using implicit library dependencies successfully is actually a bit of 
work 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 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


Re: What happened to libtool transitive DSOs?

2018-06-21 Thread Bob Friesenhahn

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


OS distributions where shared libraries provide robust implicit 
dependencies, and where pkg-config or other methods are used to obtain 
build options, do not like what libtool does.  They do not like that 
libtool adds libraries that the application/library did not explicitly 
link 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, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: What happened to libtool transitive DSOs?

2018-06-21 Thread Bob Friesenhahn

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 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
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: visibility support

2018-02-09 Thread Bob Friesenhahn

On Fri, 9 Feb 2018, Alexei Podtelezhnikov wrote:


Which LT_INIT option would enable the hidden symbol visibility support?


Libtool is all about supporting a core set of features in a portable way.


It is not about my use case, which I solved, it is about making
-fvisibility=hidden into a core Libtool feature. I will summarize and
never bother you again.


You make very good arguments.  The question remains as to who would 
implement this feature, test it, and assure that it gets in a libtool 
release?  Are you willing to take responsibility for this?  It is a 
lot of work, but libtool exists due to the effort of volunteers who 
were willing to do a lot of work.


There needs to be a fall-back mode on systems where the request can 
not be supported.  Luckily, the fall-back mode for this feature 
(simply ignore the request) is less draconian than the fall-back mode 
for the win32 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...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: visibility support

2018-02-05 Thread Bob Friesenhahn

On Fri, 2 Feb 2018, Alexei Podtelezhnikov wrote:


Dear all,

Which LT_INIT option would enable the hidden symbol visibility support?


There is no such thing in libtool as far as I am aware.  Libtool is 
all about supporting a core set of features in a portable way.


There is nothing to prevent 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://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Colons not escaped for setting LD_LIBRARY_PATH.

2018-02-02 Thread Bob Friesenhahn

On Fri, 2 Feb 2018, Philipp Thomas wrote:


The wrapper script created by ltmain 2.4.6 on Linux sets LD_LIBRARY_PATH as an
absolute path. Unfortunately it doesn't escape colons and the colon is the 
delimiter
for paths in LD_LIBRARY_PATH. So the exe doesn't find its library.

Could someone 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 Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: How can I get rid of the -L entry of LDLIBS from RPATH?

2017-08-03 Thread Bob Friesenhahn

On Mon, 31 Jul 2017, Krisztian Kovacs wrote:


Hi!

I haven't seen any examples how to set these script variables:
https://www.gnu.org/software/libtool/manual/html_node/
libtool-script-contents.html#libtool-script-contents
Can are they set per project?
If so, how?


All libtool script content is generated by 'configure' as described. 
In many cases, configure arguments may be used to set/override values 
(e.g. 'CC').  Many of these values may also be obtained from the shell 
environment in which configure is run.


A config.site script (e.g. /usr/local/share/config.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/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: ./libtool[1086]: eval: syntax error at line 1: `|' unexpected

2017-03-31 Thread Bob Friesenhahn

On Thu, 30 Mar 2017, Jeffrey Walton wrote:


If I am parsing things correctly, the "unexpected |" is due to a
missing command. Solaris is very Posixy, and I'm not sure which
command may be running afoul.


Parts of Solaris are very Posixy and other parts are not.  Unless 
things have changed in the past several years, the legacy /bin/sh 
shell is not very suitable for running configure or libtool.  On my 
Solaris 10 system, there is /usr/xpg4/bin/sh which tries to be more 
compliant (it is likely a link to ksh93 under Solaris 11), and bash is 
always available.  Configure 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.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: libtool support for LLVM's LLD linker

2017-03-21 Thread Bob Friesenhahn

On Tue, 21 Mar 2017, Ed Maste wrote:


On 9 January 2017 at 19:17, Ed Maste <ema...@freebsd.org> wrote:

I am (with a few others) trying to build all of the applications in
the FreeBSD ports tree using LLVM's LLD as the linker.


We've been making great progress linking software in the FreeBSD ports
tree with LLVM's LLD. Unfortunately, libtool is currently the largest
portability problem we're facing (in the context of LLD), and this now
applicable to LLD on at least other BSDs and Linux.

There's a proposal[1] to have LLD include "compatible with the GNU
linkers" in its version info so that libtool treats it like GNU ld /
gold. Going down this user-agent-alike path in toolchain components is
rather unfortunate, and I'd really like it if it can be avoided (at
least in the long term) by having libtool itself treat LLD as GNU ld.
For more information see the mailing list thread[2] that prompted this
patch.


What bad things happen if libtool does not decide that the linker is 
GNU ld?


Does the situation improve if --with-gnu-ld is supplied as an argument 
to configure?  If this causes things to work, then it is a way for the 
ports system to cure the problem 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 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


Re: Why does ltmain.sh::temp_rpath not need the same system lib considerations?

2017-02-16 Thread Bob Friesenhahn

On Thu, 16 Feb 2017, Nish Aravamudan wrote:


I do not believe so, the tests (heimdal self-tests) are run via a
Makefile target which calls the generated wrapper script(s).


Normally if you call the generated wrapper scripts, things should be 
ok, as long as the linkage was correct in the first place.



I really appreciate the response! From what I can tell, though, the
temp_rpath variable is not actually used to compile/link anything, it's
only used for the wrapper script generator. And I don't understand how
it would be correct for an explicit LD_LIBRARY_PATH specification (as
done by the wrapper generator) to have the system library path anywhere
before the end of the list. Otherwise, if any of the required library
dependencies are installed, the somewhat arbitrary set before the system
library path in LD_LIBRARY_PATH will use the built libraries and the
somewhat arbitrary set after the system library path in LD_LIBRARY_PATH
will use the system libraries without any indication of a problem -- and
it becomes rather murky what is actually being tested.


I don't think that it is normal or ok to have the system library path 
in the list at all.  Perhaps 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/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Why does ltmain.sh::temp_rpath not need the same system lib considerations?

2017-02-16 Thread Bob Friesenhahn

On Thu, 16 Feb 2017, Nish Aravamudan wrote:


I am trying to get to the bottom of an odd build failure on Ubuntu 17.04
with heimdal. I believe the underlying issue is a bug in libtool, but
I'm not confident in my analysis (some of it is also at
https://github.com/heimdal/heimdal/issues/241), but here's what I have,
I would appreciate any feedback!

Using the system sqlite3 (/usr/lib/x86_64-linux-gnu/) via configure, we
end up inserting the above path into LD_LIBRARY_PATH for build-time
generated wrapper scripts and since we also happen to have heimdal
libraries install at the system-level, the system heimdal libraries are
used by the tests instead of the build-local ones. This is bad for two
reasons: a) it fails in this case because of an ABI mismatch and b) we
are trying to test the built libraries, not the system installed ones
when the library in question is built by this package.


Do your test cases use

 ./libtool --mode=execute ./testprogram

or equivalent to assure that ./testprogram is executed with 
correct library paths?



It seems like there is rarely, if ever, a case to put a system library
path before a non-system library path in the wrapper script, and in
particular, it seems like ltmain.sh actually detects adding the system
path to compile_rpath and finalize_rpath. Is it correct to do the same
elision in temp_rpath? e.g.


Without studying the details, it is worth noting that other software 
delivering libraries does manage to successfully test the uninstalled 
libraries even if installed libraries are present.  For operating 
systems where this is deemed not possible (or which hard code paths to 
the libraries used), libtool builds with hard-coded run-paths and then 
re-links at install time.


Problems could still occur if a library used has a hard-coded run path 
baked into it so that the undesired directory is still used.


Problems could also accur if libraries are linked in the wrong order 
(e.g. building/linking in the wrong order in a recursive build) or 
with wrong paths such that a system library was used.


I am definitely 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.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Linking against static libraries in Windows (MSYS)

2016-06-27 Thread Bob Friesenhahn

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 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.


I failed to mention that there is something about MinGW which does 
make things different.  Windows DLLs do not allow undefined symbols so 
you may be forced to build your library 'B' as a DLL in order for 
library 'A' to sucessfully link.


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


Re: Linking against static libraries in Windows (MSYS)

2016-06-27 Thread Bob Friesenhahn

On Mon, 27 Jun 2016, Alex wrote:


$ ./configure --disable-shared --enable-static --prefix=/usr
$ make && make install

But when I build *A* afterwards the following warning appears:

*** Warning: This system can not link to static lib archive /usr/lib/
libogg.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

Has anybody come across this? Is there any known fix or workaround?


This is a common problem, which is not specific to MinGW or MSYS.

The two possible solutions are to either arrange to link with 
'B' while linking any application which depends on 'A', or else build 
'B' as libtool convenience library so that all symbols from 'B' now 
become part of 'A'.


Since in this case, the user may not expect symbols from libogg to be 
part of library 'A' (and perhaps multiple libraries similar to 'A' may 
also want to link with it), I doubt that the libtool convenience 
library approach is the correct one here.  Duplicate symbols due to 
mutual dependence need to be avoided.


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 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,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: How to make a C++ -module?

2016-06-21 Thread Bob Friesenhahn

On Tue, 21 Jun 2016, Robert Boehne wrote:


Patrick,

Did you build the compiler yourself?  Basically Libtool is saying you only
have a static version of your runtime library, so if you built the compiler
yourself, add --enable-shared when you configure.  If not, I'll see if I
can get a NetBSD VM up and running so I can reproduce your problem, but at
first glance it appears to be your compiler.


I am only seeing a static libgcc.a for my own GCC builds for Solaris 
and also for the GCC provided by Ubuntu.


To me the -lgcc seems suspect.  If it is really needed then libtool 
would need 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/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: How to make a C++ -module?

2016-06-21 Thread Bob Friesenhahn

On Tue, 21 Jun 2016, Patrick Welche wrote:


I'm trying to create a C++ loadable module. I thought it would be as easy
as:


[ stuff removed ]


This fails with:

/bin/sh ./libtool  --tag=CXX   --mode=link g++  -g -O2 -module -avoid-version  
-o hellow.la -rpath /usr/local/lib hellow.lo

*** Warning: linker path does not have real file for library -lgcc.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libgcc and none of the candidates passed a file format test
*** using a regex pattern. Last file checked: /usr/lib/libgcc.a

Presumably, this means that things aren't as simple as I thought.
What am I missing?


Nothing is easy when it comes to C++-based modules.  Risks are 
elevated if a C-based program uses C++-based modules due to unhandled 
C++ exceptions or C++ exceptions possibly not working.


You are going to need a shared library for the (correct) C++ run-time 
as well as libgcc_s.so.  These need to somehow appear where libtool is 
searching for them.  They will also need to be available in a path 
where the system searches for shared libraries in order to load the 
module.



# Dependencies to place before and after the objects being linked to
# create a shared library.
predep_objects="/usr/lib/crti.o /usr/lib/crtbeginS.o"
postdep_objects="/usr/lib/crtendS.o /usr/lib/crtn.o"
predeps=""
postdeps="-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc"


I am not sure what libgcc is used for.  It seems to only ever be 
delivered as a static library in the GCC installation tree.  Its 
appearance 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


Re: How to build libtool from git sources properly?

2016-05-18 Thread Bob Friesenhahn

On Wed, 18 May 2016, Igor Zhbanov wrote:


run `./bootstrap`
-mike


It doesn't work on a PC without git or without network connection
because it needs to clone gnulib (although there is no gnulib folder
in libtool-2.4.6.tar.gz. But this is probably another story.


This is very unfortunate.  I am not sure if it would work if you 
cloned gnulib on another computer and copied the gnulib folder into 
place since it may still make subsequent git accesses.


The bootstrap requirements make it difficult to support or test on 
targets which can not run git or don't have network access.


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


Re: Libtool not creating version info symlinks during make install

2016-03-13 Thread Bob Friesenhahn

On Sun, 13 Mar 2016, mar...@saepia.net wrote:



I have found out that libtool script in the broken library generated while 
running ./configure --prefix
/root/cerbero/dist/android_armv7 --libdir /root/cerbero/dist/android_armv7/lib 
--disable-maintainer-mode
--disable-silent-rules --disable-introspection --host=arm-linux-androideabi has 
version_type=none while one that
builds has this variable properly set to linux. That difference later causes 
libtool to not add symlinks.

Can anyone here give me any hint where should I seek for what causes invalid 
host recognition while generating
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/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: libtool-ltdl-devel

2016-03-01 Thread Bob Friesenhahn

On Tue, 1 Mar 2016, Sam Knuijver wrote:


Hello,
how do I download libtool-ltdl-devel ?
I want to install it from source since I can't apt-get it on Ubuntu 15.04
thanks


The original source code may be downloaded from 
"ftp://ftp.gnu.org/pub/gnu/libtool/;.  This might not be the 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.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: MSW DLLs support in libtool

2016-02-12 Thread Bob Friesenhahn

On Fri, 12 Feb 2016, Evgeny Grin wrote:


option is NOP for anything except W32 and AIX.
Moreover, if it does matter only for W32 and AIX, let's rename it to
"-w32-aix-shared-compatible". And add more flags, like
"-linux-compatible", "-open-bsd-compatible". This will signal libtool
that developed checked compatibility of build system with specific OS.


We don't do this sort of thing since we have no control over the 
future and don't know what the future will bring.  So we use generic 
options.  If we try to guess what the future may bring then we may 
guess wrong and someone will take us to task about our bad decisions.


For AIX, there is a build mode where shared libraries are more like 
GNU Linux and not like DLLs.



Anyway, what's drawback of assuming "-no-undefined" on W32 and AIX (or
on all platforms)?


As previously explained, it is more likely to lead to compilation 
success for packages which have not been crafted/tuned to succeed on 
targets where -no-undefined makes a difference.


A core Autotools principle is that the person compiling the software 
should be in control as much as possible.  This 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/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: MSW DLLs support in libtool

2016-02-11 Thread Bob Friesenhahn

On Thu, 11 Feb 2016, Evgeny Grin wrote:


Repeat once more: with OS-specific code parts you can't add
"-no-undefined" unconditionally.


GraphicsMagick (which compiles on a wide variety of systems, including 
Windows and AIX) has been specifying -no-undefined as a standard 
option (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.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: MSW DLLs support in libtool

2016-02-11 Thread Bob Friesenhahn

On Thu, 11 Feb 2016, Evgeny Grin wrote:


On 10.02.2016 18:51, Nick Bowler wrote:

The default (on all platforms) is to create both static libraries and,
when possible, shared libraries.

This statement is ether not correct or incorrectly documented.
Currently "configure --help" show those lib options by default:
 --enable-shared[=PKGS]  build shared libraries [default=yes]
 --enable-static[=PKGS]  build static libraries [default=yes]

There is not "=auto" option for shared or static versions. Only "yes" or
"no".
So, it's explicitly specified 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.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: MSW DLLs support in libtool

2016-02-10 Thread Bob Friesenhahn

On Wed, 10 Feb 2016, Evgeny Grin wrote:


As result - "-no-undefined" is used only on W32 without any practical
benefit: if lib have some undefined symbols, it will not be build on W32
as shared lib regardless of "-no-undefined" flag. And conditionally used


The "-no-undefined" option is not actually Win32 specific.  IBM's AIX 
has build configurations which benefit from it.


Also, "-no-undefined" does not indicate if the library has undefined 
symbols (many DLLs have undefined symbols).  It indicates that the 
build configuration has agreed to 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/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: MSW DLLs support in libtool

2016-02-09 Thread Bob Friesenhahn

On Tue, 9 Feb 2016, Nick Bowler wrote:


In retrospect, the default (assume undefined symbols are possible) was
probably a bad choice, because undefined symbols in libraries are rarely
used.  Thus, almost all libraries need to specify -no-undefined.  But
this can't be changed now without causing regressions.


This is not really true.  For example, the linker on GNU Linux 
implicility supplies libraries at link time (because of how they were 
built) and libtool has no way to know about library dependencies which 
are not listed in .la files.


Some GNU Linux distributions intentionally 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/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re[2]: MSW DLLs support in libtool

2016-02-09 Thread Bob Friesenhahn

On Wed, 10 Feb 2016, Vadim Zeitlin wrote:


Sorry but this is just not true for the MSW DLLs. If the libtool user
tries to build a DLL, you can safely assume that it will not have undefined
symbols. Anything else just doesn't make sense because it would always
result in an error. Again, this is different from the traditional Unix
shared libraries.


Why do you say this?  Most software built using libtool still comes 
from Unix type systems.  Without the existing behavior it would be 
difficult to take a program developed on a Unix type system and just 
compile it under Windows.  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/listinfo/libtool


Re: Libtool does not generate shared libraries when cross compiling x86/64 -> sparc64 using fujitsu compiler

2016-02-06 Thread Bob Friesenhahn

On Fri, 5 Feb 2016, Harald Servat wrote:


I'm unsure on how to interpret the libtool related information because it is 
very simplistic


configure:11699: checking if libtool supports shared libraries
configure:11701: result: no

however, at some point earlier, the following test might be related

configure:8998: checking whether the fccpx linker (sparc64-linux-ld -m 
elf64_sparc) supports shared libraries

configure:10069: result: no

Can we provide some additional info or run additional tests to improve 
libtool on this system?


The generated config.log file contains detail information regarding 
the tests performed and error messages produced.  Looking there is the 
next step.


The '-print-search-dirs' error message is because libtool attempted to 
treat the compiler like GCC and obtain its default linker search path.


It is unfortunate if Fujitsu does not care to contribute.  If that is 
indeed true, then that would be their loss since a large portion of 
free software packages use Autotools (including libtool) and these 
packages won't compile as effectively if the target is not supported. 
Fujitsu's system would be barren of commonly available 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/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: how to make libtool use stdlib

2015-09-08 Thread Bob Friesenhahn

On Tue, 8 Sep 2015, Andy Falanga (afalanga) wrote:


I'm working on a library which may need to link with the standard libraries (I assume 
since -nostdlib would seem to indicate that it's *not to* link with standard libraries).  
I say this because of discussions I've come across making mention that using 
"-nostdlib" has adverse side effects with pthreads.  I'm using a library, 
log4cplus, which does make use of pthreads.

Using "./configure --help" doesn't reveal any method of making libtool discontinue the 
use of "-nostdlib".  How 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/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: cross-compiling with libtool

2015-05-14 Thread Bob Friesenhahn

On Thu, 14 May 2015, Lane wrote:

That's what I don't understand. I do have a ranlib binary and it is 
named by the cross-tools environment that I've been given. For some 
reason it's not able to find it though when running make install and 
I don't know how that happens.


Are you running 'make install' as a different user than the user who 
did the build?  If so, the PATH, LD_LIBRARY_PATH, or the ability to 
execute the binary may be different.  Check the PATH, LD_LIBRARY_PATH, 
and the permission bits on the executable.  If this 'ranlib' is a 
script rather than a true binary (not uncommon for transplanted 
cross-tools), then check its first line to see if the shell it 
requests is valid and allows execution by that user.


Lastly, the toolchain binaries might be a different architecture than 
the native architecture for your machine.  For example, they might be 
i386 and/or x86-64.  If the user id, PATH, or LD_LIBRARY_PATH, 
changes, perhaps this is causing binaries not to be runnable any more. 
I have seen cases before where binaries for a different architecture 
were treated as if they were not programs at all until the framework 
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


Re: cross-compiling with libtool

2015-05-13 Thread Bob Friesenhahn

On Wed, 13 May 2015, Lane wrote:

arm-blues-linux-gnueabi-libtool: install: chmod 644 
/opt/blues/lib/libbl_parsers.a
arm-blues-linux-gnueabi-libtool: install: arm-blues-linux-gnueabi-ranlib 
/opt/blues/lib/libbl_parsers.a
../../../arm-blues-linux-gnueabi-libtool: line 1104: 
arm-blues-linux-gnueabi-ranlib: command not found
Makefile:395: recipe for target 'install-libLTLIBRARIES' failed

Any thoughts on how to proceed?


1. Assuming that you want to make progress with your work.

2. Assuming that your other cross-tools are named prefixed with
   'arm-blues-linux-gnueabi-'.

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
--
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


Re: Running an uninstalled executable

2015-05-12 Thread Bob Friesenhahn

On Tue, 12 May 2015, Alberto Luaces wrote:


Hello,

in an autoconf+automake+libtool C++ project containing only one program,
I want to run the executable before installing it.

Reading the manual I thought that it could be done with

libtool --mode=execute program_binary

but it fails, since there are undefined references to shared libraries
not installed in standard directories.

Can libtool solve this problem for me?


Libtool is supposed to solve this problem automatically for libraries 
in the build-tree built using libtool, or involved libraries which 
have a correct associated .la file.  It is not uncommon for the .la 
files that libtool installs to be deleted, or for libraries to be put 
into a location other than the paths the .la file says they reside.


If the installed libraries violate the libtool expectations, then 
there are only the choices of building the 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
--
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


Re: libtool is not wanting to play nicely with cross compiler

2015-04-07 Thread Bob Friesenhahn

On Mon, 6 Apr 2015, Andy Falanga (afalanga) wrote:

I'm working on compiling some code for an ARM processor on a Xilinx 
board.  I did not do the work of configuring the cross compiler and 
so am ignorant about some parts of this process.


I recommend reading the Autoconf manual as pertains to 
cross-compilation.


How are your cross-tools named?  Tool naming is important.

What are the arguments that you passed to configure?

I've finally gotten my configure script to complete and was running 
the main compilation when I ran into this error:


libtool: link: warning: 
`/src/afalanga/crisscross/tmp/sysroots/zc706-zynq7/usr/lib/libstdc++.la' seems 
to be moved
libtool: link: warning: 
`/src/afalanga/crisscross/tmp/sysroots/zc706-zynq7/usr/lib/libstdc++.la' seems 
to be moved
libtool: link: warning: 
`/src/afalanga/crisscross/tmp/sysroots/zc706-zynq7/usr/lib/libstdc++.la' seems 
to be moved
/bin/grep: /usr/lib/libstdc++.la: No such file or directory
/bin/sed: can't read /usr/lib/libstdc++.la: No such file or directory
libtool: link: `/usr/lib/libstdc++.la' is not a valid libtool archive


The .la files are just text files which libtool uses to remember build 
information to be re-used when using the associated library.  The 
complaint about being moved is because these files are located in a 
different place than when they were originally installed (by whoever 
built/packaged them).  The .la file contains paths which are not 
correct for your current library installation.


libtool is pointed in the right direction because the file 
libstdc++.la, in the directory indicated, is the one it should be 
using for cross compilation.  However, the file contains this:


libdir='/usr/lib'

I know this is the source of the warning, but why would I be getting 
the warning?  If my understanding is correct, the stuff in this 
directory is made into the image what it placed onto the embedded 
system.  Thus, when that OS is running, libstdc++.la would actually 
be in '/usr/lib'.


However, it seems that libtool decides that it will look in 
'/uar/lib' for libstdc++.la anyway and ignore that it found the file 
where it was told it would.  Well, just as is indicated, there isn't 
a libstdc++.la file in '/usr/lib'.  How do I make libtool happy with 
the la archive (is that what they're called) that it should be 
using?


Libtool does work for cross-compilation mode but tools must be named 
appropriately, autoconf arguments must be supplied appropriately, and 
the build toolchain needs to be smart enough to use its own sysroot 
for cross-compilation rather than accidentally using host 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.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: argument list too long error

2015-03-26 Thread Bob Friesenhahn

On Wed, 25 Mar 2015, Vincent Torri wrote:


Is this log file sufficient ?


Yes, because it shows that the problematic arguments were passed to 
libtool's command line, and not produced internally by libtool.


Perhaps the repetitions were produced by a improperly constructed 
configure script, 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 Mar 2015, Vincent Torri wrote:

also it seems that on Linux, it's not the case (no such long list of
arguments), while on Windows, it is. So maybe a problem in the 
Windows
port of libtool


  The only way to know this is if we could see the arguments which were 
passed to libtool, but you did not provide
  this to us.  Are the duplicate arguments passed to libtool?

  Windows has a vastly smaller command line limit than Linux does, and the 
Windows command-line limit is combined
  with environment variable space so more environment variables decreases 
the command-line length limit.

  Bob
  --
  Bob Friesenhahn
  bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
  GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/






--
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


Re: argument list too long error

2015-03-25 Thread Bob Friesenhahn

On Wed, 25 Mar 2015, Vincent Torri wrote:


hello,

In a project i'm following, i've seen that bug report:

https://phab.enlightenment.org/T2225

The build system pass a huge number of identical options and libtool does not 
try to remove them

is it a problem with libtool (that is, libtool should indeed remove such 
identical options) or in the build system (that is,
we should optimize the build system so that non identical options are passed) ?


The URL you posted requires a login.  Are you able to provide an 
example or summarize the problematic identical options here?


Libtool 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/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: argument list too long error

2015-03-25 Thread Bob Friesenhahn

On Wed, 25 Mar 2015, Vincent Torri wrote:


also it seems that on Linux, it's not the case (no such long list of
arguments), while on Windows, it is. So maybe a problem in the Windows
port of libtool


The only way to know this is if we could see the arguments which were 
passed to libtool, but you did not provide this to us.  Are the 
duplicate arguments passed to libtool?


Windows has a vastly smaller command line limit than Linux does, and 
the Windows command-line limit is combined with environment variable 
space so more environment variables decreases the command-line length 
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


Re: GNU libtool-2.4.6 released [stable]

2015-03-23 Thread Bob Friesenhahn

On Mon, 23 Mar 2015, Christian Rössel wrote:


Dear Gary,

thanks for libtool-2.4.6!

I discovered some files in 
http://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz that IMO don't belong 
there. The filenames start with ._ (just do a 'find . -name ._*') and 
seem to contain dropbox meta data.


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 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


Re: Bash-specific performance by avoiding sed

2015-03-09 Thread Bob Friesenhahn

On Mon, 9 Mar 2015, Mike Gran wrote:


Hello libtool,

I don't know if y'all saw this blogpost where a guy pushed
the sed regular expression handling into bash-specific
regular expressions when bash was available.  He claims
there's a significant performance improvement because of
reduced forking.

http://harald.hoyer.xyz/2015/03/05/libtool-getting-rid-of-18-sed-forks/


There is an issue in the libtool bug tracker regarding this.

This solution only works with GNU bash.  It would be good if 
volunteers could research to see if there are similar solutions which 
can 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


Re: Performance issue of libtool-2.4.4

2015-02-06 Thread Bob Friesenhahn

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 system using -j 
12:


I think that we can't see obviously slowdown by make -jN,
but make -j1 will. And bash is much slower than dash, I'm trying to
figure out why.


It seems like this issue is already corrected in the source tree but 
you are correct that the issue is much more apparent with -j1.


Optimized:

  2.4.2 : 3:43.43
  2.4.5 : 4:33.11

Non-Optimized:

  2.4.2 : 1:21.21
  2.4.5 : 2:05.48

We need a test case which is executed before every major release to 
make sure that a performance regression has not been introduced.


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


Re: Performance issue of libtool-2.4.4

2015-02-05 Thread Bob Friesenhahn
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 
system using -j 12:


2.4.2 : 23.613
2.4.3 : 31.697
2.4.4 : 28.236
2.4.5 : 28.514

And here are timings for a non-optimize (-O0) compile with no debug 
symbols:


2.4.2 :  8.629
2.4.3 : 13.216
2.4.4 : 13.012
2.4.5 : 13.281

I see similar slowdowns on an Illumos-based system, so it is not 
specific to GNU/Linux.


It is curious that there is more impact for the optimized builds.

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


Re: Performance issue of libtool-2.4.4

2015-02-04 Thread Bob Friesenhahn

On Wed, 4 Feb 2015, Robert Yang wrote:


When reporting a bug, please describe a test case to reproduce it and
include the following information:

  host-triplet:   $host
  shell:  $SHELL
  compiler:   $LTCC
  compiler flags: $LTCFLAGS
  linker: $LD (gnu? $with_gnu_ld)
  version:$progname (GNU libtool) 2.4.5
  automake:   `($AUTOMAKE --version) 2/dev/null |$SED 1q`
  autoconf:   `($AUTOCONF --version) 2/dev/null |$SED 1q`


Perhaps libtool is accidentially executing 'automake --version' and 
'autoconf --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/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Performance issue of libtool-2.4.4

2015-02-03 Thread Bob Friesenhahn

On Tue, 3 Feb 2015, Robert Yang wrote:


Sorry, I was wrong, tt seems that libtoolize is not the key, but libtool,
when compile cairo-1.12.18:

libtool 2.4.2   libtool 2.4.5
configure:  31s 32s
compile:54s 64s

The libtool 2.4.5 costs 10 more seconds. I'm debugging on it, any suggestion
is appreciated.


The build slowdown must not be my imagination then.  I had attributed 
the slowdown to other factors.  Recently I noticed that build times 
for my own project were significantly longer than I remember.


Previously libtool was heavily optimized to reduce the number of forks 
(execution of child process).  This optimization should still be 
present in 2.4.2.  Any additional forks will result in a slower build.


It is not necessary to libtoolize a package in order to test its build 
performance with different libtool versions.  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.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Performance issue of libtool-2.4.4

2015-02-02 Thread Bob Friesenhahn

On Mon, 2 Feb 2015, Robert Yang wrote:



Hello libtool,

It seems that libtool (2.4.4) has increased the packages build time, after
a rough investigation, it maybe because new libtoolize needs run a m4
command:


Did you time 'libtoolize' and compare the timings with 2.4.4 to the 
release 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/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: lt_dlopen no return

2014-12-15 Thread Bob Friesenhahn

On Mon, 15 Dec 2014, Orc Erc wrote:


Hi All,
When i called the lt_dlopen function, it sticks.  There is no return from that 
function.

Where do i look?


Run your program under a debugger such as GDB.  While it is stuck, do 
CONTROL-C on the keyboard and then then enter 'bt' at the GDB 
command-line.  This should show where it is stuck.


An alternative is to make sure that core dumps are properly enabled 
and then do


  kill -QUIT pid

where pid is the process ID of the stuck process.  You should then get 
a core dump of the program that you can investigate using a debugger.


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.GraphicsMagick.org/___
https://lists.gnu.org/mailman/listinfo/libtool


Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec

2014-12-05 Thread Bob Friesenhahn

On Wed, 5 Mar 2014, Orion Poplawski wrote:


Use ldconfig to generate sys_lib_dlsearch_path_spec so that internal library
search paths as well as all /etc/ld.so.conf and /etc/ld.so.conf.d/*.conf
entries are present.


It seems unwise to use ldconfig output as authoritative information 
since 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
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory

2014-12-02 Thread Bob Friesenhahn

On Tue, 2 Dec 2014, Filipe Brandenburger wrote:



I don't think that linking against libraries in DESTDIR is portable. DESTDIR
should be considered an install/copy-only option to support packaging.


Well, in my use case I'm often/usually cross compiling so having the
final libraries installed under /usr/lib is not really an option... It
seems that lt_cv_sys_lib_dlsearch_path_spec solved the issue for me,
but I'm not 100% positive how portable that is, if you can think of
some reasons why this is not a good fix and if there's a cleaner way
to accomplish this then please let me know.


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/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory

2014-11-28 Thread Bob Friesenhahn

On Fri, 28 Nov 2014, Gary V. Vaughan wrote:


Also, the use of -rpath is fairly deeply ingrained into the way that
automake generated rules call libtool, so if you want to tackle a complete
patch, there will be at least some work there too.

I suspect that there is a fairly good chance that the -rpath requirement came
about because some supported architectures refuse to build shared libraries
without it, but I have access to only a tiny fraction of the architectures that
libtool supports so I can't test my hypothesis.

All of that said, I do agree that it is a bug for libtool not to respect
the value of $DESTDIR when it assembles the rpath directories.  I would think
a patch should be relatively straight forward though - find the parts of
ltmain.in that assemble the link line with the rpath directories, and strip
out any $DESTDIR prefixes from those paths before handing off to the linker.


I really think libtool should be creating a wrapper script and not a
binary with an rpath pointing to the stage directory, am I wrong?


No, I agree with you.


I am not sure what OS is being discussed here since it was never 
mentioned.


GNU ld on GNU/Linux has these options:

  -rpath PATH Set runtime shared library search path
  -rpath-link PATHSet link time shared library search path

Notice that one is the path used for the installed library and the 
other is for linking.  It is more correct to use -rpath-link for 
libraries which are not in their final resting place.  However, the 
libraries do remember the -rpath-link option which was used when they 
were linked, and libraries linked with them inherit the option (to 
support cascading linkage).


Some systems hard code the linker run-time path and this may be 
necessary in order for libtool to support executing built uninstalled 
binaries for testing.  That is why libtool supports a 'finish' mode so 
make sure that finally installed executables contain the correct 
embedded path information.


I don't think that linking against libraries in DESTDIR is portable. 
DESTDIR should 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/listinfo/libtool


Re: [RFC] any critical patches for a release this weekend?

2014-10-27 Thread Bob Friesenhahn

On Mon, 27 Oct 2014, Gary V. Vaughan wrote:


Bob, in light of both that and of your disappointed something is 
better than nothing response, I figured a fearless release from 
master not only saves us from getting back into the maintaining 
several HEADs hell we've been in before, but also gives 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://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: when linking on Solaris 64bit shared object using cc, -m64 should be used

2014-06-10 Thread Bob Friesenhahn

On Mon, 9 Jun 2014, Petr Sumbera wrote:


Hi,

I'm often getting following error:

/usr/apr/1.5/build/sparcv9/libtool --silent --mode=link cc -o mod_dtrace.la
-rpath /usr/apache2/2.2/libexec/sparcv9 -module -avoid-version
mod_dtrace.lo
ld: fatal: file .libs/mod_dtrace.o: wrong ELF class: ELFCLASS64
apxs:Error: Command failed with rc=131072

Attached patch fixes the issue.


Normally such options should already be included in CFLAGS (or 
sometimes works better in CC).  All of the software needs to be 
compiled with the same -m64 option.


When compiling using the Sun compiler and targeting 64-bits, I 
configure using something like


  ./configure 'CC=/opt/SUNWspro/bin/cc -m64' ...

Libtool is not multilib capable under Solaris.  That is, it does not 
automatically install a library into an architecture-specific 
subdirectory or search there either.  You might notice that the system 
does support different directories (e.g. '/lib/32', '/lib/64', 
'/lib/amd64') and GCC is multilib capable, putting its own 64-bit 
libraries in an architecture-specific subdirectory.


For my own 64-bit compiles under Solaris, I use a different 
installation prefix in order to make sure that 32-bit and 64-bit 
libraries/includes are sane.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: when linking on Solaris 64bit shared object using cc, -m64 should be used

2014-06-10 Thread Bob Friesenhahn

On Tue, 10 Jun 2014, Petr Sumbera wrote:

And finally I was uncertain with CC=cc -m64. It appeared to me as something 
what can cause some troubles and should be rather avoided.


In my experience, this has worked best for Solaris.  Libtool uses CC 
(or CXX in the case of C++) for linking.


Until such time that libtool implements proper multilib support, this 
seems like the most reliable solution.


It would be wrong for libtool to incorporate a partial solution.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/



Re: -no-undefined on Win32

2014-04-28 Thread Bob Friesenhahn

On Mon, 28 Apr 2014, Evgeny Grin wrote:


Good. But requiring -no-undefined for Win32 flag lower probability of 
successful compile.


In what way does it lower the probability of a successful compile? 
Static linkage is much more portable than dynamic.


The situation you outlined is due to a defective package 
preparation/build environment.  A proper build has just one version of 
a given library in a link.


Regardless, it is very unlikely that libtool will react to your plea 
(if it does at all) in a timely fashion and so you are best advised to 
fix your build without relying on significant changes in libtool.


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


Re: -no-undefined on Win32

2014-04-19 Thread Bob Friesenhahn

On Fri, 18 Apr 2014, Evgeny Grin wrote:



Libtool always defaults to successful compilation and link, to the
maximum extent possible.


That's nice, leave it to compiler and linker. If something can be compiled and 
linked, it will be compiled and linked. If it can't be, then compiler or linker 
will fail. Why giving up before even try?


The GNU/Autoconf philosophy has always been that if software 
configures successfully that there should be a very high probability 
that the sofware will compile and work.  Success at compiling on 
several platforms should indicate that it is highly likely to also 
compile on other platforms (including platforms that the package 
authors don't have access to).


If the software fails to compile, or fails to work, there is 
substantial possibility that the user won't know how to solve the 
problem.


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


Re: (almost) silent creation of static lib instead of dynamic linked lib

2014-04-18 Thread Bob Friesenhahn

On Thu, 17 Apr 2014, Evgeny Grin wrote:


Hi!

Libtool always build static lib if dynamic lib can't be created.
This behavior is inconsistent with other build tools. For example if GCC can't 
compile something, it fail with error.
If I need a shared lib, this doesn't mean that static lib will satisfy me.
When I run configure with --enable-shared (or shared enabled by default), I expect that 
make will build shared lib or fail with error.


Did you try using --disable-static?  Enabling building shared 
libraries is not the same as disabling building static libraries.


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


Re: -no-undefined on Win32

2014-04-18 Thread Bob Friesenhahn

On Thu, 17 Apr 2014, Evgeny Grin wrote:


Hi,

It's strange for me that last line in following qoute from ltmain.in is 
commented out:
---
 # It is impossible to link a dll without this setting, and
 # we shouldn't force the makefile maintainer to figure out
 # what system we are compiling for in order to pass an extra
 # flag for every libtool invocation.
 # allow_undefined=no
---

Almost all project ported to Win32 already have -no-undefined options, but 
this always add more headache on porting to Win32.
If lib contains some undefined symbol, then dll will not be created regardless of using 
-no-undefined.
If lib doesn't contain any undefined symbols, then dll can be created so why forcing use 
-no-undefined?


Why does it create more headache when porting to Win32?  Using this 
option indicates that the project has been constructed in a way which 
will work on systems which do not allow undefined symbols.  Many 
projects (particularly those targeting only GNU/Linux because it is a 
popular operating system) are not suitably constructed and require 
adaptation.


Libtool always defaults to successful compilation and link, to the 
maximum extent possible.


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


Re: Forced static lib if any depend lib is static on win32

2014-04-18 Thread Bob Friesenhahn

On Thu, 17 Apr 2014, Evgeny Grin wrote:


Hi!

Win32 libs is forced to be static if any dened lib is not shared.
If it's done to prevent symbols conflicts on several shared libs with same static lib. 
But if DEF file is used or dllexport function attribute is used, ld will not export 
functions from static lib if no --export-all-symbols is specified. Same with 
-fvisibility=hidden on non-Win32 platforms.
Usually on Win32 libs are distributed in binary form and dll hell is a problem 
for projects with many depends libs as for example almost every lib use 
zlib.dll, but different zlib.dll is not abi compatible. So it can be wise to 
statically link libs for some shared lib.
Is it possible to support such configuration in libtool?


For Win32 builds on my Windows system, I see that it is normal for 
DLLs to be named according to the major interface number.  For 
example, zlib (not created using libtool) is named zlib1.dll and 
libltdl (created using libtool) is named libltdl-7.dll.  This is not 
as convenient as ELF versioning, but does prevent disaster.  Why is 
this not the case for your system?


Libtool convenience libraries do support DLL exports but this is 
because libtool built them and so it knows how they are built.  In 
fact, libtool convenience libraries are not used like libraries at all 
and are simply a convenient reference to a collection of object files 
wrapped in an archive.


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


Re: AM_LDFLAGS += -no-undefined

2014-04-08 Thread Bob Friesenhahn

On Tue, 8 Apr 2014, Akim Demaille wrote:


Hi all,

My project builds many libraries and some modules.  I've just started
using ltdl in it, with a non-recursive build.  As a result,
I have inherited the following line in my single Makefile:

AM_LDFLAGS += -no-undefined

so my libraries now fail to link.  Is this on purpose?
Shouldn't this flag be for libltdl only?  I have not seen
information about this in the documentation, but I might
have not looked correctly (I looked at occurrences of
-no-undefined and LDFLAGS).


This option is necessary in order to build DLLs under Windows (and 
likely shared libraries under AIX).  It expects a commitment to supply 
all dependency libraries at library/module link time.  You could edit 
the copy of libltd/Makefile.inc in your project if it causes an issue 
for you but there may be consequences for platforms which need it.


GraphicsMagick uses a non-recursive build and used to build libltdl as 
part of the build (for at least 8 years).  Even though ltdl added 
-no-undefined it was not a problem since GraphicsMagick was 
intentionally using this option.


Since then, I realized that building libltdl as part of the project 
was prohibitive, costly, and dangerous.  It was better to rely on 
libltdl to be a formally installed dependency on the system.  Now 
GraphicsMagick treats libltdl just like any other external library and 
life is much improved.  I would encourage any other package to not 
bundle libltdl and to simply document that it must already be 
installed on the system.


Perhaps it would be wise for libltdl to be unbundled from libtool 
itself and libltdl become a separate project.  They would still have a 
relationship but then it would be easier to install libltdl.


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


Re: AM_LDFLAGS += -no-undefined

2014-04-08 Thread Bob Friesenhahn

On Tue, 8 Apr 2014, Gary V. Vaughan wrote:


Hi Bob; Salut Akim,

On Apr 8, 2014, at 9:28 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us 
wrote:

Perhaps it would be wise for libltdl to be unbundled from libtool itself and 
libltdl become a separate project.  They would still have a relationship but 
then it would be easier to install libltdl.


Agreed. But it's not straight forward because of the codependence of ltmain.sh 
and libltdl.


It is definitely all intertwined.  In fact, libtool's own m4 and 
script code is currently subordinate to libltdl for purposes of 
sharing.



Unfortunately, I don't even have the time to finish the next release at the 
moment =(O|


Time is a precious resource that few of us of much of these days.

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


Re: AM_LDFLAGS += -no-undefined

2014-04-08 Thread Bob Friesenhahn

On Tue, 8 Apr 2014, Akim Demaille wrote:


Since then, I realized that building libltdl as part of the project 
was prohibitive, costly, and dangerous.  It was better to rely on 
libltdl to be a formally installed dependency on the system. Now 
GraphicsMagick treats libltdl just like any other external library 
and life is much improved.  I would encourage any other package to 
not bundle libltdl and to simply document that it must already be 
installed on the system.


What do you mean by dangerous?  In case of mixture of versions I guess?
This is probably a problem for libraries that likely to be linked in
a program that links with even more libraries.


Libltdl is likely managed by a package manager on the system since it 
is a common component on any GNU/Linux system and other free systems. 
By embedding libltdl in some other application or library, the users 
of that application or library may overwrite the libltdl installed by 
the package manager.  The configure options to manage this are 
confusing.



And for prohibitive and costly, I'd be happy too to have some details :)
It's not too big, and very fast to build (compared to the remainder
of my severely-templated C++ libraries, it is perfectly negligible).


The ltdl configure script bits take a long time to run and make the 
configure script larger.  With the recursive build, the build time is 
not worth worrying about.


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


Re: pkg-config and static builds

2014-03-03 Thread Bob Friesenhahn

On Mon, 3 Mar 2014, Werner LEMBERG wrote:


it seems it has been already discussed that libtool should use a
different set of link flags if compiling a static library, especially
for libraries that come without a corresponding `.la' file, cf. this
thread:

 http://lists.gnu.org/archive/html/automake/2009-05/msg00068.html

Such a feature would be useful in combination with `pkg-config', which
has the `--static' command line option to give such a different set.

What's the current state?  As an example, let's assume that my library
uses libpng.  If I'm going to statically link to it, I need to add
`-lz' and `-lm'.  From where do I get this information for static
linking if I want to use libtool for building my own library?  I've
read that it would be better to not specify `-lz' and `-lm' while
building a shared library to avoid built-in references.


If the libary.la files are deleted, then you are on your own and your 
configure script can only make an educated guess based on experience 
and test those guesses.  Guessing may be improved by using pkg-config 
(manually as you describe).  Depending entirely on pkg-config is not 
wise since it is an add-on which is not part of the autotools 
framework and not uniformly maintained.  If an end user installs his 
own libraries from source code (GNU still wants to support using 
source code), then the pkg-config information may not be correct for 
the end-user's build.


Nothing has changed in libtool since the discussion you refer to.

Static libraries do not have implicit dependencies (without benefit of 
the .la files) and they do not support library dependency versioning 
either.  Static libraries are normally linked directly into the 
application being built and not into other libraries.  Dependencies 
must be fully specified in order to avoid linkage failure.  This makes 
static libraries much more fragile and problematic than using shared 
libraries.


Please note that there are some major operating systems that require 
that dependencies be fully specified while linking a shared library. 
An approach which works for GNU/Linux may fail on other systems.


Without an organization dedicated to making sure that it works (as 
most GNU/Linux distributions do have), it is not feasable to depend on 
shared library implicit dependencies.  Successful implicit 
dependencies are the outcome of careful planning, design, and testing.


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


  1   2   3   4   5   6   7   8   9   10   >