Re: [PATCH] ltmain.in: don't suppress output for PIC compilations

2024-08-16 Thread Roumen Petrov
static vs shared build are not related to build process trace. Why to output static build as in 99.999% cases is same as shared? Cheers, Nick Regards, Roumen Petrov

Re: [PATCH] Correct DLL Installation Path for x86_64-w64-mingw32 Multilib

2024-05-21 Thread Roumen Petrov
На 19.05.24 г. в 9:28 ч., trcrsired написа: From: cqwrteur <100043421+trcrsi...@users.noreply.github.com> GCC folks ask me to submit it to upstream. see: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651670.html When building native GCC for the x86_64-w64-mingw32 host, the compiler copies

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

2024-04-17 Thread 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 an

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

2024-01-21 Thread 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 `l

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

2024-01-17 Thread 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.

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

2024-01-16 Thread 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

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

2024-01-16 Thread Roumen Petrov
nctionality 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

2024-01-16 Thread 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

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

2024-01-16 Thread Roumen Petrov
C’ 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

2024-01-16 Thread 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 .

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

2024-01-16 Thread Roumen Petrov
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

2024-01-16 Thread Roumen Petrov
. 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

2023-09-20 Thread 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 -s

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

2018-08-17 Thread 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. Sim

Re: small fix of libtool.m4

2016-05-09 Thread 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 u

Re: Windows Line Endings

2012-10-09 Thread 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.

Re: Windows Line Endings

2012-10-08 Thread 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'

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

2012-10-07 Thread Roumen Petrov
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 Dat

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

2012-10-07 Thread 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 a

Re: Windows Line Endings

2012-10-07 Thread 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 D

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

2012-09-19 Thread 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

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

2012-09-19 Thread 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 --- tests/deplibs

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

2012-09-19 Thread 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 --- tests/with-

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

2012-09-19 Thread 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. Sig

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

2012-09-19 Thread 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 --- tests/deplibs-mingw.at |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)

Re: restore EXPORT check

2012-02-01 Thread 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

2011-12-12 Thread 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.ht

restore EXPORT check

2011-11-30 Thread 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 Date: Thu, 1 Dec 2011 00:38:16

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

2011-11-21 Thread 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 boo

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

2011-10-31 Thread 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 be

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

2010-09-25 Thread 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 (nc

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

2010-09-24 Thread 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&#

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

2010-09-24 Thread Roumen Petrov
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

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

2010-09-20 Thread 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

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

2010-09-17 Thread 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

Re: w32 pending?

2010-09-17 Thread 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 loca

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

2010-08-29 Thread Roumen Petrov
Peter Rosin wrote: Den 2010-08-27 00:27 skrev 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 c

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

2010-08-26 Thread 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 +# fou

Re: [PATCH: sysroot branch] [cygwin] Minor sysroot fixups.

2010-08-23 Thread Roumen Petrov
Charles Wilson wrote: On 8/23/2010 1:44 AM, Ralf Wildenhues wrote: * Charles Wilson wrote on Mon, Aug 23, 2010 at 07:35:59AM CEST: libltdl/m4/libtool.m4 (_LT_WITH_SYSROOT): Fix typo. tests/sysroot.at: Search also for crt0.o to accomodate cygwin. accommodate fixed. Discovered a few minor i

abs-bindir support + tests

2009-11-29 Thread Roumen Petrov
Hi All, Please find attached - libtool-origin-abs_bindir.patch.gz : path for absolute bindir support including tests - libtool-origin-abs_bindir-tests.gz : result of my tests Roumen libtool-origin-abs_bindir.patch.gz Description: GNU Zip compressed data libtool-origin-abs_bindir-tests.g

abs-bindir Was: bindir for libtool

2009-11-02 Thread Roumen Petrov
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 + + Control where to place shared libraries for system without + shared library path variable diff

bindir for libtool

2009-08-24 Thread 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 ap

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

2009-08-20 Thread 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

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

2009-08-18 Thread 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

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

2009-08-17 Thread 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 b

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

2009-08-16 Thread 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&#

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

2009-08-16 Thread 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

Re: Status of the MSYS/MSVC port

2009-01-29 Thread Roumen Petrov
Peter Rosin wrote: Den 2009-01-29 00:45 skrev Roumen Petrov: 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 d

Re: Status of the MSYS/MSVC port

2009-01-29 Thread 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 -W

Re: Status of the MSYS/MSVC port

2009-01-28 Thread 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

Re: Status of the MSYS/MSVC port

2009-01-28 Thread Roumen Petrov
Peter Rosin wrote: Den 2009-01-28 04:25 skrev Charles Wilson: Peter Rosin wrote: [SNIP] #ifndef _STAT_DEFINED struct _stat { [SNIP] }; #endif /* _STAT_DEFINED */ int _stat (const char *, struct _stat *); [SNIP] I think that we has to be careful about structure _stat and version of msvcrt

Re: testsuite performance

2009-01-23 Thread 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

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

2009-01-04 Thread 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/min

Re: use $EXEEXT consistently in new testsuite

2009-01-04 Thread 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 995c8f

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

2009-01-04 Thread 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 -

Re: use $EXEEXT consistently in new testsuite

2008-11-27 Thread Roumen Petrov
Ralf Wildenhues wrote: Hi Roumen, * Roumen Petrov wrote on Wed, Nov 26, 2008 at 12:46:00AM CET: I will check this failure: 28: Runpath in libtool library filesFAILED (runpath-in-lalib.at:59) You recent commit fix this 10x. The other not "ok" test: 21: F77 c

Re: use $EXEEXT consistently in new testsuite

2008-11-25 Thread 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

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

2008-11-18 Thread 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

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

2008-11-17 Thread 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

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

2008-11-12 Thread 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

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

2008-11-12 Thread 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

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

2008-11-12 Thread 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

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

2008-11-12 Thread 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, [STAT

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

2008-11-12 Thread Roumen Petrov
Ralf Wildenhues wrote: Hello Charles, Roumen, [SNIP] diff --git a/tests/destdir.at b/tests/destdir.at index 8ce8df3..386c728 100644 --- 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 $l

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

2008-05-31 Thread 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

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

2008-05-27 Thread 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

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

2008-05-21 Thread 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 pe

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

2008-05-20 Thread 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

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

2008-05-18 Thread 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

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

2008-05-17 Thread 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. --

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

2008-05-10 Thread 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/li

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

2008-05-10 Thread 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,

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

2008-05-10 Thread 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:

Re: Feature request: setting env vars for binary wrappers

2008-04-18 Thread 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

Re: Feature request: setting env vars for binary wrappers

2008-04-18 Thread 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

Re: Feature request: setting env vars for binary wrappers

2008-04-18 Thread 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

Re: Feature request: setting env vars for binary wrappers

2008-04-18 Thread Roumen Petrov
Bob Friesenhahn wrote: On Fri, 18 Apr 2008, Roumen Petrov wrote: 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. This statement is a little "over the top".

Re: Feature request: setting env vars for binary wrappers

2008-04-18 Thread 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-de

Re: Feature request: setting env vars for binary wrappers

2008-04-17 Thread 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 differen

Re: Feature request: setting env vars for binary wrappers

2008-04-17 Thread 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 t

Re: Feature request: setting env vars for binary wrappers

2008-04-17 Thread 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,