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

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

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

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

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

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

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

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

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

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

ef 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

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

e 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

. 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

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

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

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.

Re: small fix of libtool.m4

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

Re: Windows Line Endings

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

Re: Windows Line Endings

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

Re: Windows Line Endings

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

Re: restore EXPORT check

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

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

restore EXPORT check

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

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

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

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

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

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

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

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

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

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

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

Re: w32 pending?

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

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

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: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

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,

abs-bindir Was: bindir for libtool

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

bindir for libtool

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

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

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.

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

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

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

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

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

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

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

Re: Status of the MSYS/MSVC port

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

Re: Status of the MSYS/MSVC port

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

Re: Status of the MSYS/MSVC port

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

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: use $EXEEXT consistently in new testsuite

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

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

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: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.

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

Re: use $EXEEXT consistently in new testsuite

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

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

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: testsuite.at for version 2.x Was: ... mingw-cross, check-local fail for DESTDIR tests

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,

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

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

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: libtool(20080421), mingw-cross, check-local fail for DESTDIR tests

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: [PATCH] [mingw] Add cross-compile support to cwrapper

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

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

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

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

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

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

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

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

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.

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: [PATCH] [mingw|cygwin] Modify cwrapper to invoke target directly.

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.

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

Re: Feature request: setting env vars for binary wrappers

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

Re: Feature request: setting env vars for binary wrappers

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

Re: Feature request: setting env vars for binary wrappers

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

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

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,

Re: Feature request: setting env vars for binary wrappers

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

Re: Feature request: setting env vars for binary wrappers

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