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

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: [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]

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

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

[Roumen Petrov]

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)
Now results from make check-local (only if result isn't ok):
==
## -- ##
## libtool 2.2.7a test suite. ##
## -- ##

 17: preserve duplicate convenience deps expected failure 
(duplicate_deps.at:72)

 
 21: F77 convenience archivesskipped 
(convenience.at:110)
 22: FC convenience archives skipped 
(convenience.at:170)
 23: Java convenience archives   skipped 
(convenience.at:267)

 
 25: Link order of deplibs.  skipped 
(link-order2.at:129)

 
 29: static linking flags for programs   skipped 
(static.at:177)

 
 32: sys_lib_search_path skipped 
(search-path.at:57)

 
 35: static library contains static library  expected failure 
(archive-in-archive.at:49)

 
 48: enforced lib prefix FAILED 
(need_lib_prefix.at:184)

 
 68: build tree relpaths expected failure 
(deplibs-ident.at:68)

 
 74: Run tests with low max_cmd_len  FAILED 
(cmdline_wrap.at:43)

 
 75: darwin fat compile  skipped (darwin.at:42)

## - ##
## Test results. ##
## - ##

ERROR: 68 tests were run,
5 failed (3 expected failures).
7 tests were skipped.
==

For the test 21, 22, 23 i don't have time to upgrade GCC compiler suite 
(still without Fortran and java).


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


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.


Test 32 sys_lib_search_path skipped (search-path.at:57) - a new skip :).
For all mingw builds the prefix is same but compiler don't list 
PREFIX/lib in sys_lib_search_path. May be if libtool is build with 
LDFLAGS=-LPREFIX/lib the new check will succeed.


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


Test 74 Run tests with low max_cmd_len FAILED (cmdline_wrap.at:43) - a 
new unexpected failure. No idea why. Before upgrade and patch was ok.



Roumen



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

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

[Roumen Petrov]

Ralf Wildenhues wrote:

Hello Roumen, all,

[skip]

diff --git a/tests/testsuite.at b/tests/testsuite.at
index f7e805e..6bb34f4 100644
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -203,29 +203,43 @@ m4_define([_LT_AT_TRANSLATE_TEXT_OUTPUT],
 esac])
 
 
-# LT_AT_EXEC_CHECK(EXECUTABLE, [STATUS = 0], [STDOUT], [STDERR])

+# LT_AT_EXEC_CHECK(EXECUTABLE, [STATUS = 0], [STDOUT], [STDERR],

[skip]

after patch
$ make check-local
...
19: C convenience archives  skipped 
(convenience.at:64)



