Re: [patch #10393] Fix shared library support on Android

[Roumen Petrov]

На 17.04.24 г. в 18:29 ч., Ileana Dumitrescu написа:

Follow-up Comment #3, patch #10393 (group libtool):

Thank you for the suggestion. Since we are already embedding rpath into
Android, 


And this is now critical defect - https://savannah.gnu.org/support/?111011


we could take the next step and start using GNU/Linux versioning.


No!

Android loader is not compatible.

Roumen

Re: [PATCH 2/2] libtoolize: always copy config-h.in like aclocal.m4

[Roumen Petrov]

Hi,

Mike Frysinger wrote:

When running `libtoolize --ltdl`, a symlink to the source config-h.in
is used rather than a copy of the file.  ...

This is fine . Command supports --copy and this is documented in manual page.


  This breaks `make distcheck` because when a few tests run
that invoke `libtoolize --ltdl --install` w/out --copy, and then try

This is not only autotool that install links . More or less this is expected.



to build the project, automake's rules trigger autoheader regen, and
then update the timestamp, which updates the underlying file, and then
causes libtool's own files to get out of sync.  So the next time make
is run in the tree, it tries to regenerate the source files, and fails
as the source tree is read-only.

Change libtoolize to always copying the header over during install.
...

Sure Just to remind what is output from $ autoreconf -ifv

...
autoreconf: running: libtoolize --copy --force
...
autoreconf: running: automake --add-missing --copy --force-missing
...

Remark: project does not use ltld.


Roumen

Re: [patch #10393] Fix shared library support on Android

[Roumen Petrov]

Hi Bruno,

Bruno Haible wrote:

Roumen Petrov wrote:

Android and Microsoft windows must not encode any paths.


You probably mean to say: Shared libraries packaged in Android .apk
files are mentioned in the Android manifest file (elements 
and ) [1] and therefore don't need a RUNPATH.

But shared libraries created in the Termux environment are a different
case, and they do need a RUNPATH, as I explained in the previous mail.


RUNPATH or another section.
So far so good but not all loaders support all features elf format.
You cannot use one particular sample to dictate for all others.

On top of this run-paths are again rules on some above mentioned OS-es.
On those operation system shared libraries could be installed anywhere.





When I build PKIX-SSH and OpenSSL binaries I must ensure that those libraries 
and executable could run in any Android profile.
The packages are "SecureBox Pro" or SecureBox as add-on to "TermOne Plus".
PKIX-SSH binaries use ldns as resolver library. This library uses libtool.


Again: If you want a certain binary that you build to have no RUNPATH, use the
Android SDK, not Termux and not libtool. Or use libtool outside of Termux
and don't provide a -R option.


There is nothing related to the way how binaries are created by high level 
build environment.
You cannot dictated how to build binaries. I use standard build provided by 
project.

This is reason do not understand you point here. You environment is with 
"hard-coded" paths. I mean at least prefix.

I cannot understand why you build does not use -Xlinker (please check libtool 
documentation for exact name) to specify run-time paths.
You environment is specific and does not fulfill Android requirements.

Libtool is general purpose build system and so must follow OS-requirement.
General build system cannot follow wish list of a developer in environment with 
hard-coded locations.
This is reason Termux application to fail to run in other Android profile.

Termux is a good sample for broken Android application.
Libtool must not follow builds in environment broken by design.





Also to ensure that binaries runs on support API levels elf-cleaner is should be run to 
"strip" certain sections.


You mean [2] or [3]? I think this is out of scope for libtool, because:
   - As far as I understand, it applies to both shared libraries and
 executables, and since executables can be created without using libtool,
 the right place to invoke these tools are not in libtool.
   - As you say, it depends on the minimum supported Android API level, which
 is a priori known to the Makefile and to the compiler (via '-target'
 options), but not known to libtool.


Related to functionality supported by Android loader.
If you would like to distribute binaries clean of some section is strongly 
recommended.

But if build is for fun please pass to the linker specific paths.
As pointed above you environment is with hard-coded location i.e., it is easy 
to set linker options.



Bruno



Roumen

Re: [PATCH] libtool.m4: Handle "/" as a sysroot more correctly

[Roumen Petrov]

Hi All,

Mike Frysinger wrote:

On 16 Jan 2024 21:47, Richard Purdie wrote:

If $CC has --sysroot=/, it is a valid configuration however libtool will
then set lt_sysroot to "/".

This means references like $lt_sysroot$libdir become //usr/lib instead
of the more normally expected /usr/lib. This may or may not break something
but certainly is confusing to the user and gives confusing output. Making
"/" simply unset lt_sysroot is much cleaner.

could the same argument be made if the returned value is "/opt/sysroot/"
and not just "/opt/sysroot" ?  not sure if gcc forces normalization on its
side.  but we could "simplify" this with:


I cannot see reason /path/ vs /path1 to be considered as critical.

But / vs empty is another story.
Prefix // means UNC name in some build environments.


# Trim trailing / since we'll always append absolute paths and we want
# to avoid //, if only for less confusing output for the user.
lt_sysroot=`$CC --print-sysroot 2>/dev/null | $SED 's:/\+$::'`


May be issues is from cygwin build environment.


-mike


Regards,
Roumen

Re: [PATCH] libtool: remove OpenBSD support for non-shared and a.out archs

[Roumen Petrov]

Hi All

Mike Frysinger wrote:

On 16 Jan 2024 21:11, Brad Smith wrote:

libtool: remove OpenBSD support for non-shared and a.out archs

OpenBSD stopped supporting the last non-shared arch 8 years ago
and stopped supporting a.out 10.5 years ago.

This cannot be reason to drop support.
For instance RHEL was release in 2011 and is still supported.


i'm on the fence here, and i don't know what historical guidance/policy
libtool has had.  i looked through HACKING & the manual and didn't find
anything relevant.

Some projects still support c89.
How long to support a functionality is good question.
When hardware die some legacy system have no other options  expect to switch to 
new releases. If exist one ...


yeah, that's an old target, but libtool supports things older than that.
-mike


Regards,
Roumen Petrov

Re: [patch #10393] Fix shared library support on Android

[Roumen Petrov]

Bruno Haible wrote:

Roumen Petrov wrote:

Android and Microsoft windows libraries must not use hard coded paths! 
Nevertheless what is supported by linker or loader.


Why do you mention Microsoft Windows? The commit 
47c71f61df9ace4956cc943f291480315174726b
has no effect on Microsoft Windows.


When I read commit I agree that is correct do not have RUNPATH!
The problem is that commit message is not so clear. Actually commit uses rpath 
flag!
NO! NO! NO!


Why do you want that executables never have RUNPATH on Android? Just saying
"NO! NO! NO!" is not a justification, and your arguments in [2] were not
sensible either.

If you want a certain binary that you build to have no RUNPATH, use the
Android SDK, not Termux and not libtool. Or use libtool outside of Termux
and don't provide a -R option. It's that easy.
[SNIP]


Android and Microsoft windows must not encode any paths.
When I build PKIX-SSH and OpenSSL binaries I must ensure that those libraries 
and executable could run in any Android profile.
The packages are "SecureBox Pro" or SecureBox as add-on to "TermOne Plus".
PKIX-SSH binaries use ldns as resolver library. This library uses libtool.

Also to ensure that binaries runs on support API levels elf-cleaner is should be run to 
"strip" certain sections.


Roumen

Re: [patch #9442] Add flang (LLVM-based compiler) support

[Roumen Petrov]

Hi,


Mike Frysinger wrote:

Update of patch#9442 (group libtool):

   Status:None => Done
  Open/Closed:Open => Closed

 ___

Follow-up Comment #1:

i dropped the -DPIC part as no other target does it, and i think we handle
that in common code already.  feel free to follow up if you disagree.


Please note that by default libtool build shared and static objects .
When is build shared object -DPIC is set internally for shared build.
So to remove -DPIC looks harmless.

I guess that reporter could check this. See libtool manual:
...

Notice that the second run of GCC has its output discarded. This is done so 
that compiler warnings aren’t annoyingly duplicated. If you need to see both 
sets of warnings (you might have conditional code inside ‘#ifdef PIC’ for 
example), you can turn off suppression with the -no-suppress option to 
libtool’s compile mode:

burger$libtool --mode=compile gcc -no-suppress -g -O -c hello.c
gcc -g -O -c hello.c  -fPIC -DPIC -o .libs/hello.o
gcc -g -O -c hello.c -o hello.o
burger$





Regards,
Roumen Petrov

Re: [PATCH 02/12] libtool.m4: Rename the --with-sysroot option to avoid conflict with gcc/binutils

[Roumen Petrov]

Hi,


Richard Purdie wrote:

[SNIP]
FWIW gcc and binutils have gone with --with-sysroot and --with-build-
sysroot to differentiate. Unfortunately that doesn't really help
libtool (see below).


Sure but we when use libtool argument --with-sysroot we expect to work as is 
designed and documented .


--with-libtool-sysroot doesn't make sense as it isn't an internal libtool
setting, it's changing how executables are linked, and users (who run the
configure scripts) don't know or care about this "libtool" thing.

I think it partly depends upon how you view it. Most of the time
libtool uses `$CC --print-sysroot` to set this and therefore most users
wouldn't use the commandline option. In general you do want the
compiler/linker and libtool to be working the same way.

Hmm If I remember well this is GCC specific option.
Android does not use GCC i.e., it cannot find default paths.
More over include and library directories are different i.e. option does not 
make sense for Android cross-builds.
Remark: --with-sysroot should point to "library" in my cross-builds and another 
way is used to specify paths to headers.


[SNIP]

Regards,
Roumen

Re: [PATCH 05/12] ltmain.in: Don't encode RATHS which match default linker paths

[Roumen Petrov]

Hi All

Information below is not enough to understand details.

Richard Purdie wrote:

On Mon, 2024-01-15 at 20:10 -0500, Mike Frysinger wrote:

On 25 Oct 2021 15:33, Richard Purdie wrote:

We don't want to add RPATHS which match default linker search paths, they're
a waste of space. This patch filters libtools list of paths to encoode and
removes the ones we don't need.


Libtool try to avoid search path used by run-time loader.
Note FSF version! Debian patched is know to be broken since decades.

There is a way to adapt old releases on Unix/Linux like build systems.
This is autoconf cache variable . I cannot remember exact name by is like 
lt_cv..dlsearch...path... (1)

If I remember well libtool release 2.4.7  adds configuration variable that 
allows default search path (2) to be set.


In my cross-builds scripts I use model (1) to exclude not only path passed to 
libtool with --with-sysroot argument but additional path.



how are you defining "linker" ?  are you talking about the runtime linker
(i.e. ld.so) or the build time linker (i.e. `ld`) ?

I meant the runtime linker/loader ld.so.


the commit message also doesn't really explain in concrete details the
scenario you're running into.

We were seeing binaries with RPATHS like /usr/lib in them which
basically doesn't do anything useful since it is a default for ld.so.
We were therefore trying to remove those to improve the efficiency of
the binaries slightly.

Cheers,

Richard


Regards,
Roumen Petrov

Re: [patch #10393] Fix shared library support on Android

[Roumen Petrov]

Hello,

When I read commit I agree that is correct do not have RUNPATH!
The problem is that commit message is not so clear. Actually commit uses rpath 
flag!
NO! NO! NO!

Android and Microsoft windows libraries must not use hard coded paths! 
Nevertheless what is supported by linker or loader.


Ileana Dumitrescu wrote:

Update of patch#10393 (group libtool):

   Status:None => Done
  Open/Closed:Open => Closed



[SNIP]

Regards,
Roumen Petrov

Re: [patch #10393] Fix shared library support on Android

[Roumen Petrov]

Bruno Haible wrote:

URL:
   


[SNIP]


1) On this platform, libtool is configured to relink libraries during "make
install". This leads to a problem during the installation of libgettextsrc:
The relink command that libtool emits has the form
 
   $CC -shared -fPIC -DPIC .libs/*.o -L$(libdir) ... -lgettextlib ... -o

.libs/libgettextsrc-@VERSION@.soT
 
The option -lgettextlib resolves to $(libdir)/libgettextlib.a, not to
$(libdir)/libgettextlib-@VERSION@.so. 

[SNIP]

I cannot understand this.
If high level dependency is to lib FOO , i.e. -lFOO  why libtool should emit 
command lFOO-@VERSION@?

Android does not use "versioning" scheme.



2) The installed executables don't have a RUNPATH property that points to the
directory that contains the shared libraries. Thus these executables don't
run. 

It seems to me this is correct.
On Android is expected "relocatable" library and executable. Hard coded search 
path are not expected.


Roumen

Re: libtool is adding "-L/usr/lib" even for cross-compilation with sysroot

[Roumen Petrov]

Hi,

Xi Ruoyao wrote:

Hi libtool dev,

We've recently hit an issue cross-compiling some package using libtool
for sysroot.  Saying libfoo.la contains

So there is a number of models . One to use system libtool and another one 
libtool script builds for project.
First is not for cross-compilation.

Second one should learn some thing related to build system .


libdir=/usr/lib

Then libtool will add "-L/usr/lib" to the linker command line during a
"relink" against libfoo.la, because ltmain.in:6500:

[SNIP]


For instance my script hat builds packages for Android has:
...
CC="$CC --sysroot=$ANDROID_SYSROOT"
...
CONFIG_SITE=$TMPDIR/config.site-$FULLNAME-$PLATFORM
  cat > $CONFIG_SITE <

Re: New libtool maintainer

[Roumen Petrov]

Ozkan Sezer wrote:

On 2/8/22, Julien ÉLIE  wrote:

Hi Alex,


Feel free to reach out if you have pending patches/issues you want to
"bump", ideas for improvements, general advice for a new GNU maintainer
- and above all if you'd like to lend a hand toward getting `libtool' up
and running again.

Many thanks for your work on Libtool!

I believe a good start would be to integrate suggestions and patches
from the issue tracker

https://savannah.gnu.org/patch/?group=libtool

and maybe also some patches Debian (and other distributions) have added
over the years to the last 2.4.6 release.  For instance:

https://sources.debian.org/patches/libtool/2.4.6-15/


We must be very careful with Debian patches!
Only Debian distributes version (valid for 1.4 and 2*) that cannot pass libtool 
regression tests.
As result is expected Debian to be flooded with defects.


Some of the outstanding bugs with existing patches :
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38305
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21137
(and its dups at 22895, 31900, and 36762)
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21503
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22373
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46559

Some of the outstanding bugs without any suggested patches:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45738
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53479


If those bugs are not Debian specific someone could look at them.

Libtool projects must not care for defects that shows Debian libtool brokenness.


Regards,
Roumen Petrov

Re: new release?

[Roumen Petrov]

Hi Alex Ameen,

Alex Ameen wrote:

This is a good question. I plan on making a new release this month.

When I first adopted the project I ambitiously thought I'd manage to create a 
new release after about a month; but the truth is when I started doing a deep 
dive into the internals there was a lot of history and complexity for me to 
unpack. Things that are easy to overlook like how change-logs get generated, 
quirks in the testing framework, and tracing down disparate areas to align 
documentation took quite a while to navigate.


Last maintainer heavy broke libtool scrips we "automatic" code formatting 
scrips.
Happy hacking such  brokenness.




The good news is that I think I've got the confidence to push a release soon. One area 
that I was reading up on this weekend was whether the "alpha"/private releases 
of `libtool' might be appropriate, or whether I should just push a release immediately. 
I'll admit I am leaning towards just making a release to avoid the entire alpha process 
for the time being.

I appreciate you reaching out; I definitely want to get a release out before 
March.


More feasible is to apply patches to 2.4.6 branch and to release from this 
really stable and proven to work version.
IN such case next could be 2.4.8.


Next point is name of development branch.
For some reasons projects switch to main branch. Following move libtool could 
create main branch based on 2.4.6.
From main branch could be released 2.6.
It seems to me more users will test release version then beta or release 
candidate.


[SNIP]

Regards,
Roumen Petrov

Re: disable invocation of winepath by libtool

[Roumen Petrov]

Ozkan Sezer wrote:

On 12/5/21, ilya Basin  wrote:

Dear List. I'm cross compiling a program on Linux for a mingw host and
sometimes this shows Wine dialogs like "updating wine configuration" or
"download and install Mono". I believe it's only needed to run `make check`
successfully, but I want to skip the test suite. How to properly prevent the
invocation if winepath?

Using winepath in libtool really is an abomination and must be removed.
Related: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253


Using winepath is very useful to run regression tests in emulated environment 
on Linux.

I cannot understand why wine in installed but not properly setup. Either remove 
wine or finish installation.


Regards
Roumen Petrov

Re: lt_dlopen an uninstalled library

[Roumen Petrov]

Hi ilya,

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?


No idea.

Just one note that environment variable is LTDL_LIBRARY_PATH - dynamically load 
libtool library.
Path for shared libraries depend from OS.

[SNIP]

Roumen

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

[Roumen Petrov]

Hi Vincent,

Sorry for top posting.

Perhaps is not easy visible for manual ( 
https://www.gnu.org/software/libtool/manual/html_node/Creating-object-files.html
 ) use of conditional code.
In this case #ifdef PIC.

Perhaps better solution is use of -export-symbols.


Vincent Torri wrote:

Hello

I contribute to an autotools project. The tree is :

src/lib/libfoo  <--- the library, with libfoo.h declaring the public symbols
src/bin/bar  <-- the binary which uses libfoo and includes libfoo.h in
its source files

I want to create the library 'libfoo' on Windows. I also want to
declare public symbols with __declspec(dllexport) and
__declspec(dllimport) in a macro that I call MY_API in libfoo.h

Thanks to DLL_EXPORT that libtool is passing to the preprocessor when
compiling the library 'libfoo', there is no problem to compile libfoo.
MY_API is correctly defined either when I build the static lib, or the
shared lib, or both.

The problem I am facing is when I build the 'bar' binary. On Windows:

1) if 'lifoo' is built as a shared library, when I include libfoo.h in
'bar' source files, MY_API must be defined as __declspec(dllimport)
2) if 'libfoo' is built as a static library, when I include libfoo.h
in 'bar' source files, MY_API must be defined as nothing

but, as far as I know, when I compile 'bar', I couldn't find a way to
know if 'libfoo' has been compiled as a static library or as a shared
library. I have looked at the 'bar' source files gcc calls, and they
are the same in both cases (libfoo compiled as a static or shared
lib). So I don't know how I can correctly define my macro MY_API.

Here is, for now, my macro:

#if defined(_WIN32) || defined(__CYGWIN__)
# ifdef FOO_BUILD  // defined when building 'libfoo'
#  ifdef DLL_EXPORT
#   warning "BUILD DLL"
#   define MY_API __declspec(dllexport)
#  else
#   warning "BUILD STATIC"
#   define MY_API
#  endif
# else
#  warning "IMPORT DLL"
#  define MY_API __declspec(dllimport)
# endif

in the last #else, I don't know what to do to correctly manage MY_API
for my problem above

One solution would be : never compile 'lbfoo' as a static lib ("DLL
are good on Windows"), but I would like to support both static and
shared libraries.

Does someone know how to solve my issue ? (I hope I've been clear enough...)

thank you

Vincent Torri



Regards,
Roumen Petrov

Re: transitive shared library dependencies and installation

[Roumen Petrov]

Hi Russ, libtool members,


I work on open source projects in my spare time. And so I can not 
provide feedback promptly. Today I have time to re read mail thread and 
to clarify my strong position.


Russ Allbery wrote:

Roumen Petrov  writes:


Urgh, article with very limited niche. First is only for shared libraries,
next unresolved externals in shared library, and finally requires
"advanced" loader.

Overlinking isn't about unresolved externals in shared libraries.
With unresolved I think about something different but this area is 
mostly out of scope to this thread.



It's
about avoiding linking with shared libraries that *don't* resolve any
external symbols.
This is one point - limited to "shared". Issue is not applicable for 
"static".



   It doesn't require an advanced loader, just any
reasonably modern shared library system; Solaris 2.6 from many years ago
had the same issue.
I'm thinking about Android - with modern shared library system and poor 
loader.

Autotools should work for such hosts as well.


   It is specific to systems where the linker is willing
to encode dependencies to libraries (in NEEDED, for instance) that aren't
actually required, but that's the default behavior of, say, GNU binutils.
Yes binutils adds to "needed" all passed on command line libraries for 
ELF but not for COFF.



The standard problem is that liba depends on libb, and a binary depends on
liba (but not libb).
Yes if you mean that binary uses only functions from "liba" and no one 
of all those functions need function from "libb". Let skip use of "data" 
from a library.


If B [binary] uses Fa() [function from a] and Fa() uses Fb() [function 
from] the thinks are different.

If we perform static build we must list both libraries.
Another case is shared build. For COFF is used import library. Import 
library does not add "dependency". So we must list both libraries.


Also for COFF list may contain "extra libraries". Binutil linker will 
link(pick) only ready used - there is no overlinking!




Libtool's default behavior in the presence of *.la
files will link the binary with both liba and libb, even though it only
needs to be linked with liba.

Only in "shared" build for ELF.


This causes a lot of problems for the
dependency management in a distribution if allowed to happen archive-wide,
since it creates tons of unnecessary dependency edges that make dependency
resolution and archive management much harder.

And the main question is who is responsible to resolve this issues.


Avoiding *.la files solves most of this.

Using *la files is very helpful for static or for COFF shared builds!


--as-needed helps when the
upstream Makefiles are designed to support static linking (where all the
libraries have to be listed), or where upstream just didn't pay attention
to this or didn't consider overlinking to be a problem, but has been known
to have bugs where it leaves out dependencies that actually are required.
This is specific for ELF. It seems to me discussion for linker 
capability exceed scope of this mail list.



For the software I personally maintain, --enable-reduced-dependencies
changes the behavior of Autoconf macros to not add the full transitive set
of libraries and instead only link with the immediate dependencies.  But I
think I'm the only person who uses that convention.  For newer software
that uses pkg-config, pkg-config supports this inherently if the library
maintainers write correct pkg-config files (which a lot of them don't).

The article may have limited applicability in the grand picture of all
systems and all ways of linking libraries, but it applies to pretty much
every Linux distribution (and probably any other distribution of any kind
of UNIX that uses shared libraries and package dependencies).  So by
quantity of Libtool installs and invocations, it's significant.


Open source is not limited to Linux. Build should be work on many 
OS-es(complilers, linkers, loaders).


Article https://wiki.mageia.org/en/Overlinking_issues_in_packaging 
inform us about issue in preamble.
Unfortunately context is totally misleading. It proposes correction in 
some build helpers - this definitely breaks other platforms.



As exercise:
Write configure script that test for presence of OpenSSL function 
EVP_add_cipher. Use existing macro AC_LINK_IFELSE. Ensure that it will 
work for shared and static build. Ensure that test will work on linux, 
mingw (solaris, android and etc.) hosts.


Note configure script does not use linker wrapper scripts like libtool 
and I would like to suggest do not use macro PKG_CHECK_MODULES.



I guess that after successful implementation my opinion about article 
will be more clear.



Also article point to "underlinking". With other words proposed 
solutions for build helpers (pkg-config, libtool) will lead to 
underlinking on other platforms..



Off topic: For

Re: transitive shared library dependencies and installation

[Roumen Petrov]

Hi Feri,

wf...@niif.hu wrote:

[SNIP]
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
Urgh, article with very limited niche. First is only for shared 
libraries, next unresolved externals in shared library, and finally 
requires "advanced" loader.


For instance on Microsoft Windows shared library (DLL) does not allow 
"unresolved symbols".
Remark: Initial example requires -no-undefined flags as library LDFLAGS 
(libtool requirement) for mingw* builds.
Even that fact that for executable build command includes all libraries 
linker may exclude some of them. I guess that this is because usually 
build uses "import libraries". Dunno what is behavior if build is 
directly with DLLs.


Another system is Android. System allows unresolved externals but loader 
is quite simple. To load dynamically shared library is must not contain 
unresolved externals.


Static build: partial or complete. There is no rule in general. Linker 
picks required symbols from archives and may require some dependent 
libraries. So in some cases environment variable PKG_CONFIG set to 
pkg-config --static is solutions.




  mentions that
"this is fixed using a patch from Debian" for libtool.


I wonder why is patched libtool.
Libtool is not only Debian. Is is supposed to work on all supported 
OS-se, distributions and etc.
Because of those "fixes" it is mandatory to bootstrap source tarbal 
generated on Debian with M4 macros from FSF sources.

Now I do this unconditionally on all source tarballs - it save my time.


What's your position on this?  Is overlinking a problem or not?  (It
causes problems for distributions.)
No Idea. I guess that this is more related to the rules describing 
package dependencies.
A package could be split into multiple sub-package. A project may 
produce one "big" library or several "small" libraries. In both cases 
upgrade of related package is maintenance hassle.


Topic is not for libtool . It is more general.



Should everybody use --as-needed
globally to combat it?  Something else entirely?


On some OS-es --as-needed is enabled by default. I'm not aware why this 
model was chosen instead "s/tatus quo"./


As needed is fine with limited shared library format like those used on 
Microsoft windows  (COFF?) - no unresolved, no weak symbols. In the past 
loader does not guarantee that load of library follow dependency rules.


Also as needed may break use of weak aliases (ELF format).

I'm not sure that libtool respect order of linker options like 
--no-as-needed or --as-needed.


As alternative could be used patchelf.

It seems to me question is how to remove some extra dependencies : 
automatically (--as-needed) or manually (using tools like patchelf).


May be topic is not for libtool list.

Regards,
Roumen Petrov

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

[Roumen Petrov]

Martin Liška wrote:

[SNIP]



However, LTO breaks nm really badly and with -fno-common this variable
gets marked as "T" in the nm output.


Thank you for identification of the root cause. I've just created a 
nm issue

for that:
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
It is clear that defect 25355 never will be fixed - by design plugin 
architecture is not suitable for lto and nobody would like to work on 
new version ( LD_PLUGIN_API_VERSION 2? ).



So apparently it's a known limitation of the LTO plugin. Question is 
whether

we can somehow workaround that?


Work-around was already provided - please see following feedback : 
https://lists.gnu.org/archive/html/libtool/2020-01/msg00027.html

Let me quote Nick Bowler feedback:


Workaround: add -ffat-lto-objects to CFLAGS so you get proper symbol
tables in object files and then set NM='nm --plugin ""' to completely
disable the busted LTO support in nm.

For example:

  ./configure CFLAGS='-flto -fno-common -ffat-lto-objects' NM='nm --plugin ""'




Martin

[SNIP]

Re: transitive shared library dependencies and installation

[Roumen Petrov]

Hi Feri,

wf...@niif.hu wrote:

[SNIP]

It is long history It starts with 1* (1.5) libtool . Libtool 1.5 has
some issues with multiple dependent libraries (more then two).
 From debian was proposed a patch related to library
dependencies. Unfortunately patch break existing regression test. From
debian never was proposed version that pass regression test.

Libtool 2.0 fixes his issues related to multiple libraries. On the
same Debian did not stop to contribute patch that breaks libtool.

As result when I decide to build something from source always to
updated sources to FSF version.

So the right question is did reporter test with FSF version?

I'm the reporter, and I didn't test any other version, as I wasn't even
sure whether my example was correct and was supposed to work.

You sample is correct .
One minor nit is AM_PROG_AR - it is not required for posted example. If 
you project requires use of this macro you should request automake 
1.11.2 as minimum.



Could you
please provide some keywords to search for so that I can dig up the
details of the above story?

Please check libtool achives.
To me situation on Debian is closed case.


  At the moment Debian carries 21 patches for
libtool, if I could show that one of them breaks a valid use case, that
would constitute a strong reason for dropping it.


In moment I do tests on some sources from development or stable branches 
on an another system (archaic :) ):


$ cat /etc/centos-release
CentOS release 6.10 (Final)

$ autoconf --version
autoconf (GNU Autoconf) 2.63

$ automake --version
automake (GNU automake) 1.11.1

$ libtool --version
ltmain.sh (GNU libtool) 2.2.6b

All is based on system packages except tested by me.


Result on posted test case - pass:
$ ./translib ; echo $?
12

$ readelf -a  a/.libs/liba.so  | grep RPATH
 0x000f (RPATH)  Library rpath: 
[/home/centos/.builds/test/autotools/translib/b/.libs:/tmp/translib/lib]


$ readelf -a .libs/lt-translib  | grep PATH
 0x000f (RPATH)  Library rpath: 
[/home/centos/.builds/test/autotools/translib/a/.libs:/home/centos/.builds/test/autotools/translib/b/.libs:/tmp/translib/lib]


$ readelf -a .libs/translib  | grep PATH
 0x000f (RPATH)  Library rpath: [/tmp/translib/lib]

$ readelf -a /tmp/translib/lib/liba.so | grep PATH
 0x000f (RPATH)  Library rpath: [/tmp/translib/lib]


Regards,
Roumen Petrov

Re: transitive shared library dependencies and installation

[Roumen Petrov]

Hello,

wf...@niif.hu wrote:

Roumen Petrov  writes:


wf...@niif.hu wrote:


I'm experimenting with the attached skeleton project on a Debian buster

Debian is key word.


system (autoconf 2.69-11, automake 1:1.16.1-4 and libtool 2.4.6-9):

Libtool is patched, not FSF.

[SNIP]

/usr/bin/ld: cannot find -lb
collect2: error: ld returned 1 exit status
libtool:   error: error: relink 'a/liba.la' with the above command before 
installing it
make[1]: *** [Makefile:446: install-libLTLIBRARIES] Error 1
make[1]: Leaving directory '/home/wferi/ha/pacemaker/translib'
make: *** [Makefile:798: install-am] Error 2

[SNIP]

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?

Not reproducible with FSF release.

Could you please share your link command?  Does you system use the new
dynamic tags (DT_RUNPATH instead of DT_RPATH)?
This does not make sense. With and without  new dtags result will be the 
same.


It is long history It starts with 1* (1.5) libtool . Libtool 1.5 has 
some issues with multiple dependent libraries (more then two).
From debian was proposed a patch related to library dependencies. 
Unfortunately patch break existing regression test. From debian never 
was proposed version that pass regression test.


Libtool 2.0 fixes his issues related to multiple libraries. On the same 
Debian did not stop to contribute patch that breaks libtool.


As result when I decide to build something from source always to updated 
sources to FSF version.


So the right question is did reporter test with FSF version?


Regards,
Roumen Petrov

Re: transitive shared library dependencies and installation

[Roumen Petrov]

wf...@niif.hu wrote:

Hi,

I'm experimenting with the attached skeleton project on a Debian buster
system (autoconf 2.69-11, automake 1:1.16.1-4 and libtool 2.4.6-9):

[SNIP]

/usr/bin/ld: cannot find -lb
collect2: error: ld returned 1 exit status
libtool:   error: error: relink 'a/liba.la' with the above command before 
installing it
make[1]: *** [Makefile:446: install-libLTLIBRARIES] Error 1
make[1]: Leaving directory '/home/wferi/ha/pacemaker/translib'
make: *** [Makefile:798: install-am] Error 2


Libtool does not change "order" :(. Automake just uses project rules.


Let view Makefile.in
...
install-exec-am: install-binPROGRAMS install-libLTLIBRARIES
...
install-binPROGRAMS: install-libLTLIBRARIES
...
install-libLTLIBRARIES: $(lib_LTLIBRARIES)
...
Above dependency explain all - lib_LTLIBRARIES is project (sample) 
specific. Project should ensure order.




[SNIP]


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?

Not reproducible with FSF release.

Regards,
Roumen Petrov

Re: [sr #109844] Do not override user's LD_LIBRARY_PATH in generated ltmain.sh for the build dir wrappers

[Roumen Petrov]

anonymous wrote:

URL:
   <https://savannah.gnu.org/support/?109844>

  Summary: Do not override user's LD_LIBRARY_PATH in generated
ltmain.sh for the build dir wrappers
  Project: GNU Libtool
 Submitted by: None
 Submitted on: Sat 13 Jul 2019 09:50:51 AM UTC
 Category: None
 Priority: 5 - Normal
 Severity: 3 - Normal
   Status: None
  Privacy: Public
  Assigned to: None
 Originator Email:
  Open/Closed: Open
  Discussion Lock: Any
 Operating System: GNU/Linux

 ___

Details:

ltmain.sh now (at least in Ubuntu 18.04) overrides the LD_LIBRARY_PATH with a
It seems to me libtool does not override path. It should prepend 
projects specific paths to environment variable.

Existing code:
...
    # Add our own library path to $shlibpath_var
    $shlibpath_var=\"$temp_rpath\$$shlibpath_var\"
...


system library path, thus forcing the system libs over the user's custom path
installed ones.

I fixed this in TCE build by patching ltmain.sh in our build script generator
script:

https://github.com/cpc/tce/commit/820fe4475f65b38f4ec6c7013d1ddfe4510058c0#diff-36fd0e6bb489c013aa25e9a5fd4467a2

I'm not convinced that patch is correct.
Let project build new version of a system library and try to perform 
some tests. Executable from regression tests should use library from 
"build tree" not system one.


Regards,
Roumen Petrov


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

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

[Roumen Petrov]

uri wrote:
> On 2019-06-24 09:55, Roumen Petrov wrote:
>>
>> And projects builds just fine!
>> Conclusion - there is no defect neither in libtool nor in automake nor
>> in project autotool files.
>>
>> Reporter still does not provide feedback with information from
>> configuration time (requested in a previous post) => resolution is -
>> broken build environment.
>
>
> configure and Makefile.in contain -lstdc++. These could be different
> between systems. On FreeBSD it should be -lc++.
Both configure and Makefile.in are generated .

You cannot blame configure for -lstdc++ as more or less is expected. It 
depend from so many things. For instance is normal a autoconf based 
project to check for function or libraries.
Next is Makefile.in. It is generated from  Makefile.am. Please check 
again ;).



>
> It worked when I patched these lines, Dunno why you shut in the dark.

but this is error-prone because
> some other toolchains might use a different C++ library.

Yes , and instead to update generated scripts you could help project 
ViennaRNA to improve build with correct report.



>
>
> Once the error-prone -lstdc++ are removed, libtool fails because it
> links with the C compiler.
Ha-ha. Interesting. Now I have idea how broke your build system .
Please avoid to update  randomly some scripts.

One again ViennaRNA build fine in my environment. Build system uses 
proper compiler.

NO ISSUE WITH LIBTOOL!


>  Yuri

Regards,
Roumen


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

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

[Roumen Petrov]

Dunno what is wrong in Yuri's FreeBSD environment

Bob Friesenhahn wrote:

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


In my environment /usr/bin/cc is link to gcc , linked to gcc-5.5.0, and 
c++ is linked to g++, linked to g++-gcc-5.5.0.


In my environment.
At configure time both compiles are detected as usable. At build time I 
could see:

- for C code:
  CC foo
  CCLD bar
- for C++ code:
  CXX alice
  CXXLD bob
And projects builds just fine!
Conclusion - there is no defect neither in libtool nor in automake nor 
in project autotool files.


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



Regards,
Roumen

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

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

[Roumen Petrov]

Yuri wrote:

On 2019-06-23 12:19, Roumen Petrov wrote:

cc ?

I'm not sure which compiler suite is used on FreeBSD but it seems to 
me C++ compiler is not installed.


clang8 is used. cc is a C compiler, c++ is a C++ compiler.


Ok. Dunno why is not detected c++ at configure time. I'm not familiar 
with clang as C++ compiler, especially installed symbolic links.
Please check configure output and then config.log to find why 
detection(tests) for C++ compiler fail. Also check detection of C complier.
For instance autoconf macro should search for availability of g++ or c++ 
or cxx or CC and etc as C++ compiler commands.

If clang C++ is not in list detection fail.

If clang is default OS compiler is expected symbolic link c++ to clang++ 
or similar. May be some OS setup commands could set such links.



Remark:
At end ./configure --help outputs environment variables .
Those variables could be used to tune build process.
For instance CXX=my-c++ ./configure ... could be used to change C++ 
compiler.



Roumen

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

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

[Roumen Petrov]

Yuri wrote:

On FreeBSD libtool can't find operator new[] because it is in C mode:

libtool: link: cc -fno-strict-aliasing -fopenmp -ftree-vectorize 
-pthread -O2 -pipe -fno-omit-frame-pointer -fstack-protector-strong 
-fno-strict-aliasing -fno-strict-aliasing -fstack-protector-strong -o 
RNALfold RNALfold_cmdl.o RNALfold.o 
../../src/ViennaRNA/.libs/libRNA_conv.a ./.libs/libhelpers.a -lm 
-pthread -fopenmp
libtool: link: cc -fno-strict-aliasing -fopenmp -ftree-vectorize 
-pthread -O2 -pipe -fno-omit-frame-pointer -fstack-protector-strong 
-fno-strict-aliasing -fno-strict-aliasing -fstack-protector-strong -o 
RNALalifold RNALalifold_cmdl.o RNALalifold.o  
../../src/ViennaRNA/.libs/libRNA_conv.a ./.libs/libhelpers.a -lm 
-pthread -fopenmp

ld: error: undefined symbol: operator new[](unsigned long)
>>> referenced by svm.cpp
>>>   svm.o:(Kernel::Kernel(int, svm_node* const*, 
svm_parameter const&)) in archive ../../src/ViennaRNA/.libs/libRNA_conv.a



cc ?

I'm not sure which compiler suite is used on FreeBSD but it seems to me 
C++ compiler is not installed.


Roumen

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

Re: Accounting for -rpath when libtool isn't helping

[Roumen Petrov]

Hi Paul,

Paul "LeoNerd" Evans wrote:

[SNIP]
Alternatively, am I looking at this from the wrong direction? Maybe the
problem is that the exporting library isn't providing -Wl,-rpath in
its .pc file, to assist anyone else who wasn't using libtool to link it
(such as is the case here).

No , I don't think that this is valuable.



With that in mind, I now generate those if required, in the little
shell fragment I use to create the .pc file:

#!/bin/sh

LIBS='-L${libdir} -ltickit'
CFLAGS='-I${includedir}'

case "$LIBDIR" in
   /usr/lib) ;;
   /usr/local/lib) ;;
   *)
 LIBS="$LIBS -Wl,-rpath -Wl,$LIBDIR"
 ;;
esac

cat <

Like you perl (first email) and shell (above) scripts libtool do similar 
to decide when to add "runpath" linker flag. Libtool parses 
/etc/ld.so.conf and "build-in default paths" and if a library path is 
not in list adds "runpath" flag.


On most platform you control this via variable 
lt_cv_sys_lib_dlsearch_path_spec. Pattern *_cv_* mean that this is a 
"autoconf cache variable" and "lt" is custom namespace prefix.


Add $HOME/lib to list to avoid -rpath flag.


For some autoconf builds with use of libtool you could force -rpath if 
needed - add those options to LDFLAGS ( see ./configure --help) .



Regards,
Roumen Petrov


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

Re: [patch #9678] ltmain.sh: [_MSC_VER] should be [_WIN32] in one place

[Roumen Petrov]

Simon Sobisch wrote:

[snip]

Details:

As noted in #109514 there are much more compilers for Win32 than the
proprietary MSVC and GCC "based" compilers.
All I'm aware of that match those criteria need process.h instead of unistd.h
(as [_MSC_VER] does), which is fixed with the attached patch.


Simon, does you patch means include process.h and etc. if platform is 
windows but not mingw* (i.e. gcc) ?


Roumen

Re: Why is Guile unable to find libtool?

[Roumen Petrov]

Hi Bruce,

Bruce Korb wrote:

  $ ./configure
.
checking for libltdl... no
configure: error: GNU libltdl (Libtool) not found, see README.
This error is for "libtool dynamic loader library" ltdl. Perhaps you 
system distribute separate libtool and libltdl packages.



  $ type libtool
bash: type: libtool: not found

libtool is generated script.
Some vendors decided do not distribute script generated (build) by 
libtool package.

Usually there is no such need.



[SNIP]
  $ type libtool
bash: type: libtool: not found


After successful  configuration of you project 'libtool" script(s) will 
be generated in build tree.



Regards,
Roumen Petrov


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

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

[Roumen Petrov]

Hello,

LRN wrote:

While looking though ltmain source code i've stumbled upon this egrep 
invocation:
$EGREP ' (_head_[A-Za-z0-9_]+_[ad]l*|[A-Za-z0-9_]+_[ad]l*_iname)$'
I've tried to see how it behaves on some import libraries that i have, and it
turned out that i could never get it to detect the iname lines, unless i escape
the plus sign.

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 .



Note that the function that does this is only
used in rather exotic corner-cases (old dlltool and/or ms dumpbin being in
use), so it's plausible that it could have been broken since 2010, when it was
added.



Regards,
Roumen Petrov


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

Re: merging various libraries into a single DLL on windows

[Roumen Petrov]

Werner LEMBERG wrote:

Folks,


my ttfautohint library exports a single function (`TTF_autohint') and
depends on freetype and harfbuzz.  A user posted the following recipe
to merge these three libraries into a single DLL in Windows.


Looks like use of libtool "Convenience" libraries.

[SNIP]

Regards,
Roumen

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

Re: small fix of libtool.m4

[Roumen Petrov]

Christian wrote:

so today i gave it a shot again and put a debug output right before the ‘$RM 
“$cfgfile”’. For some reason RM is set to ‘/bin/rm’ only. no ‘-f’. i’ll try to 
figure out where that might come from.

Perhaps build package is libxslt .
Issue is already reported many times. Project use AC_PATH_PROG to find 
rm command.


May be change variable name to lt_RM is solution

Regards,
Roumen

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

[Roumen Petrov]

Hi Filipe,

Filipe Brandenburger wrote:

Hi,

I'm trying to link binaries to libraries that are not installed on the
system, but just unpacked to a staging directory.

[SNIP]


Is this a libtool bug?

Any suggestions of workarounds?

(I also filed a bug at
http://savannah.gnu.org/support/index.php?108637  in case this is
actually a libtool bug.)


Libtool exclude directories from RPATH if path is listed in 
sys_lib_dlsearch_path_spec - list of space separated directories.



Variable sys_lib_dlsearch_path_spec is generated from a libtool macro. 
On linux with FSF libtool version value start with /lib /usr/lib and 
existing directories from /etc/ld.so.conf .



After configuration user could check current value with command:
$ ./libtool --config | grep sys_lib_dlsearch_path_spec
( I assume that package build process generate libtool script in build 
directory )



You could use lt_cv_sys_lib_dlsearch_path_spec to override it at 
configure time.

.../configure  \
...
lt_cv_sys_lib_dlsearch_path_spec=ORIGINAL VALUE STAGING_PATH
...


Regards
Roumen Petrov


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

Re: Windows Line Endings

[Roumen Petrov]

Peter Rosin wrote:

On 2012-10-08 23:29, Roumen Petrov wrote:

Peter Rosin wrote:

Hi Roumen,

On 2012-10-07 11:37, Roumen Petrov wrote:

And now test fail in cross environment : linux for mingw host

Thanks for the report!

I have pushed this. Let me know if it doesn't help.

No comment.

Thank you, I'm assuming it finally works for everybody.


Did you think that world to follow you stupid patches ?

It is enough do throw out you commits to bring system in stable state again.




Ralf wrote so good code I cannot understand any Peter's  patches.
Why you just don not use existing working fine macros ?

Please, make a useful suggestion instead of hand-waving it like
that. What working macros should I use? I also don't see where I'm


You even didn't wait  72 hours for feedback !

Each of you recent obvious (!!)  patches break libtool.




introducing any new macros, can you please point that out for me?
And Ralf must write very special code indeed if his code somehow
makes it impossible for some to read the code others write.
[Ralf, if you're reading this, I hope you understand that I don't
think that's true, you write very good code, period]


In this particular case,

LT_AT_HOST_DATA([expout],

doesn't work as it creates \r\n newlines in expout, and $EGREP futzes
the newlines on MSYS so that the standard output ends up \n, causing
the test to blow up.

AT_HOST([expout],

doesn't work as $EGREP leaves the newlines alone for Linux-MinGW
(at least that's what I deduced from your report), and then you
have \n in expout and \r\n in standard output. And the test blows up.

Either that, or I misread your And now test fail in cross
environment : linux for mingw host message. I read it as if the
test worked without my patch changing LT_AT_HOST_DATA to AT_HOST,


Exactly .


and that the test failed with the patch.

Exactly after you fluctuations .


That message made me
assume that neither LT_AT_HOST_DATA nor AT_DATA works for this
test (and the only thing different in this test is that $EGREP
is used).


You must investigate more why in this particular case LT_AT_HOST_DATA 
fail in you environment .




So, the newlines has to be normalized after the $EGREP, or the
test has to be rewritten in a deeper way.


Take care that LT_AT_HOST_DATA is used more then once !



And, as it happens, Ralf did not write the code I'm changing here,
it was written by Gary when he thankfully eradicated the legacy
testsuite, so I'm not sure why you're dragging Ralf into this?

You just wrote to the world that you don't know author of LT_AT_HOST_DATA !

Ralf did not write the code I'm changing here - ha ha ha .

You just point  that you lack basic knowledge and experience with 
libtool test suite .


With recent commits you just ask you commit privileges to be revoked due 
lack of background knowledge



Peter, I hop that after 10 years you will reach level of Ralf .


Cheers,
Peter


Roumen

Re: Windows Line Endings

[Roumen Petrov]

Peter Rosin wrote:

Hi Roumen,

On 2012-10-07 11:37, Roumen Petrov wrote:

And now test fail in cross environment : linux for mingw host

Thanks for the report!

I have pushed this. Let me know if it doesn't help.


No comment.

Ralf wrote so good code I cannot understand any Peter's  patches.
Why you just don not use existing working fine macros ?



 From 0f31e375104b00a181557d3809e556066b3d98b1 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Mon, 8 Oct 2012 13:10:02 +0200
Subject: [PATCH] tests: rerefix line ending problems on MinGW.

The previous commit broke Linux-MinGW cross-compiling.
Report by Roumen Petrov.

* tests/mdemo.at: Normalize line endings after $EGREP.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
  tests/mdemo.at |   12 +---
  1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/tests/mdemo.at b/tests/mdemo.at
index 48b7f63..4d70596 100644
--- a/tests/mdemo.at
+++ b/tests/mdemo.at
@@ -824,7 +824,8 @@ int main (int argc, char **argv)
  }
  ]])

-# Not using LT_AT_HOST_DATA below, since $EGREP normalizes line endings.
+# Normalize line endings after $EGREP instead of using LT_AT_HOST_DATA
+# here, since $EGREP *may* normalize line endings for us.
  AT_DATA([expout],
  [[Welcome to GNU libtool mdemo2!
  module name: foo1
@@ -849,9 +850,14 @@ LT_AT_CHECK_CONFIG([--with-included-ltdl])

  LT_AT_MAKE

-LT_AT_EXEC_CHECK([./mdemo2_static], 0, [expout], [],
+LT_AT_EXEC_CHECK([./mdemo2_static], 0, [stdout], [],
  [./foo1.la ./libfoo2.la | $EGREP -v '^module filename: '])
-LT_AT_EXEC_CHECK([./mdemo2], 0, [expout], [],
+LT_AT_UNIFY_NL([stdout])
+LT_AT_CHECK([diff expout stdout])
+
+LT_AT_EXEC_CHECK([./mdemo2], 0, [stdout], [],
  [./foo1.la ./libfoo2.la | $EGREP -v '^module filename: '])
+LT_AT_UNIFY_NL([stdout])
+LT_AT_CHECK([diff expout stdout])

  AT_CLEANUP


Whats going with Ralf ..


Roumen

Re: Windows Line Endings

[Roumen Petrov]

Peter Rosin wrote:

[SNIP]
That part of mdemo now works, thanks!

But that said, I'm about to push this revert of one of the line
ending fixes that was masked by this orthogonal problem.

Cheers,
Peter


 From b78fd9740ef6a2ed67a1ef14e76483af784fb5f0 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Sun, 7 Oct 2012 00:57:26 +0200
Subject: [PATCH] tests: refix line ending problems on MinGW.

In commit 22f5750, one of the hunks actually introduced
line ending problems. Revert that hunk.

* tests/mdemo.at: Use AT_DATA for expected output when the
output from compiled programs is fed through $EGREP.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
  tests/mdemo.at |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tests/mdemo.at b/tests/mdemo.at
index 70c5532..48b7f63 100644
--- a/tests/mdemo.at
+++ b/tests/mdemo.at
@@ -824,7 +824,8 @@ int main (int argc, char **argv)
  }
  ]])

-LT_AT_HOST_DATA([expout],
+# Not using LT_AT_HOST_DATA below, since $EGREP normalizes line endings.
+AT_DATA([expout],
  [[Welcome to GNU libtool mdemo2!
  module name: foo1
  module reference count: 1
--
1.7.9




And now test fail in cross environment : linux for mingw host

Roumen

Re: [PATCH] tests: skip with-pic test when no real pic flag is used.

[Roumen Petrov]

Peter Rosin wrote:

On 2012-09-19 23:02, Roumen Petrov wrote:

Peter Rosin wrote:

SNIP]
So, what do you mean?

On woe libtool define -DDLL_EXPORT as pic flag . So the value is
pic_flag= -DDLL_EXPORT -DPIC
On some other platform PIC default. I don't have asses to
those platforms and I could guess that the value is pic_flag=-DPIC,
i.e. only wit defines.

Ah, now the objection makes sense.  Thanks for spelling it out!


If I understand patched code properly, skip the test if pic_flag
contain only defines. This mean that other platform will be skipped
too.

Correct.
  

What about to skip test only if DLL_EXPORT is in pic_flag ?

Since the patch has already been pushed and it is only a test
that may be skipped on some other platforms, I'm going to
wait for a bit until someone can confirm if this change has in
fact caused skips where the test used to pass.  So, not
rushing this one...


I can not understand why you expect someone to confirm.
a) how many users use platform with PIC default ?
b) how many users build  with libtool instead that vendor (proprietary) 
build system ?

c) how many users test libtool ?
d) how many users report skipped tests if no one of the tests fail ?




Anyway, the change is simple if needed:

So push it.


-real_pic=false
+no_dlls=:
  case  $pic_flag  in
-[* [^ -]* | * -[^D]*]) real_pic=: ;;
+* -DDLL_EXPORT *) no_dlls=false ;;
  esac
-AT_CHECK([$real_pic || exit 77])
+AT_CHECK([$no_dlls || exit 77])

Cheers,
Peter



Roumen

126. mdemo.at:684: testing ltdl dryrun ...

[Roumen Petrov]

Hi,

This test case fail tic(tick) and pass on tac(tack) ;)  on linux , 
libtool bootstrap with autoconf 2.69 and automake 1.12.2.


It seems to me a timestamp issue .
LT_AT_MAKE([install]) run config.status to refresh config.h as stamp-h1 
is newer .  Result is appended to config.log and later compare before vs 
after trigger failure in the test. May be this is autoconf issue


What about attached patch 
0001-tests-mdemo.at-in-ltdl-dryrun-build-config.h-first-t.patch ?


Roumen

From 2061bfc7e996a7af1a2f92dbcd36101d87c1 Mon Sep 17 00:00:00 2001
From: Roumen Petrov lo...@example.net
Date: Sun, 7 Oct 2012 14:04:22 +0300
Subject: [PATCH] tests/mdemo.at : in ltdl dryrun build config.h first to
 avoid timestamp issues

---
 tests/mdemo.at |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tests/mdemo.at b/tests/mdemo.at
index 70c5532..622e45c 100644
--- a/tests/mdemo.at
+++ b/tests/mdemo.at
@@ -686,7 +686,7 @@ AT_SETUP([ltdl dryrun])
 _LT_SETUP
 
 LT_AT_CHECK_CONFIG([--with-included-ltdl])
-LT_AT_MAKE([all-local libltdl/libltdlc.la])
+LT_AT_MAKE([config.h all-local libltdl/libltdlc.la])
 
 # create `before' and `after' in a directory deep within objdir,
 # so that their creation and removal does not modify even a timestamp
-- 
1.7.4.4

Re: [PATCH] tests: don't feed -no-undefined to the linker during, configure.

[Roumen Petrov]

Peter Rosin wrote:

* tests/deplibs-mingw.at: Restore LDFLAGS for the configure run so that
the linker does not see -no-undefined. Makes the test pass instead of
skip on MinGW.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
  tests/deplibs-mingw.at |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

Ok to push?
No idea. It pass to me with git code , cross build, tested in emulated 
environment.



Roumen

Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

[Roumen Petrov]

Peter Rosin wrote:

On 2012-09-19 09:31, Peter Rosin wrote:

* tests/runpath-in-lalib.at: Make sure shared libraries are created
on Windows by passing -no-undefined. Otherwise libb.la fails to record
a dependency on liba.la, and the final link of the program then fails
with undefined symbols.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
  tests/runpath-in-lalib.at |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

Ok to push?
No idea . Test pass to me with current repository code, cross build , 
run in emulated .


Roumen

Re: [PATCH] tests: skip with-pic test when no real pic flag is used.

[Roumen Petrov]

Peter Rosin wrote:

* tests/with-pic.at: Windows uses -DDLL_EXPORT -DPIC as the pic
flag, but never applies it to static libraries. Cater for this
and skip if no real pic flag is in use.

I'm not sure that this test is suitable for mingw host.



Signed-off-by: Peter Rosin p...@lysator.liu.se
---
  tests/with-pic.at |   11 ++-
  1 files changed, 10 insertions(+), 1 deletions(-)

Ok to push?
No as libtool should define -DPIC and for mingw host pic flag is 
-DDLL_EXPORT


Roumen

Re: [PATCH] tests: don't feed -no-undefined to the linker during, configure.

[Roumen Petrov]

Peter Rosin wrote:

On 2012-09-19 21:25, Roumen Petrov wrote:

Peter Rosin wrote:

* tests/deplibs-mingw.at: Restore LDFLAGS for the configure run so that
the linker does not see -no-undefined. Makes the test pass instead of
skip on MinGW.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
   tests/deplibs-mingw.at |3 +++
   1 files changed, 3 insertions(+), 0 deletions(-)

Ok to push?

No idea. It pass to me with git code , cross build, tested in emulated 
environment.

It's strange that you get a pass, if you have mingw.

Note that the test is a bit weird in that it passes instead
of skips on $host_os != mingw*, so are you sure you even get
into the inner configure with your setup? Because if you do,
your compiler must accept -no-undefined and that seems
unlikely to me.

Anyway, in my non-cross, non-emulated setup, the test skips on
line 79:

LT_AT_CONFIGURE([|| exit 77], [$abs_top_srcdir/configure])

where configure bombs out with the compiler not being able to
create executables (due to gcc not understanding -no-undefined).

I see my regular test are based on 3.4.5, sometime with 4.4 .
I just tested with 4.6 and configure bombs.


So with oldest version gcc just warn as config.log show
..
configure:3695: i386-mingw32msvc-gcc --version 5
i386-mingw32msvc-gcc (GCC) 3.4.5 (mingw special)
..
configure:3726: checking whether the C compiler works
configure:3748: i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall 
-L/opt/mingw/lib -no-undefined conftest.c  5

i386-mingw32msvc-gcc: unrecognized option `-no-undefined'
configure:3752: $? = 0
configure:3800: result: yes
..



So, the patch upgrades this completely bogus skip to a pass on
real MinGW.

With newer gcc versions only. Probably behavior is changed in 4.5.

So patch is required.



Cheers,
Peter



Roumen

Re: [PATCH] tests: skip with-pic test when no real pic flag is used.

[Roumen Petrov]

Peter Rosin wrote:

On 2012-09-19 21:43, Roumen Petrov wrote:

Peter Rosin wrote:

* tests/with-pic.at: Windows uses -DDLL_EXPORT -DPIC as the pic
flag, but never applies it to static libraries. Cater for this
and skip if no real pic flag is in use.

I'm not sure that this test is suitable for mingw host.



Signed-off-by: Peter Rosin p...@lysator.liu.se
---
   tests/with-pic.at |   11 ++-
   1 files changed, 10 insertions(+), 1 deletions(-)

Ok to push?

No as libtool should define -DPIC and for mingw host pic flag is -DDLL_EXPORT

The test skips on MinGW with the patch, w/o the patch it
fails. You are first saying that the test is not suitable
for MinGW (implying that a skip is in order), and then you
don't like the patch (implying that a fail is good news).
You don't make any sense.

So, what do you mean?
On woe libtool define -DDLL_EXPORT as pic flag . So the value is 
pic_flag= -DDLL_EXPORT -DPIC
On some other platform PIC default. I don't have asses to those 
platforms and I could guess that the value is pic_flag=-DPIC, i.e. 
only wit defines.


If I understand patched code properly, skip the test if pic_flag contain 
only defines. This mean that other platform will be skipped too.


What about to skip test only if DLL_EXPORT is in pic_flag ?


Cheers,
Peter


Roumen

Re: restore EXPORT check

[Roumen Petrov]

Ping ?

Roumen Petrov wrote:

Hi,
now export test crash on mingw cross build as one of the patches change
!= to = when swap sides of test expression . As result incorrect
export file (asyms) is used.

Roumen

Re: Bad LD_LIBRARY_PATH set in the libtool wrapper

[Roumen Petrov]

Sam Varshavchik wrote:
My source tree builds two libraries, from two separate directories in 
the source tree.


libxtls.la gets linked against libx.la in a different directory, as 
well as some system libraries in /usr/local/lib. Makefile.am declares 
thusly:


libxtls_la_LIBADD=../base/libx.la
libxtls_la_LDFLAGS=-version-info 1 $(GNUTLS_LIBS) $(GCRYPT_LIBS) 
-lpthread
libtool use LDFLAGS before LIBADD as result paths form LDFLAGS will be 
used first.


Move $(GNUTLS_LIBS) $(GCRYPT_LIBS) -lpthread  to LIBADD adn try again.

Roumen


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

Re: PATCH: Add x32 support to _LT_ENABLE_LOCK

[Roumen Petrov]

H.J. Lu wrote:

Hi,

Here is a patch to update _LT_ENABLE_LOCK to support x32:

https://sites.google.com/site/x32abi/home

which is the 32bit ABI for x86-64.  Binutils 2.22 supports -m elf32_x86_64
for x32.


H.J.


It issue same as 
http://lists.gnu.org/archive/html/libtool/2011-10/msg00019.html


Roumen

restore EXPORT check

[Roumen Petrov]

Hi,
now export test crash on mingw cross build as one of the patches change 
!= to = when swap sides of test expression . As result incorrect 
export file (asyms) is used.


Roumen
From e6f2bddecb4cb9f7fb7a289a15f7e6882f56f395 Mon Sep 17 00:00:00 2001
From: Local lo...@example.net
Date: Thu, 1 Dec 2011 00:38:16 +0200
Subject: [PATCH] restore EXPORT test after syntax-check:r
   fix violations and implement sc_prohibit_test_const_follows_var
   from Mon, 21 Nov 2011 11:35:20 +0700

---
 build-aux/ltmain.m4sh |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/build-aux/ltmain.m4sh b/build-aux/ltmain.m4sh
index 3af476a..d618d7f 100644
--- a/build-aux/ltmain.m4sh
+++ b/build-aux/ltmain.m4sh
@@ -7436,7 +7436,7 @@ EOF
 	cygwin* | mingw* | cegcc*)
 	  if test -n $export_symbols  test -z $export_symbols_regex; then
 	# exporting using user supplied symfile
-	if test EXPORTS = `$SED 1q $export_symbols`; then
+	if test EXPORTS != `$SED 1q $export_symbols`; then
 	  # and it's NOT already a .def file. Must figure out
 	  # which of the given symbols are data symbols and tag
 	  # them as such. So, trigger use of export_symbols_cmds.
-- 
1.7.1

Re: [PATCH 2/7] syntax-check: fix violations and implement sc_useless_quotes_in_assignment.

[Roumen Petrov]

Gary V. Vaughan wrote:
[SNIP]

diff --git a/bootstrap.conf b/bootstrap.conf
index 6f0f0c3..c3491b5 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -77,13 +77,13 @@ gnulib_modules='

  # Extra gnulib files that are not in modules, which override files of
  # the same name installed by other bootstrap tools.
-gnulib_non_module_files=$gnulib_non_module_files'
+gnulib_non_module_files=$gnulib_non_module_files'
  doc/COPYINGv2
  doc/fdl.texi
   

[SNIP]
hmm, origin is only with end apostrophe .

Next one is


 # Extend the existing usage message
-usage_message=$usage_message'
+usage_message=$usage_message'

.
May be exist more places. I did not check rest of the file.


Roumen

bootstrap --copy

[Roumen Petrov]

Hello Gary,

After monster updates in repository please could you help me to 
bootstrap libtool.
I don't like to create symbolic links, so I use --copy argument , but 
since 2011-11-08 it does not work.


The command is
./bootstrap \
  --copy \
  --force \
  --gnulib-srcdir=

Output is:
Current branch  is up to date.
Usage: bootstrap MACRO_NAME FILE [...]
Try `bootstrap --help' for more information.
bootstrap: error: unrecognised option: `--copy'


$ ./bootstrap --help
bootstrap MACRO_NAME FILE [...]

Bootstrap this package from checked-out sources.

Common Bootstrap Options:
  -c, --copy copy files instead of creating symbolic links.
  --debugenable verbose shell tracing
.


Best Regards,
Roumen Pertov


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

Re: Support 64-bit default GCC on Solaris/x86

[Roumen Petrov]

Rainer Orth wrote:

In version 4.7, GCC will gain a 64-bit default Solaris/x86
configuration, similar to the existing sparcv9-sun-solaris2
configurations.  In order for that to work with GNU ld (Sun ld works out
of the box), I had to make the following minor patch to libtool.m4.

This patch has been tested with a slightly earlier version already
included in the gcc repository for Go support.  There's an effort
underway to upgrade the libtool in gcc to 2.4.2.  A gcc bootstrap with
64-bit gld and this patch included completed without regressions.

If the patch is accepted, it would be good if it could be included in
libtool 2.4.3 so by the time gcc 4.7 is released, a corresponding
version of libtool is available.

Thanks.

Rainer


2011-10-31  Rainer Orthr...@cebitec.uni-bielefeld.de

* libltdl/m4/libtool.m4: Handle x86_64-*-solaris2.1[0-9]* like
i?86-*-solaris* when determining GNU ld flags to pass for 64-bit
objects.


hmm,
Eric PAIRE post a patch . Summary could be found  in this thread
http://lists.gnu.org/archive/html/libtool/2011-10/msg00017.html
Note Eric's patch is for *kfreebsd* and  *linux* and does not cover solaris.

My question is what is result of  libtool regression test if instead to 
add  x86_64-*-... you replace $host by $build one line above ?


Roumen

Re: Obsoleting LT_SCOPE

[Roumen Petrov]

Hi Gary,

Gary V. Vaughan wrote:

Hi Chuck,

I note that no other GNU projects that I'm aware of jump through all the
__declspec hoops that the libltdl API tries to provide through LT_SCOPE.
Is any of this stuff still required on any non-museum Windows compiler
that would break if I removed it?
[]
   
The export decorator cannot be removed as is unknow how one project will 
build and try to export symbols.


Please find attached file bootstrap.sh with test cases that show export 
functionality on windows platform gcc compiler - function export 
depend from export statement and export attribute:
Test cases 1 are without export decorator as 1x export only one of 
functions. Application 1x fail to link
Test cases 2 are with export attribute as 2x export only one of 
functions. Boot application will be linked due explicitly defined export 
attribute.


Export of variables is other case .

Also if export attribute is applied only to variables if I remember 
function will not be exported.



Regards,
Roumen



bootstrap.sh
Description: Bourne shell script


bootstrap.sh.gz
Description: GNU Zip compressed data
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool, multilib and test duplicate convenience archive names

[Roumen Petrov]

Hi Andreas and Bo,

Please could you clarify build of 64-bit system for 32 bit.


Roumen Petrov wrote:

Hello All,

I wonder how to build and test on a 64 bit platform a 32 bit libtool 
version.


First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux 
with CC and CXX set to 'gcc|g++ -m32', i.e. multilib .


The libtool regression suite fail in test case :
25: duplicate convenience archive names FAILED 
(duplicate_conv.at:83)


From testsuite.log:

.../libtool-2.4.2/tests/duplicate_conv.at:83: $LIBTOOL --mode=link 
--tag=CC $CC $CFLAGS $LDFLAGS -o cee.$OBJEXT c.lo a/liba.la b/liba.la

stderr:
.../ld: Relocatable linking with relocations from format elf32-i386 
(.libs/c.o) to format elf64-x86-64 (cee.o) is not supported

stdout:
libtool: link: .../ld -r -o cee.o  .libs/c.o   --whole-archive 
a/.libs/liba.a b/.libs/liba.a --no-whole-archive



Eric PAIRE post a patch about linker emulation mode - ref.
http://lists.gnu.org/archive/html/bug-libtool/2011-06/msg1.html .


Based on Eric's suggestion I try to build without to set --host, i.e. 
as native build for x86_64-gnu-linux with gcc|g++ -m32 as compilers.


As result -m elf_i386 is added to linker (LD) and libtool regression 
test pass with:

114 tests behaved as expected.
12 tests were skipped.


Any thought on this ?


Traced to

2002-11-18 Andreas Jaeger a...@suse.de, Bo Thorsen b...@suse.de

* libtool.m4: Support linking of 32-bit libraries with ld

on the x86-64, ppc64, s390x and sparc64 GNU/Linux systems.



Roumen



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

libtool, multilib and test duplicate convenience archive names

[Roumen Petrov]

Hello All,

I wonder how to build and test on a 64 bit platform a 32 bit libtool 
version.


First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux with 
CC and CXX set to 'gcc|g++ -m32', i.e. multilib .


The libtool regression suite fail in test case :
25: duplicate convenience archive names FAILED 
(duplicate_conv.at:83)


From testsuite.log:

.../libtool-2.4.2/tests/duplicate_conv.at:83: $LIBTOOL --mode=link 
--tag=CC $CC $CFLAGS $LDFLAGS -o cee.$OBJEXT c.lo a/liba.la b/liba.la

stderr:
.../ld: Relocatable linking with relocations from format elf32-i386 
(.libs/c.o) to format elf64-x86-64 (cee.o) is not supported

stdout:
libtool: link: .../ld -r -o cee.o  .libs/c.o   --whole-archive 
a/.libs/liba.a b/.libs/liba.a --no-whole-archive



Eric PAIRE post a patch about linker emulation mode - ref.
http://lists.gnu.org/archive/html/bug-libtool/2011-06/msg1.html .


Based on Eric's suggestion I try to build without to set --host, i.e. as 
native build for x86_64-gnu-linux with gcc|g++ -m32 as compilers.


As result -m elf_i386 is added to linker (LD) and libtool regression 
test pass with:

114 tests behaved as expected.
12 tests were skipped.


Any thought on this ?


Regards,
Roumen

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

Re: [PATCH] tests: import variables for MSVC.

[Roumen Petrov]

Charles Wilson wrote:

On 9/24/2010 8:06 PM, Roumen Petrov wrote:


I would like to propose different macros for export/import of variables
in format:

#define XXX(type)decorator_before type decorator_after


Why?  Peter's formula is practically universal in most packages I have
seen (ncurses is the only exception that springs to mind).  What
advantage does using an unusual decorator structure bring?

It's not as if we're going to, in our demo/test code, start using
__stdcall decorator_afters, are we?  (Remember that we're only talking
about how the test code is structured, not how libtool requires client
code to be written.  Clients would still be free if they chose to, to
use XXX(type) macros).

--
Chuck


Because #define XXX(type)decorator_before type decorator_after is 
easy to be adapted to every compiler:

- some will accept both :  __export int and int __export
- other only support :  int __export
and so on.

For the define XXX(type) check apache source

Roumen

Re: [PATCH] tests: import variables for MSVC.

[Roumen Petrov]

I sent my email before to finish, sorry.

Roumen Petrov wrote:

Ralf Wildenhues wrote:

* Peter Rosin wrote on Fri, Sep 24, 2010 at 02:44:25PM CEST:

[SNIP]

I'll let Chuck and you hash out and decide all the details on this.

One question though: will all of these '#ifdef _MSC_VER' cases need
changing as soon as we add support for yet another w32 compiler? In
that case, I think the strategy should be reconsidered. The idea is
that the sources should ideally not need any, or at least not many,
changes in the future. Relying on compiler defines seems like a
suboptimal strategy, and should only be done if there is no other way.


I would like to propose different macros for export/import of variables
in format:

#define XXX(type) decorator_before type decorator_after



I sent my email before to finish, sorry.

Next in code to replace int foo with XXX(int) foo.

About pre-processor flags - better is C code to start with #define 
BUIILD_FOO instead -DBUIILD_FOO in makefile.


Roumen

Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.

[Roumen Petrov]

Peter Rosin wrote:

Den 2010-09-18 00:04 skrev Roumen Petrov:

Hi Peter,

Peter Rosin wrote:

Hi!

need_lib_prefix.at currently fails with MSVC.


Hmm probably test fail as shared library is build without -no-undefined  flag.

Did libtool MSC allow creation of shared libraries without -no-undefined ?

On windows platforms (msc, gcc(mingw*)) may be the test require some PATH 
magics.
(as example like func_fix_path from static.at test)


You are barking up the wrong tree, since:

1. The test passes on MinGW and Cygwin with gcc, if wouldn't do that if
-no-undefined was the cause of the fail.




2. The patch in the old quoted message makes the test pass on MSVC, which
it wouldn't do if -no-undefined was the cause of the fail.

PATH magic is not relevant if -no-undefined is not passed, since everything
should be static in that case (no dlls created).


But the libtool command contain -rpath so the test build shared and 
static libraries .



1) linux native build:
$ cd .../testsuite.dir/086
$ strace -f ./main 21 | grep foo
open(/.libs/tls/i686/libfoo1.so, O_RDONLY) = -1 ENOENT (No such 
file or directory)
open(/.libs/tls/libfoo1.so, O_RDONLY) = -1 ENOENT (No such file or 
directory)
open(/.libs/i686/libfoo1.so, O_RDONLY) = -1 ENOENT (No such file 
or directory)

open(/.libs/libfoo1.so, O_RDONLY) = 3
open(/.libs/libfoo2.so, O_RDONLY) = 3
write(1, libfoo1: 2\nlibfoo2: 3\n, 22libfoo1: 2
libfoo2: 3

$ ls .../testsuite.dir/086/.libs/
foo1.la@  foo1.lai  foo1.o  foo2.o  libfoo1.a  libfoo1.so*  libfoo2.a 
libfoo2.la@  libfoo2.lai  libfoo2.so*  lt-main*  main*  mainS.o


Result test pass. Both static and shared libraries are created. The 
executable load shared.



2) In cross-build env. verbose more:

libtool: link: ( cd .libs  rm -f foo1.la  ln -s ../foo1.la 
foo1.la )
/X/need_lib_prefix.at:165: $LIBTOOL --mode=link $CC -module 
-avoid-version $CFLAGS $LDFLAGS -o libfoo2.la foo2.lo -rpath $instdir/lib

stderr:
libtool: link: warning: undefined symbols not allowed in 
i386-pc-mingw32msvc shared libraries



$ ls .libs/
foo1.la@  foo1.lai  foo1.o  foo2.o  libfoo1.a  libfoo2.a  libfoo2.la@ 
libfoo2.lai  lt-main.c  main.exe*  main.exeS.o  main_ltshwrapper


Result the test pass. Shared libraries are not created.


I'm not convinced that test is correct for windows platforms.


3)  In cross-build env. and test patched with -no-undefined :
$ ls .libs/
foo1.la@  foo1.o  libfoo1.a libfoo1.dll.a  libfoo2.dll* 
libfoo2.la@  lt-main.c  main.exeS.o
foo1.lai  foo2.o  libfoo1.dll*  libfoo2.a  libfoo2.dll.a 
libfoo2.lai  main.exe*  main_ltshwrapper


Result test skipped = failed.

3.1)
$ cd .../testsuite.dir/086/.libs/
$ ./main.exe
libfoo2: 3
function `f' not found: Procedure not found
error during preloading.

$ strace -f ./main.exe 21 | grep foo
[pid   353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755, 
st_size=809650, ...}) = 0
[pid   353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755, 
st_size=809650, ...}) = 0
[pid   353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755, 
st_size=809650, ...}) = 0
[pid   353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755, 
st_size=809650, ...}) = 0
[pid   353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755, 
st_size=809650, ...}) = 0
[pid   338] open(/086/.libs/libfoo1.dll, 
O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 78
[pid   353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755, 
st_size=809650, ...}) = 0

[pid   353] open(/086/.libs/libfoo1.dll, O_RDONLY) = 9
[pid   353] open(/opt/wine/1.3.1/lib/wine/libfoo1.dll.so, O_RDONLY) = 
-1 ENOENT (No such file or directory)
[pid   353] open(/opt/wine/1.3.1/lib/wine/libfoo1.dll.so, 
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid   353] stat64(/086/.libs/libfoo2.dll, {st_mode=S_IFREG|0755, 
st_size=809656, ...}) = 0
[pid   353] stat64(/086/.libs/libfoo2.dll, {st_mode=S_IFREG|0755, 
st_size=809656, ...}) = 0
[pid   353] stat64(/086/.libs/libfoo2.dll, {st_mode=S_IFREG|0755, 
st_size=809656, ...}) = 0
[pid   353] stat64(/086/.libs/libfoo2.dll, {st_mode=S_IFREG|0755, 
st_size=809656, ...}) = 0
[pid   353] stat64(/086/.libs/libfoo2.dll, {st_mode=S_IFREG|0755, 
st_size=809656, ...}) = 0
[pid   338] open(/086/.libs/libfoo2.dll, 
O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 79
[pid   353] stat64(/086/.libs/libfoo2.dll, {st_mode=S_IFREG|0755, 
st_size=809656, ...}) = 0

[pid   353] open(/086/.libs/libfoo2.dll, O_RDONLY) = 9
[pid   353] open(/opt/wine/1.3.1/lib/wine/libfoo2.dll.so, O_RDONLY) = 
-1 ENOENT (No such file or directory)
[pid   353] open(/opt/wine/1.3.1/lib/wine/libfoo2.dll.so, 
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid   353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755, 
st_size=809650, ...}) = 0
[pid   353] stat64(/086/.libs/libfoo1.dll, {st_mode=S_IFREG|0755, 
st_size=809650, ...}) = 0
[pid   353] stat64(/086/.libs/libfoo2.dll, {st_mode=S_IFREG|0755

Re: w32 pending?

[Roumen Petrov]

Ralf Wildenhues wrote:

Hi Charles,

* Charles Wilson wrote on Thu, Sep 16, 2010 at 08:47:52PM CEST:

[cygwin|mingw] Fix order of PATH manipulation in cwrapper

* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call
lt_update_exe_path before lt_update_lib_path, to ensure that the local
OBJDIR(s) supersedes any -rpath directories.
Reported by Jon Turney...


This looks ok, but wouldn't the shell wrapper need this as well,
seeing that it could be run on w32 too (IIRC)?

Also, of course, testsuite exposure should follow eventually.

Thanks,
Ralf


--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -3677,8 +3677,12 @@ EOF

lt_setenv (BIN_SH, xpg4); /* for Tru64 */
lt_setenv (DUALCASE, 1);  /* for MSK sh */
-  lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE);
+  /* For Windows, this order is important: it ensures that any -rpath
+ values are prepended first, and then the local OBJDIR directory(ies)
+ is prepended second -- ensuring that just-built libraries supersede
+ installed ones. */
lt_update_exe_path (EXE_PATH_VARNAME, EXE_PATH_VALUE);
+  lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE);

lt_debugprintf (__FILE__, __LINE__, (main) lt_argv_zero: %s\n,
   nonnull (lt_argv_zero));





+1 This will fix the case reported 
http://lists.gnu.org/archive/html/bug-libtool/2009-12/msg00037.html; - 
the report is with attached test case.


Roumen

Re: [PATCH] Skip need_lib_prefix.at on systems without lib prefix on libraries.

[Roumen Petrov]

Hi Peter,

Peter Rosin wrote:

Hi!

need_lib_prefix.at currently fails with MSVC.


Hmm probably test fail as shared library is build without -no-undefined 
 flag.


Did libtool MSC allow creation of shared libraries without -no-undefined ?

On windows platforms (msc, gcc(mingw*)) may be the test require some 
PATH magics.

(as example like func_fix_path from static.at test)



I think the test
is there to ensure that weird systems continue to work even
if the testsuite is running on a normal system. weird in
this case are systems with need_lib_prefix set to unknown and
normal are those with it set to no. However, there are
even weirder systems where need_lib_prefix should perhaps be
set to never (i.e. MSVC) but that currently simply sets it
to no. never would perhaps be more appropriate since preopen
doesn't work right if libs have a lib prefix.




I think OS/2 is
affected in the same way as MSVC, but I have no means to test
that.

The below patch makes the need_lib_prefix.at test skip for the
even weirder systems, i.e. those where libname_spec does not
prefix library names with lib.


The test use libtool -module flag and thus libtool won't complain if 
library is created without lib prefix.



Ok to push?


No if -no-undefined  and PATH magic resolve failure in this test.

[SNIP]


Roumen

Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

[Roumen Petrov]

Ralf Wildenhues wrote:

Hi Charles,


[SNIP]

+  func_wine_to_win32_path_result=$1
+  if test -n $1; then
+# Unfortunately, winepath does not exit with a non-zero
+# error code, so we are forced to check the contents of
+# stdout. On the other hand, if the command is not
+# found, the shell will set an exit code of 127 and print
+# *an error message* to stdout. So we must check for both
+# error code of zero AND non-empty stdout, which explains
+# the odd construction:


Starting from wine 1.3.1 wine path always output paths:
Lets wine is correctly configured (Z: drive is linked to the file system 
root):

$ cd $WINEPREFIX/dosdevices
$ winepath -w `pwd`
Z:\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices

Now lets remove link:
$ rm z:
$ winepath -w `pwd`
\\?\unix\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices

So sed should remove leading //?/unix



Peter, are you reading this?  Looks like a TODO item for
automake/lib/compile.  ;-)


+func_wine_to_win32_path_tmp=`winepath -w $1 2/dev/null`
+if test $? -eq 0  test -n ${func_wine_to_win32_path_tmp}; then


I'll just note that some shells ((d?)ash 0.2) fail to propagate the exit
status of an assignment.  No need to change the code, but users should
have a decent shell for this.


+  func_wine_to_win32_path_result=`$ECHO $func_wine_to_win32_path_tmp |
+$SED -e $lt_sed_naive_backslashify`
+else
+  func_wine_to_win32_path_result=


The way this is coded, correctness relies on the fact that all code
paths that invoke this function do eventually check for non-emptiness
of the result.


+fi
+  fi
+}
+# end: func_wine_to_win32_path

