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
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,
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
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
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
Russ Allbery wrote:
Roumen Petrov [EMAIL PROTECTED] writes:
Russ Allbery wrote:
Debian's experience to date is that --as-needed is buggy and breaks a
lot of software, and overall is not a particularly stable solution.
Removing *.la files so that the unneeded shared libraries aren't linked
[SNIP]
But problem is not in the libtool.
Yes it is. If you're linking to libfoo, libtool reads libfoo.la and
adds direct links to everything in dependency_libs. Let's say libfoo
depends on libbar and libbaz. You're application ends up directly
linking to libfoo, libbar and libbaz instead of
Russ Allbery wrote:
Roumen Petrov [EMAIL PROTECTED] writes:
Russ Allbery wrote:
When you create a libtool library, libtool records every library
against which that library was linked into the *.la file. If you then
link another shared library against that shared library using libtool
Dan Nicholson wrote:
On Sat, Nov 8, 2008 at 9:22 AM, Roumen Petrov
[EMAIL PROTECTED] wrote:
[SNIP]
But problem is not in the libtool.
Yes it is. If you're linking to libfoo, libtool reads libfoo.la and
adds direct links to everything in dependency_libs. Let's say libfoo
depends on libbar
Russ Allbery wrote:
Roumen Petrov [EMAIL PROTECTED] writes:
It was old build bug when building readline library on some linux-es. In
my memory is suse 7.1 but I'm sure that only this particular version was
affected.
Many other linux verdors build readline without dependent libraries
Russ Allbery wrote:
Roumen Petrov [EMAIL PROTECTED] writes:
Russ Allbery wrote:
libreadline is linked against libncurses on Debian.
Which version ?
readline 5.2-3, ncurses 5.7-2.
No,no debian version/release.
This is an 7(5?) years old linux bug.
I'm very dubious
Hi Russ,
Russ Allbery wrote:
Ralf Wildenhues [EMAIL PROTECTED] writes:
Hello Russ,
* Russ Allbery wrote on Fri, Nov 07, 2008 at 01:20:28AM CET:
The most frequent problem caused by *.la files is that they add a pile
of unnecessary dependencies to shared libraries, which further
entangles
Dan Nicholson wrote:
On Mon, Nov 3, 2008 at 2:05 PM, Ralf Wildenhues [EMAIL PROTECTED] wrote:
[SNIP]
Oh, well. You do know that all the linux distros (that I know of)
remove the .la files, right?
NO
I was sort of hoping there would be a
nice way to do that.
Check content of so called
Vincent Torri wrote:
On Tue, 7 Oct 2008, Roumen Petrov wrote:
Vincent Torri wrote:
Hey,
Even if i'm still waiting for an answer about the func_win32_libid()
function, here is the 2nd problem:
On Sun, 5 Oct 2008, Ralf Wildenhues wrote:
2) 2nd qestion: I have the following message from
Vincent Torri wrote:
Hey,
Even if i'm still waiting for an answer about the func_win32_libid()
function, here is the 2nd problem:
On Sun, 5 Oct 2008, Ralf Wildenhues wrote:
2) 2nd qestion: I have the following message from libtool (which i do
not have with other compilers):
libtool:
Jason Curl wrote:
Hello,
Recently some info was posted about using resource files with Windows
compilers. I'm trying to generate a reasonably simple Version resource and
there's some information I'm not sure how I can extract from the build process.
I'm using libtool-1.5.27a on MSYS-1.0.10
Bernd Jendrissek wrote:
On Sat, Jun 14, 2008 at 9:59 AM, Alon Bar-Lev [EMAIL PROTECTED] wrote:
Building packages into chroot is more and more common, live-cd,
live-usb, initramfs, embedded, vservers etc...
A lot of packages use libtool, so using the standard gnu build for
chroot environment,
Alon Bar-Lev wrote:
Hello,
I looked at recent libtool-2 versions and could still not find a solution to
compile into chroot.
I want to create an image to embedded device using a cross compiler.
So I do:
mkdir /tmp/device-root
cd /package1
./configure --host= --prefix=/usr
make install
Bob Friesenhahn wrote:
On Thu, 12 Jun 2008, Alon Bar-Lev wrote:
After installing I want to perform:
chroot /tmp/device-root /bin/whatever
And continue from there.
So all elements (linkage, .la) should be related to the chroot and not
to host filesystem.
Why not just add a /tmp/device-root
Vincent Torri wrote:
On Wed, 4 Jun 2008, Ralf Wildenhues wrote:
* Vikram Ambrose wrote on Wed, Jun 04, 2008 at 03:54:35PM CEST:
However I need to pass separate CPPFLAGS to the objects destined for the
shared library as opposed to the objects destined for the library
archive.
As Andreas
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
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
Ralf Wildenhues wrote:
Hello Roumen,
* Roumen Petrov wrote on Fri, May 09, 2008 at 09:39:11PM CEST:
In my environment exist GNU C and Java compilers along with mingw C
cross-compiler. When I build libtool the path to mingw C-compiler (gcc)
precede path to native C-compiler.
In configure
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
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
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
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.
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:
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,
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
Hello libtool Team,
In my environment exist GNU C and Java compilers along with mingw C
cross-compiler. When I build libtool the path to mingw C-compiler (gcc)
precede path to native C-compiler.
In configure output I see :
checking for i386-mingw32msvc-strip... i386-mingw32msvc-strip
Bob Friesenhahn wrote:
On Fri, 9 May 2008, Roumen Petrov wrote:
checking for i386-mingw32msvc-gcj... no
checking for gcj... gcj - OOPS !
Is above detection correct ?
If is detected a prefix for a program why configure try to find a
program without prefix ?
It looks to me like
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
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
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
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
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,
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
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
Alon Bar-Lev wrote:
On 3/28/08, Roumen Petrov [EMAIL PROTECTED] wrote:
You request is to change library name. So I could not understand what is
related to SONAME. It came as a surprise to me to allow user(verdor) to
change library name at configure time.
It for generating a differnet
Alon Bar-Lev wrote:
On 3/29/08, Roumen Petrov [EMAIL PROTECTED] wrote:
So with automake makefile like this :
lib_LTLIBRARIES = @[EMAIL PROTECTED]
@[EMAIL PROTECTED] = module.c
@[EMAIL PROTECTED] = -module -avoid-version
where MODULE is substituted by configure you can get result.
Thanks
Alon Bar-Lev wrote:
On 3/28/08, Peter O'Gorman [EMAIL PROTECTED] wrote:
-rpath is required for proper execution in many environments, the
ability to change the soname is, as far as I can tell, not.
Please present a more convincing argument.
Hello Peter,
I think that infrastructures such
Erik de Castro Lopo wrote:
Hi all,
I have the beginnings of a solution to this issue.
If I hack the libtool generated wrapper script and replace this:
exec $progdir/$program ${1+$@}
with
WINEDLLPATH=$PATH;$WINEDLLPATH
exec wine $progdir/$program ${1+$@}
My test suite
Alon Bar-Lev wrote:
On 3/15/08, Peter Rosin [EMAIL PROTECTED] wrote:
With your suggestion of always using age, you would get dll-7.dll and
dll-8.dll for your examples, but you would also get dll-7.dll for my
example, and then you would have the same file name for two incompatible
dlls, which
Roumen Petrov wrote:
Ralf Wildenhues wrote:
* Roumen Petrov wrote on Sun, Mar 09, 2008 at 05:01:30PM CET:
[SNIP]
Hmm during the tests tests/demo/helldl.exe is compiled many times.
First is ok, later don't produce output(exit code 127) and
tests/demo/.libs/helldl.exe crash.
Roumen
Bruno Haible wrote:
Hi,
A while ago someone said that if in a build directory I have a (not yet
installed) ../lib/libfoo.la, to link with this library I should *not* use
libtool ... -L../lib -lfoo
but rather mention the .la file explicitly:
libtool ... -L../lib ../lib/libfoo.la
or
Roumen Petrov wrote:
Daniel Sands wrote:
I have an executable that dlopens modules, and the modules make use of
symbols provided by the executable. Since AIX does not export symbols
unless either it has to (if needed for direct linkage to a shared
object) or you REALLY want it to (either
Simon Josefsson wrote:
Hi! We have received a bug report about some parts of recent gnutls
(libgnutls-extra.so.26) incorrectly links to the libgnutls.so in
/usr/lib/ rather than in $prefix, see original report:
http://lists.gnu.org/archive/html/gnutls-devel/2007-12/msg00038.html
To understand
Ralf Wildenhues wrote:
* Daniel Herring wrote on Mon, Nov 12, 2007 at 07:46:55AM CET:
Here's a relevant post from the GCC list; it mentions how to work around
some dlopen difficulties (including RTTI, exceptions, custom new/delete).
http://gcc.gnu.org/ml/gcc-help/2007-10/msg00248.html
Russ Allbery wrote:
Simon White [EMAIL PROTECTED] writes:
However if one of those modules internally calls a function that is also
marked as being exported it does not necessarily call the function in
its own library. Depending on order it may call the function that
exists in the other
Jason Curl wrote:
Roumen Petrov wrote:
[SNIP]
Well, I think I've figured it out today (albeit I'm testing on a
different machine, similar software though) and there are two
executables. One in the build directory and one in .libs. e.g.
src/
.libs/
libmofo-1.dll
test/
libtest.exe
Usually /etc/ld.so.conf contain /usr/local/lib.
Dunno why this path is not set on you host.
Benoit SIGOURE wrote:
Hi list,
On GNU/Linux Debian with GCC 4.1 / Debian's libtool 1.5.22-4
(1.1220.2.365 2005/12/18 22:14:06), I have Boost installed under
/usr/local/lib (pre-built binaries:
(distributors) can decide how to create dlls.
Please comment,
Roumen
Roumen Petrov wrote:
Let a project use libtool to make libraries.
In case of mingw build (cross-compilation) in many cases is good dll
to be without lib prefix.
In these cases cross-compilation can create dlls with same names
Let a project use libtool to make libraries.
In case of mingw build (cross-compilation) in many cases is good dll to be
without lib prefix.
In these cases cross-compilation can create dlls with same names as native
build and those dlls can be used instead native build.
The name of import
Hi Raúl,
I would like to know if option SH_WORD_SPLIT is set problem is solved too ?
Test case:
===
#!/bin/zsh
VAR=v1 v2
for V in ${VAR}; do
echo V1=$V
done
setopt SH_WORD_SPLIT
for V in ${VAR}; do
echo V2=$V
done
===
When
101 - 155 of 155 matches
Mail list logo