may patch is not correct :(
Roumen

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

[Roumen Petrov]

Roumen Petrov wrote:

Roumen Petrov wrote:

Ralf Wildenhues wrote:

Hello Roumen, all,

[skip]

diff --git a/tests/testsuite.at b/tests/testsuite.at

...


-# LT_AT_EXEC_CHECK(EXECUTABLE, [STATUS = 0], [STDOUT], [STDERR])
+# LT_AT_EXEC_CHECK(EXECUTABLE, [STATUS = 0], [STDOUT], [STDERR],

[skip]


Please find attached file convenience.at-log
Roumen


May by not related to the patch:
convenience.at at lines 59 and 61 link executable without $EXEEXT.
The static executable is created in build directory without suffix and 
exit with 0;
The shared executable is created in .libs subdirectory without suffix, 
the wrapper is created in build-dir with suffix .exe, bug exit with 
error code 127 - look like expected failure as executable can't be found.


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,

[skip]

diff --git a/tests/testsuite.at b/tests/testsuite.at

...


-# LT_AT_EXEC_CHECK(EXECUTABLE, [STATUS = 0], [STDOUT], [STDERR])
+# LT_AT_EXEC_CHECK(EXECUTABLE, [STATUS = 0], [STDOUT], [STDERR],

[skip]


Please find attached file convenience.at-log
Roumen
abs_srcdir=`CDPATH=${ZSH_VERSION+.}:  cd [SRCDIR]  pwd`; cd tests; \
CONFIG_SHELL=/bin/sh /bin/sh $abs_srcdir/tests/testsuite \
  MAKE=make CC=i386-mingw32msvc-gcc CFLAGS=-O2 
-fno-strict-aliasing -Wall CPP=i386-mingw32msvc-gcc -E CPPFLAGS= 
LD=/opt/mingw/i386-mingw32msvc/bin/ld LDFLAGS= LIBS= LN_S=ln -s 
NM=/opt/mingw/bin/i386-mingw32msvc-nm -B RANLIB=i386-mingw32msvc-ranlib 
STRIP=i386-mingw32msvc-strip INSTALL=/usr/bin/ginstall -c OBJEXT=o 
EXEEXT=.exe SHELL=/bin/sh CONFIG_SHELL=/bin/sh CXX=i386-mingw32msvc-g++ 
CXXFLAGS=-O2 -fno-strict-aliasing -Wall CXXCPP=i386-mingw32msvc-g++ -E 
F77= FFLAGS= FC= FCFLAGS= GCJ=gcj GCJFLAGS=-g -O2 
_lt_pkgdatadir=[SRCDIR] LIBTOOLIZE=[BLDDIR]/libtoolize 
LIBTOOL=[BLDDIR]/libtool tst_aclocaldir=[SRCDIR]/libltdl/m4 -v 19
## -- ##
## libtool 2.2.7a test suite. ##
## -- ##
19. convenience.at:30: testing ...
libtool: compile:  i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall -c 
main1.c  -DDLL_EXPORT -DPIC -o .libs/main1.o
libtool: compile:  i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall -c 
main1.c -o main1.o /dev/null 21
libtool: compile:  i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall -c a1.c  
-DDLL_EXPORT -DPIC -o .libs/a1.o
libtool: compile:  i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall -c a1.c 
-o a1.o /dev/null 21
libtool: link: i386-mingw32msvc-ar cru .libs/liba1.a .libs/a1.o 
libtool: link: i386-mingw32msvc-ranlib .libs/liba1.a
libtool: link: ( cd .libs  rm -f liba1.la  ln -s ../liba1.la 
liba1.la )
libtool: compile:  i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall -c 
main2.c  -DDLL_EXPORT -DPIC -o .libs/main2.o
libtool: compile:  i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall -c 
main2.c -o main2.o /dev/null 21
libtool: compile:  i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall -c a2.c  
-DDLL_EXPORT -DPIC -o .libs/a2.o
libtool: compile:  i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall -c a2.c 
-o a2.o /dev/null 21
libtool: link: i386-mingw32msvc-ar cru .libs/liba2.a .libs/a2.o 
libtool: link: i386-mingw32msvc-ranlib .libs/liba2.a
libtool: link: ( cd .libs  rm -f liba2.la  ln -s ../liba2.la 
liba2.la )
libtool: compile:  i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall -c 
main3.c  -DDLL_EXPORT -DPIC -o .libs/main3.o
libtool: compile:  i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall -c 
main3.c -o main3.o /dev/null 21
libtool: compile:  i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall -c a3.c  
-DDLL_EXPORT -DPIC -o .libs/a3.o
libtool: compile:  i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall -c a3.c 
-o a3.o /dev/null 21
libtool: link: i386-mingw32msvc-ar cru .libs/liba3.a .libs/a3.o 
libtool: link: i386-mingw32msvc-ranlib .libs/liba3.a
libtool: link: ( cd .libs  rm -f liba3.la  ln -s ../liba3.la 
liba3.la )
[SRCDIR]/tests/convenience.at:51: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o 
liba12.la liba1.la liba2.la -rpath /notexist
stderr:
libtool: link: warning: undefined symbols not allowed in i386-pc-mingw32msvc 
shared libraries
stdout:
libtool: link: (cd .libs/liba12.lax/liba1.a  i386-mingw32msvc-ar x 
[BLDDIR]/tests/testsuite.dir/19/./.libs/liba1.a)
libtool: link: (cd .libs/liba12.lax/liba2.a  i386-mingw32msvc-ar x 
[BLDDIR]/tests/testsuite.dir/19/./.libs/liba2.a)
libtool: link: i386-mingw32msvc-ar cru .libs/liba12.a   
.libs/liba12.lax/liba1.a/a1.o  .libs/liba12.lax/liba2.a/a2.o 
libtool: link: i386-mingw32msvc-ranlib .libs/liba12.a
libtool: link: rm -fr .libs/liba12.lax
libtool: link: ( cd .libs  rm -f liba12.la  ln -s ../liba12.la 
liba12.la )
[SRCDIR]/tests/convenience.at:53: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o 
liba123.la a3.lo liba1.la liba2.la -rpath /notexist
stderr:
libtool: link: warning: undefined symbols not allowed in i386-pc-mingw32msvc 
shared libraries
stdout:
libtool: link: (cd .libs/liba123.lax/liba1.a  i386-mingw32msvc-ar x 
[BLDDIR]/tests/testsuite.dir/19/./.libs/liba1.a)
libtool: link: (cd .libs/liba123.lax/liba2.a  i386-mingw32msvc-ar x 
[BLDDIR]/tests/testsuite.dir/19/./.libs/liba2.a)
libtool: link: i386-mingw32msvc-ar cru .libs/liba123.a  a3.o  
.libs/liba123.lax/liba1.a/a1.o  .libs/liba123.lax/liba2.a/a2.o 
libtool: link: i386-mingw32msvc-ranlib .libs/liba123.a
libtool: link: rm -fr .libs/liba123.lax
libtool: link: ( cd .libs  rm -f liba123.la  ln -s ../liba123.la 
liba123.la )
[SRCDIR]/tests/convenience.at:59: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS 
-static -o main_static main$i.lo liba$conv.la
stderr:
stdout:
libtool: link: i386-mingw32msvc-gcc -O2 -fno-strict-aliasing -Wall -o 
main_static .libs/main1.o  ./.libs/liba1.a 
[SRCDIR]/tests/convenience.at:61: $LIBTOOL --mode=link $CC

Re: libtool(20080421), mingw-cross, check-local fail for DESTDIR tests

[Roumen Petrov]

Ralf Wildenhues wrote:

Hi Roumen,

* Roumen Petrov wrote on Wed, Nov 12, 2008 at 08:41:09PM CET:

Ralf Wildenhues wrote:

--- a/tests/destdir.at
+++ b/tests/destdir.at
@@ -56,7 +56,7 @@ $LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c a.c

[SNIP]


 AT_CHECK([$LIBTOOL --mode=finish $libdir], [ignore], [ignore], [ignore])
-LT_AT_EXEC_CHECK([$bindir/m])
+LT_AT_EXEC_CHECK([$bindir/m$EXEEXT])

[SNIP]
May we don't need to change call of LT_AT_EXEC_CHECK - yet another
 patch that address LT_AT_EXEC_CHECK and LT_AT_NOINST_EXEC_CHECK has to  
be enough.


Yes.  In fact, the other patch that I posted for review and testing
would make this very change above obsolete.  Doesn't matter, though,
it doesn't hurt to leave it in.

Cheers,
Ralf


10x

make check-local TESTSUITEFLAGS=38 39 result:

## -- ##
## libtool 2.2.7a test suite. ##
## -- ##

Testing libtool functions.

 38: Install tests   ok

DESTDIR tests

 39: Simple DESTDIR install  ok

## - ##
## Test results. ##
## - ##

All 2 tests were successful.

Roumen

Re: [PATCH] [mingw] Add cross-compile support to cwrapper

[Roumen Petrov]

Charles Wilson wrote:

Roumen Petrov wrote:


 # func_to_host_path arg

[SNIP]



 # ARG is the path (on $build) that should be converted to
 # the proper representation for $host. The result is stored
@@ -2546,11 +2553,28 @@ func_to_host_path ()
 func_to_host_path_result=`echo $func_to_host_path_tmp1 |\
   $SED -e $lt_sed_naive_backslashify`
 ;;
+  * )
+# Unfortunately, winepath does not exit with a non-zero
+# error code, so we are forced to check stderr for an
+# error message. On the other hand, if the command is not
+# found, the shell will set an exit code of 127. So we
+# must check for both, which explains the odd construction:
+func_to_host_path_winepath_stderr=`winepath -w $1 
 /dev/null 21`