[SNIP]

Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

[Roumen Petrov]

Gary V. Vaughan wrote:

Hi Roumen,

On 22 May 2010, at 03:26, Roumen Petrov wrote:

Gary V. Vaughan wrote:


The Libtool Team is pleased to announce release candidate 2.2.7b of GNU
Libtool.  If there are no serious deficiencies reported in this release,
it will be renumbered as 2.2.8 and re-released (otherwise, we'll fix
any problems and put out 2.2.7d first).

[SNIP]

I not sure that this is resolved : 
http://lists.gnu.org/archive/html/bug-libtool/2010-01/msg00028.html;


Can you confirm that the testcase at the end of this link still shows a
failure on Windows? I haven't used a Windows machine in almost a decade,
and don't have access to one.


I don't have windows host and for some test I must wait feedback from 
friends.


I'm not sure that test case is only windows issue. Yes I know that 
similar test pass on elf shared libraries. Right now I'm not able to 
write test that fail on linux except the case described here 
http://www.aleksey.com/pipermail/xmlsec/2010/008866.html
The patch that resolve issue for xmlsec is to move libxmlsec1.la as 
dependend library at end:

 libxmlsec1_openssl_la_LIBADD = \
-   ../libxmlsec1.la \
$(OPENSSL_LIBS) \
$(LIBXSLT_LIBS) \
$(LIBXML_LIBS) \
+   ../libxmlsec1.la \
$(NULL)
This build against dependent libraries with and without la-files 
(openssl is one of them) and one of attachments is difference : libtool 
output before and after patch.