+func_to_host_path_winepath_exitcode=$?
+if test $func_to_host_path_winepath_exitcode -eq 0 \
+   test -z ${func_to_host_path_winepath_stderr} ; then
+  func_to_host_path_tmp1=`winepath -w $1`
+  func_to_host_path_result=`echo 
$func_to_host_path_tmp1 |\

+$SED -e $lt_sed_naive_backslashify`
+fi
+;;

[SNIP]

So it winepath fail to convert a build-system path it output only LF 
on standard output(stdout).
I cannot confirm that exists relation: 'non-empty' stderr output and 
path-translation failure.


My point of view is that check for 'empty' stdout is enough as 
indication for translation-failure.


The problem with that is, bash puts the following on stdout -- NOT 
stderr -- if it cannot find winepath:

bash: winepath: command not found

So, at the very least, we have failure if either
  stdout is empty
or
  exit code is nonzero

Try replacing the section above with:

  * )
# 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:
func_to_host_path_tmp1=`winepath -w $1 2/dev/null`
func_to_host_path_winepath_exitcode=$?
if test $func_to_host_path_winepath_exitcode -eq 0 \
   test -n ${func_to_host_path_tmp1} ; then
  func_to_host_path_result=`echo $func_to_host_path_tmp1|\
$SED -e $lt_sed_naive_backslashify`
fi
;;

And let me know if that works better for you.

[SNIP]



--
Chuck


It seems to me that the patch work with one addition:

func_to_host_path ()
{
  func_to_host_path_result=$1
  if test -n $1 ; then
case $host in
  *mingw* )
func_to_host_path_result= #  clean result
lt_sed_naive_backslashify='s|*|\\|g;s|/|\\|g;s|\\||g'
case $build in
  *mingw* ) # actually, msys
.

Without to clean result we cannot get warning in cross-compilation case 
it winepath fail.



Or maybe to clean only in default build case if winepath fail since if 
build is mingw/cygwin code always assign value to func_to_host_path_result:


.
  func_to_host_path_tmp1=`winepath -w $1 2/dev/null`
  func_to_host_path_winepath_exitcode=$?
  if test $func_to_host_path_winepath_exitcode -eq 0 \
 test -n ${func_to_host_path_tmp1} ; then
func_to_host_path_result=`echo $func_to_host_path_tmp1 |\
  $SED -e $lt_sed_naive_backslashify`
  else
func_to_host_path_result= #  clean result
  fi
  ;;
.



Roumen

Re: [PATCH] [mingw] Add cross-compile support to cwrapper

[Roumen Petrov]

Charles Wilson wrote:

Roumen Petrov wrote:

[SNIP]

Try replacing the section above with:

  * )
# 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:
func_to_host_path_tmp1=`winepath -w $1 2/dev/null`
func_to_host_path_winepath_exitcode=$?
if test $func_to_host_path_winepath_exitcode -eq 0 \
   test -n ${func_to_host_path_tmp1} ; then
  func_to_host_path_result=`echo $func_to_host_path_tmp1|\
$SED -e $lt_sed_naive_backslashify`
fi
;;

And let me know if that works better for you. 

[SNIP]

Looks good. I may test this weekend.
Roumen

Re: [PATCH] [mingw] Add cross-compile support to cwrapper

[Roumen Petrov]

Charles Wilson wrote:

Roumen Petrov wrote:
No answer from wine-developers ( 
http://www.winehq.org/pipermail/wine-devel/2008-May/065695.html )


As expected you patch pass my test :).


That's good to know. Except for one issue [1], I'm of the opinion that 
my current patch is pedantically correct -- but slow, while your 
proposed modifications are optimizations.



Lets go upstream.


By this do you mean 'push to the git repo'?


yes (push/commit/put/add in head/trunk/origin/master/main branch)


I'd rather wait for Ralf to 
get back and comment; should be later this week I think.



Roumen Petrov wrote:

Charles Wilson wrote:
But I'm not sure that supporting changing the mapping after 
building the wrapper is something we should support (e.g. 
deliberately code the wrapper to allow it, and then have to answer 
questions about why it does or does not work in some user's wacky 
wine setup, down the road.) Is there a realistic use case where this 
facility is important, that couldn't be solved by okay, then rm -f 
wrapper.exe, make wrapper


Expanding on this point, right now we do not expect the wrapper 
*scripts* to work outside of their build directory:



#! /bin/sh
# mdemo_static - temporary wrapper script for .libs/mdemo_static
# Generated by ltmain.sh (GNU libtool 1.2980 2008-05-13) 2.2.5a
...
# This wrapper script should never be moved out of the build directory.
# If it is, it will not operate correctly.

And, if you change your fstab so that the effective path to the wrapper 
script changes -- even if you don't physcially

   mv from-here/wrapper to-there/wrapper
I would still expect the wrapper script to be broken.


Not to move - to change mapping:
Let $WINEPREFIX/dosdevices contain:
lrwxrwxrwx ... c: -  #not important
lrwxrwxrwx ... l: - /usr/local/
lrwxrwxrwx ... s: - /usr/local/src/

Let top_builddir is /usr/local/src/test,
library lib1 in /usr/local/src/test/lib1,
and program foo in /usr/local/src/test/appl .
In this case c-wrapper program will contain in xxx_PATH_VALUE 
s:\lib1\.libs .


If the mapping s: is removed the program will fail without to be moved 
physically on build system. Strictly speaking it is moved on host system 
- now valid path is l:\src\lib1\.libs.



That same limitations apply to the binary wrapper executables.  Change 
the wine fstab after you build, and you'll probably break the wrappers.



So if the wine developers confirm that run-time translation in not
side-effect we may skip winepath and the problem will disappear
and will not depend of $WINEPREFIX/dosdevice links.
In well setup environment z in link to the root of the filesystems on
build. In my test-environment m: is an additional link (to
MINGWCROSS) and z: is removed intentionally before tests.


But, if I understand your text above correctly, even with no Z: mapping 
(as long as you have SOME suitable mapping to the build directly), my 
current proposed patch works.


The patch work if exist translation from absolute 'subpath' to build 
directory to DOSDEVICE, i.e. work if winepath -w top_builddir return 
 DOSPATH c-wrapper. This is in the case when project don't use external 
shared libraries.
If project use external shared libraries, but absolute path on build 
host cannot' be translated, at link phase libtool output:

libtool: link: Could not determine host path corresponding to
libtool: link:   '/.'
libtool: link: Continuing, but uninstalled executables may not work.
for all missing paths.
So it is fine with me.

The check for empty func_to_host_pathlist_result is after path-list 
translation but all missing path are reported by func_to_host_path.

May be this check is extra.


The problem I have with echo $val | sed -e 's|:|;|g' is what if, 
somehow, a dos-style path is in $val?


C:\bob - C;\bob


May we left the build path cannot contain ':' as limitation of 
libtool in case of cross-compilation environment ?


But that's a rather arbitrary restriction, simply to enable an 
optimization in the wrapper generation, isn't it?


May be if ltmain.m4sh, during creation of dllsearchpath and some 
other variables, separate items by host system dir-separator the 
problem will  be solved.


Oh, boy. I *really* don't know about that: because then the changes we 
are talking about are no longer isolated to one little corner of 
libtool, but could propagate everywhere -- and affect other platforms. 
No, thanks -- in that case, the cure is worse than the disease.




P.S.:
Also winepath exit with zero(!?!?!?) even if path cannot be 
translated:

==
$ winepath -w `pwd`; echo $?
Warning: could not find DOS drive for current working directory 
'/./lt-HEAD-mingw-mlib', starting in the Windows directory.


0


Well, that's just...evil. Is it possible that this is a bug in 
winepath that should be reported upstream? Surely 
exit-with-0-on-error is not the *design* behavior, is it?


I'm going to have to think hard about how to detect error 
status...there is a very ugly

Re: [PATCH] [mingw] Add cross-compile support to cwrapper

[Roumen Petrov]

No answer from wine-developers ( 
http://www.winehq.org/pipermail/wine-devel/2008-May/065695.html )


As expected you patch pass my test :). Lets go upstream.

Roumen


Roumen Petrov wrote:

Charles Wilson wrote:

Roumen Petrov wrote:

Charles Wilson wrote:

[mingw] Add cross-compile support to cwrapper


May be the patch can be more simple. In a previous post I confirm 
that for the wine emulator is enough items in path list, where every 
item is absolute path from build system, to be separated by DOS 
path-separator only.


Right, and thank you for that. What wasn't clear, however, was whether 
this automatic path translation was a peculiarity of your wine setup 
(e.g. identity mounts or something) or is a documented feature of wine.


Automatic path translation work for me. I may ask wine-developers to
confirm.


This is enough and at run-time wine(wineloader?) will translate 
internally from build system absolute path to the path from 
emulated environment.


So it only works for absolute paths, but is applied to all environment 
variables (like PATH)?


winepath will convert relative paths, AFAICT, although it converts 
them to absolute first, and canonicalizes if you have permissions to 
chdir to the target:


No it work for relative paths too, but with limitation:
path can be relative to the executable location and current work
directory is equal to executable path it works.
I attach my test case (bootstrap.sh) executabel + two dependent shared
libraries from different directories.



The wine is setup with $WINEPREFIX/dosdevices/m: linked MINGWCROSS
Note that MINGWCROSS is absolute path in build system.
Lets see output from the script:

autotool build
=== ./foo-t1.exe ===
in main()
in foo1(11)
in foo2(22)
in foo1(22)
(main) argv[0]  : ./foo-t1.exe
(main) program_name : foo-t1.exe
(find_executable)   : ./foo-t1.exe
(check_executable)  : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t1.exe
(main) found exe (before symlink chase) at :
M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t1.exe
(main) found exe (after symlink chase) at :
M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t1.exe
(main) libtool target name: foo.exe
(lt_setenv) setting 'BIN_SH' to 'xpg4'
(lt_setenv) setting 'DUALCASE' to '1'
(lt_update_lib_path) modifying 'PATH' by prepending
'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;' 


(lt_setenv) setting 'PATH' to
'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin' 


(lt_update_exe_path) modifying 'PATH' by prepending
';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;' 


(lt_setenv) setting 'PATH' to
';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin' 

(main) lt_argv_zero : 
M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo.exe

(main) newargz[0]   :
M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo-t1.exe
DONE[t1]=126
=== ./foo-t2.exe ===
in main()
in foo1(11)
in foo2(22)
in foo1(22)
(main) argv[0]  : ./foo-t2.exe
(main) program_name : foo-t2.exe
(find_executable)   : ./foo-t2.exe
(check_executable)  : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t2.exe
(main) found exe (before symlink chase) at :
M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t2.exe
(main) found exe (after symlink chase) at :
M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t2.exe
(main) libtool target name: foo.exe
(lt_setenv) setting 'BIN_SH' to 'xpg4'
(lt_setenv) setting 'DUALCASE' to '1'
(lt_update_lib_path) modifying 'PATH' by prepending
'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;'
(lt_setenv) setting 'PATH' to
'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin' 


(lt_update_exe_path) modifying 'PATH' by prepending
';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;' 


(lt_setenv) setting 'PATH' to
';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin' 

(main) lt_argv_zero : 
M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo.exe

(main) newargz[0]   :
M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo-t2.exe
DONE[t2]=126

Re: [PATCH] [mingw] Add cross-compile support to cwrapper

[Roumen Petrov]

Charles Wilson wrote:

Roumen Petrov wrote:

Charles Wilson wrote:

[mingw] Add cross-compile support to cwrapper


May be the patch can be more simple. In a previous post I confirm that 
for the wine emulator is enough items in path list, where every item 
is absolute path from build system, to be separated by DOS 
path-separator only.


Right, and thank you for that. What wasn't clear, however, was whether 
this automatic path translation was a peculiarity of your wine setup 
(e.g. identity mounts or something) or is a documented feature of wine.


Automatic path translation work for me. I may ask wine-developers to
confirm.


This is enough and at run-time wine(wineloader?) will translate 
internally from build system absolute path to the path from 
emulated environment.


So it only works for absolute paths, but is applied to all environment 
variables (like PATH)?


winepath will convert relative paths, AFAICT, although it converts them 
to absolute first, and canonicalizes if you have permissions to chdir to 
the target:


No it work for relative paths too, but with limitation:
path can be relative to the executable location and current work
directory is equal to executable path it works.
I attach my test case (bootstrap.sh) executabel + two dependent shared
libraries from different directories.