Is the problem due to Windows searching for DLLs along $PATH?  And, if so, do
you know whether the current directory is always searched first irrespective
of the PATH setting?
If your answers are 'yes' and 'no' respectively, I might be able to look
into the wrapper script code and figure out why PATH is not being set
correctly.  In either case, I'll be happy to accept a patch :)


As I post here 
http://lists.gnu.org/archive/html/bug-libtool/2009-12/msg00037.html
 very simple issue is to prepend to PATH value of EXE_PATH_VALUE first 
and LIB_PATH_VALUE second.




Cheers,



Roumen

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

Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).

[Roumen Petrov]

Gary V. Vaughan wrote:

GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl,
which hides the complexity of loading dynamic runtime libraries
(modules) behind a consistent, portable interface.

The Libtool Team is pleased to announce release candidate 2.2.7b of GNU
Libtool.  If there are no serious deficiencies reported in this release,
it will be renumbered as 2.2.8 and re-released (otherwise, we'll fix
any problems and put out 2.2.7d first).

[SNIP]

I not sure that this is resolved : 
http://lists.gnu.org/archive/html/bug-libtool/2010-01/msg00028.html;


Roumen

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

Re: Extend libtool dll namespaces for mingw-w64

[Roumen Petrov]

JonY wrote:

On 1/31/2010 02:14, Roumen Petrov wrote:

I don't understand request as the usually final result is
.../libfool.la
.../libfool.dll.a
.../libfool.dll
.../libfool.a

Also note that makefiles the macros(variables) are libfoo_.
Did the requester expect if target is libfoo_ make command to search
for libYYfoo_ or may be requested will contact all developers as
will convince to use macros like @libpre...@foo_ in makefiles and
LIBPREFIX is set by configure ?
Uhh ...



Hi,

If you looked at the concept patch, it changes how libtool names the
DLL by soname_spec, libname_spec stays the same. The makefiles do not
see the DLLs at all, only the .la files if libtool is in use. The .la
filenames stay the same.

That is the whole point of libtool, devs don't need to bother about
platform specific details and implementation of shared libs.



Uhh and the libtool install la files and process installed. So after 
installation xx-bit will override yy-bit.


Roumen



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

Re: Extend libtool dll namespaces for mingw-w64

[Roumen Petrov]

I don't understand request as the usually final result is
.../libfool.la
.../libfool.dll.a
.../libfool.dll
.../libfool.a

Also note that  makefiles the macros(variables) are libfoo_.
Did the requester expect if target is libfoo_ make command to search 
for libYYfoo_  or may be requested will contact all developers as 
will convince to use macros like @libpre...@foo_ in makefiles and 
LIBPREFIX is set by configure ?