The wine is setup with $WINEPREFIX/dosdevices/m: linked MINGWCROSS
Note that MINGWCROSS is absolute path in build system.
Lets see output from the script:

autotool build
=== ./foo-t1.exe ===
in main()
in foo1(11)
in foo2(22)
in foo1(22)
(main) argv[0]  : ./foo-t1.exe
(main) program_name : foo-t1.exe
(find_executable)   : ./foo-t1.exe
(check_executable)  : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t1.exe
(main) found exe (before symlink chase) at :
M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t1.exe
(main) found exe (after symlink chase) at :
M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t1.exe
(main) libtool target name: foo.exe
(lt_setenv) setting 'BIN_SH' to 'xpg4'
(lt_setenv) setting 'DUALCASE' to '1'
(lt_update_lib_path) modifying 'PATH' by prepending
'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;'
(lt_setenv) setting 'PATH' to
'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin'
(lt_update_exe_path) modifying 'PATH' by prepending
';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;'
(lt_setenv) setting 'PATH' to
';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin'
(main) lt_argv_zero : M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo.exe
(main) newargz[0]   :
M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo-t1.exe
DONE[t1]=126
=== ./foo-t2.exe ===
in main()
in foo1(11)
in foo2(22)
in foo1(22)
(main) argv[0]  : ./foo-t2.exe
(main) program_name : foo-t2.exe
(find_executable)   : ./foo-t2.exe
(check_executable)  : M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t2.exe
(main) found exe (before symlink chase) at :
M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t2.exe
(main) found exe (after symlink chase) at :
M:\1\lt-HEAD-mingw-mlib-autotools\appl/./foo-t2.exe
(main) libtool target name: foo.exe
(lt_setenv) setting 'BIN_SH' to 'xpg4'
(lt_setenv) setting 'DUALCASE' to '1'
(lt_update_lib_path) modifying 'PATH' by prepending
'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;'
(lt_setenv) setting 'PATH' to
'MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin'
(lt_update_exe_path) modifying 'PATH' by prepending
';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;'
(lt_setenv) setting 'PATH' to
';MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;/tmp/test/pkg/lt-HEAD-mingw-mlib/lib;/tmp/test/pkg/lt-HEAD-mingw-mlib/bin;MINGWCROSS/1/lt-HEAD-mingw-mlib-autotools/lib2/.libs;../lib1/.libs;c:\windows\system32;c:\windows;z:\opt\mingw\bin;z:\opt\mingw\gtk2\bin'
(main) lt_argv_zero : M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo.exe
(main) newargz[0]   :
M:/1/lt-HEAD-mingw-mlib-autotools/appl/./.libs/foo-t2.exe
DONE[t2]=126


The libtool create C-wrapper with absolute paths.
- foo-t1.exe, where ':' is replaced with ';' : can be run from any location.
- foo-t1.exe, where path to one of libraries is relative

Re: [PATCH] [mingw] Add cross-compile support to cwrapper

[Roumen Petrov]

Charles Wilson wrote:

[mingw] Add cross-compile support to cwrapper

* libltdl/config/ltmain.m4sh (func_to_host_path):
If present, use winepath to convert from $build to $host
if $host is mingw and $build is neither mingw (msys) nor
cygwin. Also update comments.
(func_to_host_pathlist): Ditto.
---
This is a follow-on to the recent patch dealing with the cwrapper
for mingw and cygwin. This patch adds the ability for cross-compile
setups (where $host=mingw and $build=not mingw/msys, not cygwin, 
but some *nix with wine) to generate correct binary wrappers.


winepath, if found, is used to convert $build (unix) paths to
the appropriate windows-style paths /inside/ the wine environment.
If winepath is not found, then the $build path will be used by
the cwrapper (which is the current behavior for cross-compile to
mingw $host).  Obviously, the $build path is not correct, so the
cwrapper won't work -- but the build will continue successfully
after printing a warning, so no harm.

However, I can't test this patch directly.  The concepts work in 
my stripped-down wine-on-linux install, but I don't have a full

mingw environment to test the whole thing in.  I *did* verify that
this patch causes no regressions for native cygwin, and native mingw.

Also, I think that, even in the best of cases and everything works
as I expect, you'll either have have the linux binfmt extension
working to actually run the test suite in a cross-compile setup, 
because I don't know how you'd convince the testsuite machinery

to prefix every program invocation with '/path/to/wine ...'

Anyway; please /test/.

Chuck


 libltdl/config/ltmain.m4sh |   97 +--
 1 files changed, 65 insertions(+), 32 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 0bfae76..197920c 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2515,12 +2515,19 @@ func_emit_wrapper ()
 #
 # Convert paths to build format when used with build tools.
 # Intended for use with native mingw (where libtool itself
-# is running under the msys shell). Ordinarily, the (msys) shell
-# automatically converts such things for non-msys applications
-# it launches, but that isn't available from inside the cwrapper.
-# Similar accommodations are necessary for $host mingw and $build
-# cygwin.  Calling this function does no harm on other $build or
-# for other $host.
+# is running under the msys shell), or in the following cross-
+# build environments:
+#$build  $host
+#mingw (msys)mingw  [e.g. native]
+#cygwin  mingw
+#*nix + wine mingw
+# where wine is equipped with the `winepath' executable.
+# In the native mingw case, the (msys) shell automatically
+# converts paths for any non-msys applications it launches,
+# but that facility isn't available from inside the cwrapper.
+# Similar accommodations are necessary for $host mingw and
+# $build cygwin.  Calling this function does no harm for other
+# $host/$build combinations not listed above.
 #
 # ARG is the path (on $build) that should be converted to
 # the proper representation for $host. The result is stored
@@ -2546,6 +2553,13 @@ func_to_host_path ()
 func_to_host_path_result=`echo $func_to_host_path_tmp1 |\
   $SED -e $lt_sed_naive_backslashify`
 ;;
+  * )
+if winepath -h /dev/null 21 ; then
+  func_to_host_path_tmp1=`winepath -w $1`
+  func_to_host_path_result=`echo $func_to_host_path_tmp1 |\
+$SED -e $lt_sed_naive_backslashify`
+fi
+;;
 esac
 if test -z $func_to_host_path_result ; then
   func_error Could not determine host path corresponding to