Uhh ...

Roumen


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

Re: Extend libtool dll namespaces for mingw-w64

[Roumen Petrov]

Matěj Týč wrote:

On Tue, 2010-01-26 at 23:26 +0800, JonY wrote:
...

I suggest the following naming scheme.

mingw.org:  libname-major.dll (unchanged)
Cygwin: cygname-major.dll (unchanged)
mingw-w64(64):  lib64name-major.dll
mingw-w64(32):  lib32name-major.dll

libtool should also check if GCC -m32 or -m64 is used, and select
the proper namespace accordingly (mingw-w64 GCC can do multilib).

Comments?



AFAIK if you use automake, you have to have something like the following
line in Makefile.am:
lib_LTLIBRARIES = libfoo.la
This means that the 'lib' prefix doesn't actually come from mingw, but
from your automake setup, right?


No http://lists.gnu.org/archive/html/libtool/2007-07/msg00064.html

[SNIP]

This should allow some library name modifications as proposed here.
What I would like to see one day though is that I am able to produce a
library named foo.dll instead of libfoo.dll without any workarounds.
That lib prefix tends to scare Windows users, but I am sure you know
that too :-) I was not aware of possible conflicts that were mentioned
here though.



I'm not sure that idea for lib{64|32} is so good.
As I know for 32 bit process  64 bit microsoft windows os will return 
%WINDOWS%\SysWOW64 as system folder. For 64 bit process it is 
%WINDOWS%\System32 (no comment on design), Program Files for 64-bit 
and Program Files (x86)(?) for 32-bit (more on MSDN).


I'm not sure that libtool has to know how lets call it redirection work.

Roumen


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

Re: Extend libtool dll namespaces for mingw-w64

[Roumen Petrov]

Matěj Týč wrote:
[SNIP]

Wow, this is interesting.
I remember that one guy asked about the dll prefix and he has been
advised to strip the prefix from the library name and add the '-module'
flag to libtool in order to silence complaints.

[SNIP]
-module flag will install dll in $libdir and without flag in 
$libdir/..bin for stable release .


Roumen


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

Re: libtool did not search ws2_32.dll

[Roumen Petrov]

Kuang-Chun Cheng wrote:

Hi,

I'm using mingw cross compiler (with GNU autotools) under Linux to build DLL.
One of the package I build is gnet2-2.0.8 which will link winsock library.
Everything is OK, the DLL is created under Linux.

When I copy the library to WinXP and use gnet2-2.0.8 to create
network my app.  The libtool complain that it can't handle -lws2_32
and show me error message:

*** Warning: linker path does not have real file for library -lws2_32.
*** 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

I try to trace what's wrong in libtool ... and found that libtool try to search
libws2_32.dll under couple paths ... but libtool does not know the
real DLL is c:\windows\system32\ws2_32.dll !!


cross compiler ?

In cross-environment import library is 
.../TARGET_ALIAS/lib/libws2_32.a along with other import libraries.




If I copy/rename c:\windows\system32\ws2_32.dll to c:\mingw\bin\libws2_32.dll
then everything work OK.

Is this expected ? or a libtool bug ?


Not sure what is cause of issue. The process of you copy is not clear.
... and use gnet2-2.0.8 to create ... .. Warning: linker path does 
not have real file for library -lws2_32  Look like issue with 
native build and missing installation of w32api dev. package.



Thanks
KC


Roumen


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

Re: libtool mail lists

[Roumen Petrov]

Hi Ralf,

Ralf Wildenhues wrote:

Hi Roumen,

* Roumen Petrov wrote on Sat, Jan 09, 2010 at 04:33:00PM CET:

This page http://www.gnu.org/software/libtool/ currently refer to
site http://mail.gnu.org/;... for libtool related mail lists . It
seems to that correct site is http://lists.gnu.org/...;.

Also not all links point to final location as example
http://lists.gnu.org/pipermail/libtool-patches/; (note
s/mail/lists/ ) it moved permanently to
href=http://lists.gnu.org/archive/html/libtool-patches;.


These should be fixed now.  Thanks for reporting them!

Cheers,
Ralf



As example you could test missing /moved with wget
$ wget http://www.gnu.org/software/libtool/ -O libtool-index.html
$  wget --spider --force-html --verbose=off --debug=off 
--base=http://www.gnu.org/software/libtool/ -i libtool-index.html


After fixes for libtool lists the result is :
https://my.fsf.org/associate/support_freedom?referrer=4052:
Remote file does not exist -- broken link!!!

May be it is
https://my.fsf.org/associate/support_freedom/join_fsf?; or
https://my.fsf.org/associate/support_freedom/; ?


Also with verbose and/or debug set you could find some references with 
301 Moved Permanently response first (Note not so important). As 
example for .../XXX (.../manual and .../libtool-commit)  server 
respond moved to .../XXX/.


Roumen


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

libtool mail lists

[Roumen Petrov]

Hi libtool webadmin,

This page http://www.gnu.org/software/libtool/ currently refer to site 
http://mail.gnu.org/;... for libtool related mail lists . It seems to 
that correct site is http://lists.gnu.org/...;.


Also not all links point to final location as example
http://lists.gnu.org/pipermail/libtool-patches/; (note s/mail/lists/ ) 
it moved permanently to 
href=http://lists.gnu.org/archive/html/libtool-patches;.


Roumen


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

Re: rpath

[Roumen Petrov]

Ralf Wildenhues wrote:

* Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 08:04:27AM CET:

Ralf Wildenhues wrote on 10/12/2009 06:16:40:

* Joakim Tjernlund wrote on Thu, Dec 10, 2009 at 12:50:14AM CET:

Ralf Wildenhues wrote on 08/12/2009 20:13:13:

   ./configure --prefix=/opt/x/y
   make
   make install DESTDIR=/some/dir


I getting back to this now that my libtool problem seem to be over.
Pondring on DESTDIR, I wonder if there is a way to set a default DESTDIR at
configure time so one does have to remember/type DESTDIR=.. at every make


No, but you can just `export DESTDIR' in your environment.


Yeah, but that isn't going to work in here, too easy to get wrong. I image
I could add something to configure.ac that will allow me to set it at configure
time? Not sure what would work though, any ideas?


Well you can
   AC_ARG_VAR([DESTDIR], [perform staged installation using DESTDIR])


This  require makefiles generated by configure script to contain line 
like this one:

destd...@destdir@
otherwise it is useless 

I won't like to discuss more what happen if user forget DESTDIR as it is 
not required at every make.  DESTDIR is usefull only if user would 
like to create distribution archive and for every package DESTDIR is 
good to point to clean directory tree.
Other point is that on unix(linux) user work under unprivileged account 
and only for install is required a  privileged account(root).




but it will require your users to either specify it at configure time
already, or, if they want to specify it at `make install' time only,
use GNU make.

Cheers,
Ralf



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

abs-bindir Was: bindir for libtool

[Roumen Petrov]

Ralf Wildenhues wrote:

Hi Charles,

[SNIP]


I agree.


I'd suggest, perhaps, adding a *different* libtool option, e.g.
-abs-bindir, that works semantically as Roumen desires. Then, later, gcc
may choose to use either -bindir or -abs-bindir, whatever seems best to
them. I'm probably overlooking something with this suggestion, but I'd
prefer if, rather than extending this thread and delaying #1 above any
longer, we postpone discussion of how what I've just said is all wrong
until after #1, and we're into the discussion of #2.


We can think about -abs-bindir.  #1 is waiting to be committed to GNU
Libtool only for the finishing of DaveK's copyright papers; then I will
commit it (along with a couple of fixes, one of which has shown up in
GCC already and the other is in Libtool testsuite-only code).