@@ -2561,12 +2575,18 @@ func_to_host_path ()
 # func_to_host_pathlist arg
 #
 # Convert pathlists to build format when used with build tools.
-# See func_to_host_path(), above.
+# See func_to_host_path(), above. This function supports the
+# following $build/$host combinations (but does no harm for
+# combinations not listed here):
+#$build  $host
+#mingw (msys)mingw  [e.g. native]
+#cygwin  mingw
+#*nix + wine mingw
 #
-# Path separators are also converted from ':' to ';', and if
-# $1 begins or ends with a ':' it is preserved (as ';') on
-# output. This description applies only when $build is mingw
-# (msys) or cygwin, and $host is mingw.
+# Path separators are also converted from $build format to
+# $host format. If ARG begins or ends with a path separator
+# character, it is preserved (but converted to $host format)
+# on output.
 #
 # ARG is a pathlist (on $build) that should be converted to
 # the proper representation on $host. The result is stored
@@ -2578,16 +2598,12 @@ func_to_host_pathlist ()
 case $host in
   *mingw* )
 lt_sed_naive_backslashify='s|*|\\|g;s|/|\\|g;s|\\||g'
-case $build in
-  *mingw* | *cygwin* )
-  

Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.

[Roumen Petrov]

Hi Charles,

About following comment:
/* execv doesn't actually work on mingw as expected on unix */

Actually execXXX on microsoft windows create a new process and it is not 
mingw problem. What about to substitute mingw with windows ?


Roumen


Charles Wilson wrote:

Charles Wilson wrote:

2008-05-05  Charles Wilson  ...

* libltdl/config/ltmain.m4sh (func_to_native_path):
new function. If $host is mingw, and $build is mingw
or cygwin, convert path to mingw native format.
(func_to_native_pathlist): new function. Ditto, for
:-separated pathlists.
(func_emit_cwrapperexe_src) [__CYGWIN__  __STRICT_ANSI__]:
ensure putenv and setenv are declared. Define HAVE_SETENV.
(func_emit_cwrapperexe_src) [main]: add new constants to
hold desired PATH settings; initialize and convert to native
mingw format using functions above. Add new command-line
options --lt-env-set, --lt-env-prepend, and --lt-env-append.
No longer emit wrapper script as integral part of launching
child. Remove support for (now) unnecessary $TARGETSHELL.
Exec actual target executable directly.
(func_emit_cwrapperexe_src) [lt_setenv]: new function.
(func_emit_cwrapperexe_src) [lt_extend_str]: new function.
(func_emit_cwrapperexe_src) [lt_split_name_value]: new function.
(func_emit_cwrapperexe_src) [lt_opt_process_env_set]: new function.
(func_emit_cwrapperexe_src) [lt_opt_process_env_prepend]: new 
function.
(func_emit_cwrapperexe_src) [lt_opt_process_env_append]: new 
function.

(func_emit_cwrapperexe_src) [lt_update_exe_path]: new function.
(func_emit_cwrapperexe_src) [lt_update_lib_path]: new function.



The attached patch (to be applied over the previous one) addresses the 
comments received so far. I can post the merged patch if desired -- and 
of course, I'll squash into a single patch before I push.


Cygwin: passes 115 (9 skip) on old test suite
only two unexpected failures on new test suite -- but 25 and 72 are 
actually expected on cygwin.


Mingw (msys): no regressions over previous results:
old test suite: fails demo-exec after demo-shared (helldl)
fails the fortran tests, but that's a peculiarity of my system

new test suite: fails 25 and 72 (expected), and 58-60 (a problem with 
the autotool wrappers on my system)


OK for push?

--
Chuck

Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.

[Roumen Petrov]

Charles Wilson wrote:

Charles Wilson wrote:

2008-05-05  Charles Wilson  ...

* libltdl/config/ltmain.m4sh (func_to_native_path):
new function. If $host is mingw, and $build is mingw
or cygwin, convert path to mingw native format.
(func_to_native_pathlist): new function. Ditto, for
:-separated pathlists.
(func_emit_cwrapperexe_src) [__CYGWIN__  __STRICT_ANSI__]:
ensure putenv and setenv are declared. Define HAVE_SETENV.
(func_emit_cwrapperexe_src) [main]: add new constants to
hold desired PATH settings; initialize and convert to native
mingw format using functions above. Add new command-line
options --lt-env-set, --lt-env-prepend, and --lt-env-append.
No longer emit wrapper script as integral part of launching
child. Remove support for (now) unnecessary $TARGETSHELL.
Exec actual target executable directly.
(func_emit_cwrapperexe_src) [lt_setenv]: new function.
(func_emit_cwrapperexe_src) [lt_extend_str]: new function.
(func_emit_cwrapperexe_src) [lt_split_name_value]: new function.
(func_emit_cwrapperexe_src) [lt_opt_process_env_set]: new function.
(func_emit_cwrapperexe_src) [lt_opt_process_env_prepend]: new 
function.
(func_emit_cwrapperexe_src) [lt_opt_process_env_append]: new 
function.

(func_emit_cwrapperexe_src) [lt_update_exe_path]: new function.
(func_emit_cwrapperexe_src) [lt_update_lib_path]: new function.



The attached patch (to be applied over the previous one) addresses the 
comments received so far. I can post the merged patch if desired -- and 
of course, I'll squash into a single patch before I push.


Cygwin: passes 115 (9 skip) on old test suite
only two unexpected failures on new test suite -- but 25 and 72 are 
actually expected on cygwin.


Mingw (msys): no regressions over previous results:
old test suite: fails demo-exec after demo-shared (helldl)
fails the fortran tests, but that's a peculiarity of my system

new test suite: fails 25 and 72 (expected), and 58-60 (a problem with 
the autotool wrappers on my system)


OK for push?

--
Chuck




libtool 2.2.4 patched with both patches still fail:
...
(lt_setenv) setting 'PATH' to 
':/usr/local/src//lt-2.2.4-mingw-mlib/lib2/.libs:/usr/local/src//lt-2.2.4-mingw-mlib/lib1/.libs:/tmp/test/pkg/lt-2.2.4-mingw-mlib/lib:/tmp/test/pkg/lt-2.2.4-mingw-mlib/bin:/usr/local/src//lt-2.2.4-mingw-mlib/lib2/.libs:/usr/local/src//lt-2.2.4-mingw-mlib/lib1/.libs:c:\windows\system32;c:\windows;z:\opt\mingw\bin'