Just updated to master, but without tests - I don't have time to write 
them , may be next month :(


Regards
diff --git a/ChangeLog b/ChangeLog
index caf125a..ebabba8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2009-09-28  Roumen Petrov  bugtr...@roumenpetrov.info
+
+	Control where to place shared libraries for system without
+	shared library path variable different from PATH.
+	* libltdl/config/ltmain.m4sh (func_mode_help):
+	Document -abs-bindir.
+	(func_mode_link, func_mode_install, func_mode_uninstall):
+	Accept new -abs-bindir option and use it, if supplied.
+	* libltdl/m4/libtool.m4: support absolute path for DLLs.
+	Pass environment variable DESTDIR to post{un}install commands.
+	* libltdl/ltdl.c: support absolute path for dynamic module.
+	* NEWS: Update.
+
 2009-11-01  Ralf Wildenhues  ralf.wildenh...@gmx.de
 
 	Fix func_normal_abspath sed script for Solaris.
diff --git a/NEWS b/NEWS
index 80f0413..d0b88a1 100644
--- a/NEWS
+++ b/NEWS
@@ -16,6 +16,8 @@ New in 2.2.8 2009-??-??: git version 2.2.7a, Libtool team:
 runs on Windows with popup windows in the middle, and `check-interactive'
 for the complement set of tests.
   - New link mode flag -bindir to specify the location for installed PE DLLs.
+  - New flag -abs-bindir for modes link,install,uninstall to specify the
+absolute location for installed PE DLLs.
 
 * Changes in supported systems or compilers:
 
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 91d0800..0a17a41 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1112,7 +1112,9 @@ The following components of INSTALL-COMMAND are treated specially:
   -inst-prefix-dir PREFIX-DIR  Use PREFIX-DIR as a staging area for installation
 
 The rest of the components are interpreted as arguments to that command (only
-BSD-compatible install options are recognized).
+BSD-compatible install options are recognized). Exception is argument
+\`-abs-bindir'. This argument specify where to place shared libraries(DLLs)
+for system without shared library path variable different from PATH.
 ;;
 
   link)
@@ -1131,6 +1133,11 @@ The following components of LINK-COMMAND are treated specially:
   -avoid-versiondo not add a version suffix if possible
   -bindir BINDIRspecify path to binaries directory (for systems where
 libraries must be found in the PATH setting at runtime)
+  -abs-bindir ABS_BINDIR
+specify path to binaries directory (for system without
+shared library path variable different from PATH).
+Symilar to -bindir but without internal relative path
+calculation.
   -dlopen FILE  \`-dlpreopen' FILE if it cannot be dlopened at runtime
   -dlpreopen FILE   link in FILE and add its symbols to lt_preloaded_symbols
   -export-dynamic   allow symbols from OUTPUT-FILE to be resolved with dlsym(3)
@@ -1191,6 +1198,12 @@ Remove libraries from an installation directory.
 RM is the name of the program to use to delete files associated with each FILE
 (typically \`/bin/rm').  RM-OPTIONS are options (such as \`-f') to be passed
 to RM.
+The following components of RM-OPTIONS are treated specially:
+
+  -abs-bindir ABS_BINDIR
+  Use ABS_BINDIR to find shared libraries (DLLs) for system without
+  shared library path variable different from PATH. Used only if
+  FILE is a libtool library.
 
 If FILE is a libtool library, all the files associated with it are deleted.
 Otherwise, only FILE itself is deleted using RM.
@@ -1451,6 +1464,9 @@ test $mode = finish  func_mode_finish ${1+$@}
 # func_mode_install arg...
 func_mode_install ()
 {
+inst_destdir=
+test -n $DESTDIR  inst_destdir=$DESTDIR
+
 $opt_debug
 # There may be an optional sh(1) argument at the beginning of
 # install_prog (especially on Windows NT).
@@ -1477,6 +1493,10 @@ func_mode_install ()
   *) install_cp=false ;;
 esac
 
+# heuristic location of shared libraries for system without
+# shared library path variable different from PATH
+dlbindir=../bin
+
 # We need to accept at least

bindir for libtool

[Roumen Petrov]

Hi All,

I would like to share code and test case performed by me to add bindir 
support to libtool.
The patch for libtool is attached as file libtool-origin-bindir.patch. 
The patch propose absolute path for dlname in la-file.
The attached file bootstrap.sh is the test case for a dlopen 
application. Bootstrap script apply following patched to test source tree .

- libtool-libltdl.patch (non required . help to trace dlopen)
- makefile-bindir_rule.patch - changed to automake rules, i.e. add 
bindir flag to libtool.



Charles Wilson in mails threads add a note that for GNU Coding Standard.
Libtool create lai-files in link mode. So in install mode is too late to 
change prefix,bindir or libdir. libdir in installed la-file point to 
libdir directory as is set before in link mode.


For install mode the above patch install libraries in correct location - 
libdir for library related files and DLL in bindir. Note that 
libdir in la-file left unchanged during install. As result dll can't 
be found even dlname contain relative path. I'm addressing the simple 
case when user try to override prefix for install.



Regards,
Roumen
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index d8c5749..c1c6acc 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1129,6 +1129,8 @@ The following components of LINK-COMMAND are treated specially:
 
   -all-static   do not do any dynamic linking at all
   -avoid-versiondo not add a version suffix if possible
+  -bindir BINDIRspecify path to binaries directory (for systems where
+libraries must be found in the PATH setting at runtime)
   -dlopen FILE  \`-dlpreopen' FILE if it cannot be dlopened at runtime
   -dlpreopen FILE   link in FILE and add its symbols to lt_preloaded_symbols
   -export-dynamic   allow symbols from OUTPUT-FILE to be resolved with dlsym(3)
@@ -1475,6 +1477,10 @@ func_mode_install ()
   *) install_cp=false ;;
 esac
 
+# heuristic location of shared libraries for system without
+# shared library path variable different from PATH
+dlbindir=../bin
+
 # We need to accept at least all the BSD install flags.
 dest=
 files=
@@ -1507,16 +1513,29 @@ func_mode_install ()
 	stripme= -s
 	continue
 	;;
+  -bindir)
+	prev=bindir
+	continue
+	;;
   -*)
 	;;
   *)
 	# If the previous option needed an argument, then skip it.
 	if test -n $prev; then
+	  case $prev in
+	bindir)
+	  dlbindir=$arg
+	  prev=
+	  continue
+	;;
+	*)
 	  if test x$prev = x-m  test -n $install_override_mode; then
 	arg2=$install_override_mode
 	no_mode=false
 	  fi
 	  prev=
+	;;
+	  esac
 	else
 	  dest=$arg
 	  continue
@@ -1696,7 +1715,9 @@ func_mode_install ()
 
 	  # Do each command in the postinstall commands.
 	  lib=$destdir/$realname
-	  func_execute_cmds $postinstall_cmds 'exit $?'
+	  inst_prefix_dir=
+	  test -n $DESTDIR  inst_prefix_dir=$DESTDIR
+	  func_execute_cmds inst_prefix_dir=$inst_prefix_dir~dlbindir=$dlbindir~$postinstall_cmds 'exit $?'
 	fi
 
 	# Install the pseudo-library for information purposes.
@@ -3674,6 +3695,9 @@ func_mode_link ()
 new_inherited_linker_flags=
 
 avoid_version=no
+# heuristic location of shared libraries for system without
+# shared library path variable different from PATH
+dlbindir=../bin
 dlfiles=
 dlprefiles=
 dlself=no
@@ -3766,6 +3790,11 @@ func_mode_link ()
 	esac
 
 	case $prev in
+	bindir)
+	  dlbindir=$arg
+	  prev=
+	  continue
+	  ;;
 	dlfiles|dlprefiles)
 	  if test $preload = no; then
 	# Add the symbol object into the linking commands.
@@ -4027,6 +4056,11 @@ func_mode_link ()
 	continue
 	;;
 
+  -bindir)
+	prev=bindir
+	continue
+	;;
+
   -dlopen)
 	prev=dlfiles
 	continue
@@ -7721,7 +7755,8 @@ EOF
 	  # place dlname in correct position for cygwin
 	  tdlname=$dlname
 	  case $host,$output,$installed,$module,$dlname in
-	*cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) tdlname=../bin/$dlname ;;
+	*cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll)
+	  tdlname=$dlbindir/$dlname;;
 	  esac
 	  $ECHO  $output \
 # $outputname - a libtool library file
@@ -7793,16 +7828,33 @@ func_mode_uninstall ()
 rmforce=
 exit_status=0
 
+# heuristic location of shared libraries for system without
+# shared library path variable different from PATH
+dlbindir=../bin
+
 # This variable tells wrapper scripts just to set variables rather
 # than running their programs.
 libtool_install_magic=$magic
 
+prev=
 for arg
 do
   case $arg in
+  -bindir)
+prev=bindir
+continue
+;;
   -f) RM=$RM $arg; rmforce=yes ;;
   -*) RM=$RM $arg ;;
-  *) files=$files $arg ;;
+  *)
+case $prev in
+  bindir)
+dlbindir=$arg
+prev=
+continue
+;;
+ 

Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.

[Roumen Petrov]

Hi Charles,

Charles Wilson wrote:

Roumen Petrov wrote:


[SNIP]


If you can come up with a mechanism to use absolute paths in dlname,
which does not break any of the known installation modes, works whether
the installation tree(s) are pre-created or NOT, and whether the final
installation tree contains symlinks or NOT, AND solves the issue with
getting DLLs on w32 into the correct directory AND that the installed
.la file correctly describes its location...

Then please show us the code. And the test results. On as many systems
as Dave has, especially including mingw, cygwin, linux, and various
cross environments.


Please find attached file libtool-origin-bindir.patch with my
idea for absolute path in la-file.

[SNIP]

--
Chuck



Roumen
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index d8c5749..381bef5 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1129,6 +1129,8 @@ The following components of LINK-COMMAND are treated specially:
 
   -all-static   do not do any dynamic linking at all
   -avoid-versiondo not add a version suffix if possible
+  -bindir BINDIRspecify path to binaries directory (for systems where
+libraries must be found in the PATH setting at runtime)
   -dlopen FILE  \`-dlpreopen' FILE if it cannot be dlopened at runtime
   -dlpreopen FILE   link in FILE and add its symbols to lt_preloaded_symbols
   -export-dynamic   allow symbols from OUTPUT-FILE to be resolved with dlsym(3)
@@ -1631,10 +1633,10 @@ func_mode_install ()
 	dir=$func_dirname_result
 	dir=$dir$objdir
 
-	if test -n $relink_command; then
-	  # Determine the prefix the user has applied to our future dir.
-	  inst_prefix_dir=`$ECHO $destdir | $SED -e s%$libdir\$%%`
+	# Determine the prefix the user has applied to our future dir.
+	inst_prefix_dir=`$ECHO $destdir | $SED -e s%$libdir\$%%`
 
+	if test -n $relink_command; then
 	  # Don't allow the user to place us outside of our expected
 	  # location b/c this prevents finding dependent libraries that
 	  # are installed to the same prefix.
@@ -1696,7 +1698,7 @@ func_mode_install ()
 
 	  # Do each command in the postinstall commands.
 	  lib=$destdir/$realname
-	  func_execute_cmds $postinstall_cmds 'exit $?'
+	  func_execute_cmds inst_prefix_dir=$inst_prefix_dir~$postinstall_cmds 'exit $?'
 	fi
 
 	# Install the pseudo-library for information purposes.
@@ -3674,6 +3676,9 @@ func_mode_link ()
 new_inherited_linker_flags=
 
 avoid_version=no
+# heuristic location of shared libraries for system without
+# shared library path variable different from PATH
+dlbindir=../bin
 dlfiles=
 dlprefiles=
 dlself=no
@@ -3766,6 +3771,11 @@ func_mode_link ()
 	esac
 
 	case $prev in
+	bindir)
+	  dlbindir=$arg
+	  prev=
+	  continue
+	  ;;
 	dlfiles|dlprefiles)
 	  if test $preload = no; then
 	# Add the symbol object into the linking commands.
@@ -4027,6 +4037,11 @@ func_mode_link ()
 	continue
 	;;
 
+  -bindir)
+	prev=bindir
+	continue
+	;;
+
   -dlopen)
 	prev=dlfiles
 	continue
@@ -7721,7 +7736,8 @@ EOF
 	  # place dlname in correct position for cygwin
 	  tdlname=$dlname
 	  case $host,$output,$installed,$module,$dlname in
-	*cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll) tdlname=../bin/$dlname ;;
+	*cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll | *cegcc*,*lai,yes,no,*.dll)
+	  tdlname=$dlbindir/$dlname;;
 	  esac
 	  $ECHO  $output \
 # $outputname - a libtool library file
diff --git a/libltdl/ltdl.c b/libltdl/ltdl.c
index 80b5675..ea5d51f 100644
--- a/libltdl/ltdl.c
+++ b/libltdl/ltdl.c
@@ -480,7 +480,7 @@ tryall_dlopen_module (lt_dlhandle *handle, const char *prefix,
   int  error	= 0;
   char *filename	= 0;
   size_t   filename_len	= 0;
-  size_t   dirname_len	= LT_STRLEN (dirname);
+  size_t   dirname_len	= (*dlname == '/') ? (size_t)0: LT_STRLEN (dirname);
 
   assert (handle);
   assert (dirname);
@@ -494,7 +494,7 @@ tryall_dlopen_module (lt_dlhandle *handle, const char *prefix,
   if (dirname_len  0)
 if (dirname[dirname_len -1] == '/')
   --dirname_len;
-  filename_len = dirname_len + 1 + LT_STRLEN (dlname);
+  filename_len = (*dlname == '/' ? (size_t)0 : (dirname_len + 1)) + LT_STRLEN (dlname);
 
   /* Allocate memory, and combine DIRNAME and MODULENAME into it.
  The PREFIX (if any) is handled below.  */
@@ -502,7 +502,10 @@ tryall_dlopen_module (lt_dlhandle *handle, const char *prefix,
   if (!filename)
 return 1;
 
-  sprintf (filename, %.*s/%s, (int) dirname_len, dirname, dlname);
+  if (*dlname == '/')
+strncpy (filename, dlname, filename_len + 1);
+  else
+sprintf (filename, %.*s/%s, (int) dirname_len, dirname, dlname);
 
   /* Now that we have combined DIRNAME and MODULENAME, if there is
  also a PREFIX to contend with, simply recurse with the arguments
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 3a65ec4..18710b0 100644

Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.

[Roumen Petrov]

Dave Korn wrote:

Roumen Petrov wrote:


The calculation or relative path to dll is based on function XXX_abspath
that may produce wrong results. 


  No it doesn't.  Like any function, it produces the correct results when
given valid inputs, but if you give it bad input, you get GIGO.


:) :) :-D



I suggest you
go read the fine manual about the realpath and abspath functions, because
until you understand the difference between these two functions you're just
wasting everybody's time. 


:)



*Your suggestion to use realpath instead of abspath
requires magic or time-travel before it is even possible, which is why I will
waste no time on it.*


Reading all above seems to my you mix mail threads and/or lists.



I'm concerned that we can't implement a working portable(cross-platform)
relative path calculation.


  But that is exactly what I have done.  It works, it is in portable code, it
operates the same on all platforms.  It has an implicit requirement that you
do not pass it a path containing a symlink.  As does *everything else* in
autotools.


:) :) :) Dave, you even don't understand what is wrong.



What is better for dlname for installed la-file: absolute or relative path ?


  That you could even ask such a question demonstrates that you don't
understand the subject you are pontificating about.  Go and read up about how
'configure' works and what a prefix is.


Please, countdown before to post (hint: manual is libtool) .



cheers,
  DaveK



Roumen

Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.

[Roumen Petrov]

Charles Wilson wrote:

Roumen Petrov wrote:

Dave Korn wrote:

Roumen Petrov wrote:

[SNIP]


Why?  abspath != realpath.  That's the point.  If you're arguing that
all GNU installation tools should use realpath to canonicalize all paths
before use, well...maybe that discussion should be held, in some other
thread with a broader audience as it affects MUCH more than just
libtool.  But (a) your desired behavior is not the case now, in a lot of
places other than libtool, (b) doing it your way will badly break
DESTDIR installations and any installation where the target installation
directory tree is not fully created at build/installation time (c) and
you'll get a lot of pushback from automake/autoconf on that.

Summary: in what way does Dave's patch make libtool behavior worse than
current?


The calculation or relative path to dll is based on function XXX_abspath 
that may produce wrong results. The algorithm to calculated absolute 
path is acceptable only for DOS like file systems.


Next implementation of -bindir flag may require changes in automake 
rule. Otherwise why will pass this flag to libtool ?

Next automake rule is not expected to create bindir, right ?

I'm not against to be removed current hard-coded libtoll '../bin/xx' DDL 
rule.
The Dave XX_abspath function for test case ported in previous my email 
produce /work/tmp/test/test-links/b (incorrect). Compare with command 
readlink -f ../1/../. It is /work/tmp/test/test-links/a (correct !).


I'm concerned that we can't implement a working portable(cross-platform) 
relative path calculation.


What is better for dlname for installed la-file: absolute or relative 
path ?


May be is better to put DLL in bindir as is passed to libtool and to 
write in installed la-file as is ?



[SNIP]


--
Chuck


Roumen

Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.

[Roumen Petrov]

Dave Korn wrote:

  So, here I hope is the final respin.  Built and tested on i686-pc-cygwin and
i686-pc-linux-gnu with no regressions and all new tests passing (see below sig
separator for details).

libtool/ChangeLog:

* Makefile.am (TESTSUITE_AT): Add bindir.at.
* libltdl/config/general.m4sh (func_normal_abspath): New function.
(func_relative_path): Likewise.
* libltdl/config/ltmain.m4sh (func_mode_link): Accept new -bindir
option and use it, if supplied, to place Windows DLLs.
* tests/bindir.at: New file for DLL install tests.
* doc/libtool.texi (Link Mode): Update documentation.

  Unless I've missed anything?


I think that processing of '..' in a path is too naive. It will fail to 
produce correct results on filesystems with links.



cheers,
  DaveK



Roumen

Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.

[Roumen Petrov]

Dave Korn wrote:

Roumen Petrov wrote:

I think that processing of '..' in a path is too naive. It will fail to
produce correct results on filesystems with links.


  As I explained to Eric, this function implements 'abspath', not 'realpath',
and given that we can't assume any of the directories even exist when we have
to do this at link time, before installation, I don't see how we could hope to
do any different.


You may test you function with following example:

(
P=/work/tmp/test/test-links
rm -rf $P
mkdir $P
cd $P
mkdir -p a/1/2
mkdir -p b/2
(cd b; ln -s ../a/1)

cd b/2
D=../1/../
touch $D/test
func_normal_abspath $D
echo $func_normal_abspath_result
/bin/ls -l $func_normal_abspath_result/
/bin/ls -l $D
)



  I think the whole of GNU configure expects the tree under $prefix/ to be
real and there are a lot of other things that will break if you try to use
symlinks to make the physical directory structure different from the apparent
structure, for example gcc tries to execute ld by starting at the
$prefix/lib/gcc/$target/$version directory where cc1 lives and invoking
../../../../bin/ld; if you've got symlinks in there that can't be ascended
without ending up somewhere other than you expect, then the compiler isn't
going to work.


Sure.
Currently for gcc 4.4.0 (target i486-mingw32 build ${ARCH}-pc-linux) non 
prefixed binaries from PREFIX/TARGET/bin don't work for me. As 
example gcc can't find cc1. May be is same issue.


To resolve issue I use following additional links:
# cd $PREFIX
# l ./i486-mingw32/lib/gcc
lrwxrwxrwx 1  ./i486-mingw32/lib/gcc - ../../lib/gcc/
# l ./i486-mingw32/libexec
lrwxrwxrwx 1  ./i486-mingw32/libexec - ../libexec/



  So I don't think this is likely to cause any problem except in really
bizarre corner-cases where someone's already trying something dubious, is it?


So to me function like XX_abspath has to work.



cheers,
  DaveK


Roumen

Re: Multipurpose binaries with different names

[Roumen Petrov]

Eric Blake wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Jan Engelhardt on 7/24/2009 3:25 AM:

Hi,


when one has a program that does something like

  if(strcmp(argv[0], gunzip) == 0)
uncompress();
  else
compress();


GNU Coding Standards frown on this practice:
http://www.gnu.org/software/automake/manual/standards.html#User-Interfaces


The Multipurpose binaries are born before GNU Coding Standards. So I 
think that libtool has to support them for historical reasons.



Regards
Roumen


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

Re: purpose of the c wrapper

[Roumen Petrov]

Ralf Wildenhues wrote:

Hello Vincent, Bob,


[SNIP]

But anyway, I don't see how the current git code generates C wrappers
for wince. 


The host is usually xxx-mingw32ce and will match patterns like 
{*-}*-mingw*, i.e. it will generate wrappers as for mingw32.


But the C-wrapper-code of current (my repository close is about one 
month old) libtool  don't include error.h :

.
#ifndef __MINGW32CE__
# include errno.h
#endif
.

[SNIP]
Roumen



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

Re: d3dx9.lib is not managed by ld, but libd3dx9.a is

[Roumen Petrov]

Vincent Torri wrote:


Hey,

I'm writing a dll using D3D and autotools stuff (MSYS / MinGW). I pass 
-ld3dx9 and i have added everything so that the dll is built.


If I add from the DirectX SDK d3dx9.lib in /mingw/lib, i have the usual 
warning message from linker / libtool:


*** Warning: linker path does not have real file for library -ld3dx9. 
blah blah blah


and only the static lib is built.

If I rename d3dx9.lib to libd3dx9.a, then the DLL is built. I don't 
understand why because, according to the doc of ld for win32:


http://sourceware.org/binutils/docs/ld/WIN32.html

if I pass -ld3dx9, then d3dx9.lib should be used.

What is the reason of the failure ?

thank you

Vincent Torri


I'm not sure that libtool has to deal with library '.lib' suffix. From 
the suffix is not clear type of library file - static or import library.
GNU compiler(mingw) use suffix '.a'  for static library and '.dll.a' for 
import libraries.
If a xx.lib file is found in search path libtool has to process file and 
to find its type(static/import). This impact performance.


Also support for MSVC import libraries isn't perfect and linker will 
fail to link if a library export variables. Note in this case GNU linker 
succeed to link directly shared(DLL) library.


Roumen


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

Re: Linking together .dll using .a static libraries

[Roumen Petrov]

Ralf Wildenhues wrote:

* Roumen Petrov wrote on Fri, Feb 27, 2009 at 10:07:19PM CET:

LRN wrote:

OK, maybe it's a stupid question, but i have to ask anyway.
MinGW ships some static .a libraries. How do i link these to shared .dll
libraries? It seems that libtool always performs a check (filemagic in
my case) on each -lname argument, and to pass that check the library has
to be x86 archive import or x86 DLL, but not x86 archive static.

Some of those libraries are always linked as example mingwex.


Which libraries are this exactly (for various MinGW versions), and are
any of these import libs?



quote for gcc spec file:
==
*lib:
%{pg:-lgmon} %{mwindows:-lgdi32 -lcomdlg32} -luser32 -lkernel32 
-ladvapi32 -lshell32


*libgcc:
%{mthreads:-lmingwthrd} -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
==

- mingwthrd: import, specific
- mingw32: static
- moldname: import (for functions without underscore)
- mingwex: static
- msvcrt+other xx*32: import (runtime)

mingwex is a specific extension. As example library add float and long 
double functions missing in msvcrt. Version 3.15 (3.14 ?) add posix 
compatible IO.




For the non-import default-linked ones, we should probably add
exceptions to libtool to accept them, but I'm not sure whether
that is the right thing here.



Thanks,
Ralf



Roumen


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

Re: Linking together .dll using .a static libraries

[Roumen Petrov]

LRN wrote:

OK, maybe it's a stupid question, but i have to ask anyway.
MinGW ships some static .a libraries. How do i link these to shared .dll
libraries? It seems that libtool always performs a check (filemagic in
my case) on each -lname argument, and to pass that check the library has
to be x86 archive import or x86 DLL, but not x86 archive static.


Some of those libraries are always linked as example mingwex.

Also you may pass flags to the linker: -Wl... Libtool pass it to the 
linker, i.e. you may pass def-file or library  (-lXXX) .


Roumen


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

Re: Making .lib import libraries with libtool

[Roumen Petrov]

LRN wrote:

I have a project that uses autoconf/automake/libtool, and it produces
shared libraries (on Windows that would be .dll) and static libraries
(.a). Which modifications are necessary for it to start outputing .lib
libraries (the ones that could be linked with link.exe) along with
.dll's? I can hack configure script and add calls to lib.exe, but that
doesn't seem right, and i would rather try doing that in configure.ac.


You didn't specify compiler. If it is GCC(mingwXX target) compiler 
produce import libraries with suffix .dll.a. In most cases just 
changing suffix work. Exception is both direction (.lib-.dll.a) is for 
exported variables.
In general even MSVC didn't produce compatible import libraries. Library 
created by compiler version X may not work for version Y. I'm not 
informed that this issue is resolved.

Def-files are more portable and some projects prefer this way.

Roumen


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

Re: Status of the MSYS/MSVC port

[Roumen Petrov]

Peter Rosin wrote:

Den 2009-01-29 18:56, skrev Ralf Wildenhues:

* Peter Rosin wrote on Thu, Jan 29, 2009 at 06:53:48PM CET:

But maybe, just maybe, you don't have a desperate need to do
-std=c89 -Werror :-)


Guys, if all you're working around is -Werror, then stop right now.
Just eliminate -Werror from $LTCC $LTCFLAGS and be done with it.
The cwrapper machinery, if it needs anything, then become simpler
and less work to maintain, not more.


I just realized that -Werror is not needed though, -std=c89 is enough
to make it fail. E.g.

./.libs/lt-usea.c:429: error: `S_IXUSR' undeclared (first use in this 
function)


and

./.libs/lt-usea.c:439: error: storage size of 'st' isn't known

etc

So, we'd need to also kick out -std=c89, -std=c99, -ansi (I think). Etc...

Cheers,
Peter


For flags -ansi and -std=c89 compiler internals (defines) are same.
With -ansi flag mingw 1.15 and 1.15.1 has to fail in stdlib.h ( inline 
... strtod ). This is fixed in 1.15.2.


Roumen

Re: Status of the MSYS/MSVC port

[Roumen Petrov]

Peter Rosin wrote:

Den 2009-01-29 00:45 skrev Roumen Petrov:

snip

I'm sure that I test libtool in mingw-cross env. after Charles add 
cwrapper test. Now I repeat the test N# 37(cwrapper) in verbose mode and

the results is:
...
/at-groups/37/test-source: line 73: ./libtool: Permission denied
...
37. cwrapper.at:25:  ok
1 test was successful.

Ooops


Indeed. I'll post a patch in a new thread...

Cheers,
Peter


Now 39. cwrapper.at pass
mingw runtime v 1.15.2

Roumen

Re: Status of the MSYS/MSVC port

[Roumen Petrov]

Peter Rosin wrote:
[SNIP]

This was all inside #ifdef __MINGW32__, which assumes msvcrt.dll, i.e.
compatible with MSVC 6, so we're safe. I think. Famous last words...


It seems to me that I misunderstood report failure and the case.
It start for ms compiler why #ifdef __MINGW32__ is now involved ?


Cheers,
Peter


I'm sure that I test libtool in mingw-cross env. after Charles add 
cwrapper test. Now I repeat the test N# 37(cwrapper) in verbose mode and

the results is:
...
/at-groups/37/test-source: line 73: ./libtool: Permission denied
...
37. cwrapper.at:25:  ok
1 test was successful.

Ooops

Roumen

Re: testsuite performance

[Roumen Petrov]

Charles Wilson wrote:

Ralf Wildenhues wrote:

* Charles Wilson wrote on Wed, Jan 21, 2009 at 08:47:42PM CET:

[...] EVERY separate patchset requires an independent full testsuite
run.  Until recently, that was 5 hours of sitting in front of my
computer waiting for popups, while that computer was completely useless
for anything else (100% cpu).

[SNIP]

Can you work on a Linux system with Wine, for at least those
changes for which the difference shouldn't matter that much? 


Not sure.
To run msys bash it has to be at least wine version 1.1.8 (I forgot 
number of resolved issue). Next born shells (msys bash and ash from 
pw32) are too slow. The simple command like sh -c echo xxx is about 10 
times slower if compare to native run - the last wine issue is 13606.


Roumen

Re: use $EXEEXT consistently in new testsuite

[Roumen Petrov]

Ping.
Roumen Petrov wrote:
[SNIP]

Now my environment is with Fortran and Java tools.
Tests 21 and 22 - ok.
For test 23 - one more $EXEEXT. Please see attached file 
libtool-origin-20081127.diff

[SNIP]
Roumen
diff --git a/tests/convenience.at b/tests/convenience.at
index 995c8ff..c689811 100644
--- a/tests/convenience.at
+++ b/tests/convenience.at
@@ -263,7 +263,7 @@ EOF
   # libgcj.spec or unable to find it.  Skip this test for them.
   if test $i -eq 1; then
 AT_CHECK([$GCJ $GCJFLAGS -c foo1.java || exit 77], [], [ignore], [ignore])
-AT_CHECK([$GCJ $GCJFLAGS --main=foo1 -o foo1 foo1.java A1.java || exit 
77],[],[ignore],[ignore])
+AT_CHECK([$GCJ $GCJFLAGS --main=foo1 -o foo1$EXEEXT foo1.java A1.java || 
exit 77],[],[ignore],[ignore])
 AT_CHECK([./foo1$EXEEXT || exit 77],[],[ignore],[ignore])
 rm -f foo1.o foo1.obj foo1$EXEEXT
   fi

Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.

[Roumen Petrov]

Charles Wilson wrote:
[SNIP]

This patch attempts to correct the issues raised in this thread:
msys/mingw warnings about string length and putenv absence with gcc -Wall 
-ansi
http://lists.gnu.org/archive/html/bug-libtool/2008-12/msg00038.html


[SNIP]
Patch fail for trunk(origin):
$ patch -p1 --dry-run  .../Fix\ compile\ warnings...
patching file libltdl/config/ltmain.m4sh
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] y
Hunk #1 FAILED at 5.
Hunk #2 FAILED at 2309.
Hunk #3 FAILED at 2406.
Hunk #4 FAILED at 2526.
Hunk #5 FAILED at 2717.
Hunk #6 succeeded at 2725 with fuzz 2 (offset -10 lines).
Hunk #7 FAILED at 2769.
Hunk #8 FAILED at 2821.
Hunk #9 FAILED at 2855.
Hunk #10 FAILED at 2952.
Hunk #11 FAILED at 3712.
10 out of 11 hunks FAILED -- saving rejects to file 
libltdl/config/ltmain.m4sh.rej


Roumen

Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.

[Roumen Petrov]

Charles Wilson wrote:

Now I get completely new working cross-environment: git show correctly 
modified files, patch work too :) .

[SNIP]

No regressions on msys/mingw from the last time I ran the testsuite on
that platform (2.2.5a).  IOW:

Old testsuite results:

[SNIP]
No regression on unix/mingw too.


New testsuite results:
ERROR: 77 tests were run,
6 failed (3 expected failures).
4 tests were skipped.
 65: compiling softlinked libltdl   FAILED (recursive.at:71)
 66: compiling copied libltdl   FAILED (recursive.at:91)
 67: installable libltdlFAILED (recursive.at:113)
 80: Run tests with low max_cmd_len (ctrl-C'ed, so not incl. in tally)



The results:
17: preserve duplicate convenience deps expected failure
29: static linking flags for programs   skipped
32: sys_lib_search_path skipped
35: static library contains static library  expected failure
74: build tree relpaths expected failure
80: Run tests with low max_cmd_len(CANCELED)

For 32: My new build environment is with incorrect path to libz :(.
For 23: Java convenience archives is ok as my build env. contain one 
$EXEEXT more.



OK to push?


Fine with me.

Roumen

Re: uninstalled modules do not build .so files

[Roumen Petrov]

Andy Wingo wrote:


Hi,

So, this is a resend, as for some reason the silliest of autotools
projects creates 300 kB tarballs. Attaching the files individually:
unpack in a directory of their own please.

***

Unpack the attached tarball (it will create its own directory). It is a
standard autotooled project with one file, foo.c.

Expected results: ./autogen.sh  make produces a .so file in .libs.

Actual results: No .so file is produced.


AC_ENABLE_SHARED ?

Roumen


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

Re: libtool.git cl.exe Mingw32

[Roumen Petrov]

Akim Demaille wrote:

Hi friends,

It's cold, the win32ter's back, and I'm a lonely winderer in the 
winderful country to losedows.


As you suggested, I'm moved from pw32 to ming32, and as a result, I now 
have a wrapper.exe instead of a shell script wrapper.  This is 
wonderful news, since I was wasting a lot of time in useless 
recompilations, because libtool -o foo.exe used to create foo, which 
cause the Makefiles to never be satisfied and relaunching endless 
recompilations.


Yet I have a slight problem: for some reason the top-level wrapper 
(lt-cli.exe in my case) tries to launch .libs/lt-cli.exe, which does not 
exist.  What does exist is .libs/cli.exe (and actually it makes more 
sense to me).  So I had to change libtool:

[SNIP]

What about libtool version ?

Roumen


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

Re: Migrating from 1.5.x to 2.2.x

[Roumen Petrov]

Jason Curl wrote:

Dan Nicholson wrote:

On Sat, Dec 13, 2008 at 12:57 AM, Jason Curl jcurln...@arcor.de wrote:
 

Ralf Wildenhues wrote:

[SNIP]
  

You're right, I only ran autoreconf. libtoolize fixed the problem.

A concern I have about libtoolize, it copies libtool.m4 and lt*.m4 
files to my m4 macro directory. This is OK so long as all development 
platforms where I might run autoreconf are configured the same. I've 
tested to autoreconf my project on Ubuntu 8.10 that has by default 
libtool-2.2.4, where my Cygwin installation has libtool-2.2.6a. If I go 
backwards I get warnings. And I've already had a problem that during 
building the software the libtool scripts hung. All this occurs as soon 
as when the macros in m4/lt*.m4 don't match that which are installed on 
the local machine. I never had this issue with libtool-1.5.23 to 
libtool-1.5.26.
I always had this issue with version  2.x on all projects that include 
libtool macros in acinclude.m4. This is the case when user try to 
recreate autotools scripts. Work around is known - manually(!) remove 
(replace) libtool macros from acinclude.m4.
As from 2.x libtool team recommend macros to be in separate files and 
now is more easy to refresh them.


Also this isn't only libtool issue. In a project all macros from and 
external(dependent) has to be synchronized with you version of this 
package. If macros rare from new or old version is possible configure 
script to fail.
This is integration problem(issue). Overwriting external m4 files in a 
project with those from system help in most cases, but not all.


The hang of libtool may be is similar to KDevelop issue :
http://lists.gnu.org/archive/html/bug-libtool/2008-05/msg00086.html

[SNIP]

Roumen



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

Re: Getting filenames for libraries

[Roumen Petrov]

Jason Curl wrote:

Brian Dessent wrote:

Jason Curl wrote:


[SNIP]


I've attached a sample of the macros if there are comments.

e.g.
configure.ac (only the interesting bits)

[SNIP]

LX_PROG_RC

use AC_LIBTOOL_RC


AC_CONFIG_FILES([src/rsrc.rc])

Makefile.am

[SNIP]

.rc.lo:
   $(LIBTOOL) $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --tag=CC --mode=compile 
$(RC) $(RCFLAGS) $ -o $@


after AC_LIBTOOL_RC in configure you may use .. --tag=RC $(RC) ..

[SNIP]


  windows)
major=`expr $current - $age`
versuffix=-$major
;;

In case of make LDFLAGS=-avoid-version versuffix has to be  !

[SNIP]
Roumen



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

Re: problem when cross compiling with mingw32ce

[Roumen Petrov]

Vincent Torri wrote:


Hey,


* Vincent Torri wrote on Tue, Oct 07, 2008 at 05:30:24PM CEST:

libtool call:

/bin/sh ../../libtool --tag=CC   --mode=link arm-mingw32ce-gcc  -g -O2
-Wl,--enable-auto-import -L/home/torri/local/wince/lib
-L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o
memcpy_glibc_arm.o ../../src/lib/libevil.la
libtool: link: arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -o
.libs/suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o
-L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib
../../src/lib/.libs/libevil.dll.a -lws2 -L/home/torri/local/wince/lib

libtool: link: Could not determine host path corresponding to
libtool: link:
'/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link:   '/home/torri/local/wince/lib'

[SNIP]


Note that I also have those warnings when I cross-compile on linux using 
the host i586-mingw32msvc. So it's not specific to the arm-mingw32ce host


Vincent Torri


You environment lack emulator, or winepath isn't in PATH.

Roumen



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

Re: problem when cross compiling with mingw32ce

[Roumen Petrov]

Vincent Torri wrote:



On Sat, 6 Dec 2008, Roumen Petrov wrote:


You environment lack emulator, or winepath isn't in PATH.


WHY do I need an emulator ?


I need it to run the project tests including libtool tests.


 I don't care about that. I just want my
executables being installed (copied) in the prefix/bin directory I 
passed when I exec 'make install'. That's all. WHY does libtool does not 
want to do so ? Is there a way to forbid libtool executing that wrapper 
? like -do-not-exec-the-stupid-wrapper


It is just a warning. Is there a real issue ?


Vincent Torri



Roumen


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

Re: func_emit_cwrapperexe_src() errors with mingw32ce

[Roumen Petrov]

Vincent Torri wrote:


Hey,

Natively, the Windows CE OS has no concept of environment variable. 
Hence, when mingw32ce is used, func_emit_cwrapperexe_src() fails because 
of missing getenv() and putenv() (or setenv() also, of course). I don't 
know what to do here (removing or not thee calls, as I don't know why 
they are used.


There are also 2 other functions that are missing with that compiler:

 * getcwd()


May be a port function that return always \Temp is work around?


  it's possible to get the path where the current process is launched. 
Again, i don't know if it's simpler to remove that call or if one should 
provide a way to have the path where the process is launched.


 * _spawnv()


A code based on CreateProcess ?

  i don't know any simple way to fake that function. Maybe one should 
add another test in the 'host' case for that specific compiler which wo 
do nothing (in that case, one can remove the #ifndef in the case the 
host is mingw*)


Vincent Torri


If wince lack working emulator may libtool omit creation of wrapper  ?

Roumen


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

Re: use $EXEEXT consistently in new testsuite

[Roumen Petrov]

Ralf Wildenhues wrote:

* Ralf Wildenhues wrote on Sun, Nov 23, 2008 at 10:41:46PM CET:

To fix the loose end wrt. the exec checks, there was some exit status
normalization needed here.  I think this patch should be sufficient,
once the $EXEEXT patch is in (comes next).


Here it is.  I went over tests/*.at and hopefully found all instances
needing $EXEEXT now.  Pushed.  Review appreciated.

Cheers,
Ralf

[SNIP]
I will check this failure:
28: Runpath in libtool library filesFAILED 
(runpath-in-lalib.at:59)


The other not ok test:
 21: F77 convenience archives   skipped (convenience.at:110)
 22: FC convenience archivesskipped (convenience.at:170)
 23: Java convenience archives  skipped (convenience.at:267)
It is time to install those tools :( ;)

 29: static linking flags for programs skipped (static.at:177)
 35: static library contains static library	expected failure 
(archive-in-archive.at:49)

 68: build tree relpathsexpected failure 
(deplibs-ident.at:68)
 74: Run tests with low max_cmd_len FAILED (cmdline_wrap.at:43)
Still no time to look into this one.

 75: darwin fat compile  skipped (darwin.at:42)
  fine (test is on linux)

Roumen

Re: testsuite.at for version 2.x Was: ... mingw-cross, check-local fail for DESTDIR tests

[Roumen Petrov]

Roumen Petrov wrote:

Ralf Wildenhues wrote:

Hello Roumen, all,

apologies for the huge delay.

* Roumen Petrov wrote on Sat, May 10, 2008 at 12:25:48PM CEST:
The libtool version before 2.x (as example 1.5x) in mingw-cross  
compilation environment create executables as follow:

- foo : wrapper shell script
- foo.exe : libtool wrapper executable
. libs/foo.exe : native(host) executable

Since version 2.x don't create wrapper shell script in build 
directory  make check{-local} skip any tests. The reason is code of 
macro  LT_AT_EXEC_CHECK:

[...]
The program $1 (wrapper shell scrip in 1.5x and former) don't exist,  
lt_status is non zero and macro code exit with status 77 (exist 
wrapper  executable $1$EXEEXT).


Also same problem in macro LT_AT_NOINST_EXEC_CHECK.


Agreed.  Please try this patch.  Thanks.

Others, OK to commit?

Thanks,
Ralf


Please find attached file libtool-origin-20081118.diff.gz (Ralf patch
+ more $EXEEXT when linking executables)


I guess that a typo was problem with libtool --mode install so in 
previous patch I left test code unchanged (may be a Cyrillic E instead 
Latin).


Now I update code for mode install again and the new diff-file is 
attached as libtool-origin-20081118-v2.diff.gz.

Changes:
- $EXEEXT for mode install;
- gived-up changes in old-m4-iface.at;
- change in static.at from [m$st] to [m${st}$EXEEXT] may be isn't portable.


[SNIP]
Test 25 Link order of deplibs skipped (link-order2.at:129) - in my 
todo  for investigation.


Still skipped. The executable exit code is 1 instead 2. No idea what is 
problem:

- emulation problem;
- mingw linker problem;
- windows loader - load shared library order problem (not tested yet).

$objdump -x .libs/wrong.exe  | grep DLL
DLL Name: libb-0.dll
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
DLL Name: liba0-0.dll

$ objdump -x .libs/libb-0.dll | grep DLL
DLL Name: liba1-0.dll
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll

strace show that liba1-0.dll is accessed first.

The link command:
[GCC] ... -o .libs/wrong.exe main.o \
  -L[T25DIR]/lib \
  [T25DIR]/lib/liba0.dll.a \
  ./.libs/libb.dll.a \
  [T25DIR]/.libs/liba1.dll.a \
  -L[T25DIR]/lib -L[T25DIR]/inst/lib


Test 29 static linking flags for programs skipped (static.at:177) - 
problem is with libtool --mode install since real executable is in 
.libs subdirectory. No idea how to fix.

It is not --mode install problem.
Still skipped. It is too big test :) .


[SNIP]
Test 48 enforced lib prefix FAILED (need_lib_prefix.at:184) - again 
--mode install problem (see test 29).

It is not --mode install problem. It is related to end of line.
$ cat -A testsuite.dir/48/expout
libfoo1: 2^M^M$
libfoo2: 3^M^M$
$ testsuite.dir/48/main.exe  | cat -A
libfoo1: 2^M$
libfoo2: 3^M$

Also executable is linked statically since -no-undefined isn't specified 
(two warnings in log output).



[SNIP]


Roumen


libtool-origin-20081118-v2.diff.gz
Description: application/gzip