(main) lt_argv_zero : Z://lt-2.2.4-mingw-mlib/appl/.libs/foo.exe
(main) newargz[0]   : Z://lt-2.2.4-mingw-mlib/appl/.libs/foo.exe
err:module:import_dll Library libfoo2.dll (which is needed by 
LZ:\\\\lt-2.2.4-mingw-mlib\\appl\\.libs\\foo.exe) not found

...

The PATH contain unix instead dos path-separator.

Roumen

Re: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.

[Roumen Petrov]

Charles Wilson wrote:

Roumen Petrov wrote:


libtool 2.2.4 patched with both patches still fail:
...
(lt_setenv) setting 'PATH' to 
':/usr/local/src//lt-2.2.4-mingw-mlib/lib2/.libs:/usr/local/src//lt-2.2.4-mingw-mlib/lib1/.libs:/tmp/test/pkg/lt-2.2.4-mingw-mlib/lib:/tmp/test/pkg/lt-2.2.4-mingw-mlib/bin:/usr/local/src//lt-2.2.4-mingw-mlib/lib2/.libs:/usr/local/src//lt-2.2.4-mingw-mlib/lib1/.libs:c:\windows\system32;c:\windows;z:\opt\mingw\bin' 


(main) lt_argv_zero : Z://lt-2.2.4-mingw-mlib/appl/.libs/foo.exe
(main) newargz[0]   : Z://lt-2.2.4-mingw-mlib/appl/.libs/foo.exe
err:module:import_dll Library libfoo2.dll (which is needed by 
LZ:\\\\lt-2.2.4-mingw-mlib\\appl\\.libs\\foo.exe) not found

...

The PATH contain unix instead dos path-separator.


Right.  With *this* patch, I do not expect improvement with 
cross-compiles. This is just the first step. To get cross-compiles 
working, I need to *extend* this change using some of the techniques 
demonstrated in the 'convert_mingw_paths_with_wine.sh' script -- which 
is the #3 attachment to this message:

http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00164.html

One step at a time

--
Chuck



I confirm that in cross environment (wine emulation) is enough to 
replace all ':' (unix) with ';' (dos) in LIB_PATH_VALUE and 
LIB_PATH_VALUE to get cwrapper to work.


Roumen

Re: Feature request: setting env vars for binary wrappers

[Roumen Petrov]

Behdad Esfahbod wrote:

On Fri, 2008-04-18 at 02:32 +0300, Roumen Petrov wrote:

Behdad Esfahbod wrote:

[SNIP]
But if user run directly an application installed in non-default 
location the user is responsible to set environment.

I'm not talking about application installed in non-default location.
I'm talking about uninstalled application.

There is no significant difference !


I thought there is.  The former is not supported, while I'm under the
impression that the latter is.


If its a regression/unit test the correct application environment has
to 
be set in Makefile{|.in|.am} and the program/library will inherit it.

No, it's not a test suite.  It's a real, legitimate application the user
has built.  Now he wants to run it before doing make install.
And if application don't read environment, next request is libtool 
wrapper script to pass arguments to application command line.


The argument passing is part of the patch too.  But one or the other is
enough, because the application developer can use whatever is available
to them.  Currently, there is no way to fix this problem with autotools.
With the proposed changes, there will be.  That's all.



About no way to fix this problem with autotools. Why ?
As example libxml can run binaries from build dir. In one of the tests 
is created specific xml catalog and application is run with this catalog 
instead with system.






The whole idea is libtool overkill.


Fair enough.  Just suggest an alternative please, instead of acting as
if the problem does not exist.


Roumen

Re: Feature request: setting env vars for binary wrappers

[Roumen Petrov]

Behdad Esfahbod wrote:

On Fri, 2008-04-18 at 21:53 +0300, Roumen Petrov wrote:

In some cases application depend from other services.
In this case a specific to project wrapper script has to run
services, 
to check if service is run, to run project application and when 
application finish to stop service. The test can be run from makefile.


Now I'm getting the impression that you selectively read the responses
in this thread and ignore the rest.  Please tell me *how*, from makefile
or otherwise, the problem can be solved such that when my user goes into
his build directory and runs the command:

$ ./pango-view

how as the developer, I can make that command run in a modified
environment?



I perfectly know this problem. Un-installed application cannot be run 
without to prepared suitable environment. About six years I maintain 
X.509 certificate support in OpenSSH and I perfectly know that user 
cannot go in build-dir and just to run secure shell daemon/client.


Roumen

Re: Feature request: setting env vars for binary wrappers

[Roumen Petrov]

Ralf Wildenhues wrote:

* Bob Friesenhahn wrote on Fri, Apr 18, 2008 at 09:15:55PM CEST:
The only substantial change is for static builds which currently 
don't have a wrapper.


Yes.

The static build is a more significant concern since static builds are 
often used for debugging purposes and if we hide the static binary in a 
subdirectory, it may be more difficult to debug.


Good point, thanks.

We need to make sure 
that it is both possible to obtain the necessary run-time environment, 
and to run the debugger on the correct binary.  Proposals for the 
cleanest way to do that are appreciated.


Well, did this cease to work (except for the bug which was fixed in
2.2.2)?
  ./libtool --mode=execute gdb ./prog --args ...



I think that existing --mode=execute is enough.

Roumen

Re: Feature request: setting env vars for binary wrappers

[Roumen Petrov]

Behdad Esfahbod wrote:

On Fri, 2008-04-18 at 22:27 +0300, Roumen Petrov wrote:
I perfectly know that user 
cannot go in build-dir and just to run secure shell daemon/client.


And if you are happy with that, good for you.


:)


In GNOME

Ohh no


though, we want
our users to be able to run uninstalled programs.  If this feature is
not interesting to you, fine.  I don't understand why you are so
opposing it.  Apparently not on any technical reasoning.



For my users, from make and some wrapper script, I setup environment, 
run some servers (as example openldap with preloaded data) run 
un-installed programs so my users see that things work before to install.


Roumen

Re: Feature request: setting env vars for binary wrappers

[Roumen Petrov]

Behdad Esfahbod wrote:

On Tue, 2006-06-13 at 17:00 -0400, Ralf Wildenhues wrote:

[ this is: http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5319
or http://lists.gnu.org/archive/html/bug-libtool/2006-03/msg00013.html ]

Hi Behdad, everyone,


Hi again,


Sorry for the delay again.


So, yeah, replying after two years... I know.  Hope you still remember
this issue and the patch is not too stale by now...



* Behdad Esfahbod wrote on Thu, Mar 09, 2006 at 04:59:38PM CET:

On Wed, 1 Mar 2006, Ralf Wildenhues wrote:

* Behdad Esfahbod wrote on Wed, Mar 01, 2006 at 05:15:17AM CET:

This is a feature request for libtool.  Let me describe the
problem as I face it, so you may have a workaround for it
already:  I'm using libtool in the Pango text rendering engine.
The Pango library accesses a file in $prefix/etc/pango/pangorc to
find its modules at run-time.  Now all I want to do is to be able
to run the examples in pango/example when Pango is not installed.

The easiest way that can be done is to set the PANGO_RC_PATH
envvar to a special pangorc file.  Another is to pass the
--pangorc path-to-pango-rc to the examples if they understand it.
What I need from libtool is to let me do one of these things in
the wrapper it creates for uninstalled binaries.

[ my concerns were: we don't always build a wrapper ATM. ]


Sure, a wrapper is created if need be.  And this feature can be just
another reason to create a wrapper.


If we can find an answer to this question to define coherent semantics,
I'm all for it.

Ok, this is my view of the problem:  Running uninstalled programs
requires some modifications to the environment.  One is to make
sure that the uninstalled libraries are linked.  Other changes
may be needed, on a per application basis.  Libtool is free to
choose how to implement these.  So far it has only supported the
library path modification, and implemented that using a wrapper
script on some platforms, or using rpath on others (right?)

More or less, yes.


The same goes with the other modifications.  They can be easily
implemented using a wrapper.  So if there are such modifications
requested, a wrapper should be used.

Yep.  And that's really the easiest solution: as soon as extra arguments
or extra environment variables are passed, we always build a wrapper.


My current workaround has been making pango-view accept a
--pangorc path-to-pangorc parameter and defaulting to ./pangorc.
But that opens up a known security problem...  So I really want
to fix it the right way.

I don't quite understand how this fixes any security problems...
but here you go with a suggestion (against current CVS HEAD).


The attached patch implements two new link flags, -wrapper-arg and
-wrapper-env, to prepend arguments to programs, and modify their
environment.  They will force creating a (shell) wrapper.

Here's the hairy part about it: somebody may eventually want to extend
the C wrapper that is currently used on w32 to encompass all the
functionality that the shell wrapper currently has.  And while I don't
have current plans about this, I still don't want to add any
unnecessary obstackles to it.


Fair enough.



So whatever we add to the shell wrapper should be doable easily in a C
wrapper as well.  This led me to add these restrictions:  the
-wrapper-env works like putenv: you pass an argument `var=value', the
variable will be exported, the value will _not_ be interpreted by the
shell any more.  For now you cannot unset variables (this is to cater
for hosts with a shell that does not support `unset'), and, e.g.,
  -wrapper-env 'foo=$bar'

will cause the environment variable `foo' to contain the four characters
$, b, a, and r, not the contents of the variable $bar.


But make variables are expanded, right?


Similarly, -wrapper-arg will add exactly one literal argument to the
exec.  I've put suitable quoting in place for this to work with most
kinds of input, and of course a test to this end.

What do you think?  OK for HEAD right now, or do you think this is too
intrusive now?


Sounds good to me.  Can it finally go in?!


I think we should not backport this to 1.5.x, it is a new feature.

Cheers,
Ralf


Cheers,


I think that all above is out of libtool scope.
It's is exceptional project specific (lets skip cross-compilation 
environment) and is subject of project regression test suite.
The project is responsible to set appropriate test environment before to 
run regression test.

Please let me know when I don't understand request properly.

Roumen

Re: Feature request: setting env vars for binary wrappers

[Roumen Petrov]

Behdad Esfahbod wrote:

On Thu, 2008-04-17 at 23:38 +0300, Roumen Petrov wrote:


I think that all above is out of libtool scope.
It's is exceptional project specific (lets skip cross-compilation 
environment) and is subject of project regression test suite.

The project is responsible to set appropriate test environment before
to run regression test.
Please let me know when I don't understand request properly.


It's not about regression testing at all.  It's about making binaries in
uninstalled builds work.  For example, many GNOME applications need to
load their UI from XML files.  If you build and not install them and try
to run from the build dir, not surprisingly, the XML file is not found
at destination, and the program will fail to start.  With my proposed
additions, programs can for example check for an env var for an
alternative prefix, and the Makefile.am can pass that information to
libtool to put into the wrapper.  Then running from uninstalled build
will work.

If running uninstalled build is not a goal, why bother about
LD_LIBRARY_PATH'ing the uninstalled library path at all?


Roumen


Cheers,


Exactly, libtool do home work and set LD_LIBRARY_PATH (DYLD_LIBRARY_PATH 
, LIBRARY_PATH, PATH and etc. host/platform specific environment library 
search paths) but for application specific environment is author/project 
responsibility. I see that you understand case when a library isn't 
installed at specified(system) location. This library will load 
dependent libraries from default(system) library search path. So the 
wrapper script help correct library to be loaded so the libtool home 
work is done.
But if user run directly an application installed in non-default 
location the user is responsible to set environment.
If its a regression/unit test the correct application environment has to 
be set in Makefile{|.in|.am} and the program/library will inherit it.


Roumen

Re: Feature request: setting env vars for binary wrappers

[Roumen Petrov]

Behdad Esfahbod wrote:

[SNIP]
But if user run directly an application installed in non-default 
location the user is responsible to set environment.


I'm not talking about application installed in non-default location.
I'm talking about uninstalled application.


There is no significant difference !



If its a regression/unit test the correct application environment has
to 
be set in Makefile{|.in|.am} and the program/library will inherit it.


No, it's not a test suite.  It's a real, legitimate application the user
has built.  Now he wants to run it before doing make install.


And if application don't read environment, next request is libtool 
wrapper script to pass arguments to application command line.


The whole idea is libtool overkill.

Roumen