On Tue, Apr 04, 2006 at 05:37:44AM -0500, Alexandre Julliard wrote:
Module: wine Branch: refs/heads/master Commit: 197a7d0422b2dd60009e405bc254ca616327fbf0 URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=197a7d0422b2dd60009e405b...
Author: Alexandre Julliard julliard@winehq.org Date: Tue Apr 4 12:08:30 2006 +0200
configure: Filter out garbage from arts-config --libs too.
configure | 9 ++++++++- configure.ac | 9 ++++++++- 2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/configure b/configure index 9bffafd..c825171 100755 --- a/configure +++ b/configure @@ -10855,7 +10855,14 @@ then -I*) ARTSC_CFLAGS="$ARTSC_CFLAGS $i";; esac done
- ARTSC_LIBS=`$ARTSCCONFIG --libs`
- ARTSC_LIBS=""
- for i in `$ARTSCCONFIG --libs`
- do
case "$i" in-L/usr/lib|-L/usr/lib64) ;;-L*|-l*) ARTSC_LIBS="$ARTSC_LIBS $i";;esac- done
It also adds -L/opt/kde/lib64 for me, so this will likely not fully work.
I would say we just do not configure arts and esd on 64->32 compiles. :/
Ciao, Marcus
Marcus Meissner meissner@suse.de writes:
It also adds -L/opt/kde/lib64 for me, so this will likely not fully work.
I would say we just do not configure arts and esd on 64->32 compiles. :/
Hmmm... does it fail to link if you simply remove the -L/opt/kde/lib64? And if it fails, does configure detect the failure properly?
On Tue, Apr 04, 2006 at 01:12:26PM +0200, Alexandre Julliard wrote:
Marcus Meissner meissner@suse.de writes:
It also adds -L/opt/kde/lib64 for me, so this will likely not fully work.
I would say we just do not configure arts and esd on 64->32 compiles. :/
Hmmm... does it fail to link if you simply remove the -L/opt/kde/lib64? And if it fails, does configure detect the failure properly?
Currently: configure:10975: gcc -m32 -o conftest -D_FORTIFY_SOURCE=2 -O2 -Wall -I/opt/kde3/include/artsc -I/opt/gnome/include/glib-2.0 -I/opt/gnome/l ib64/glib-2.0/include conftest.c -lartsc -L/opt/kde3/lib64 -ldl -lartsc -lpthread -L/opt/gnome/lib64 -lgmodule-2.0 -ldl -lgthread-2.0 -l glib-2.0 >&5 /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /opt/kde3/lib64/libartsc.so when searchi ng for -lartsc /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: cannot find -lartsc
If I remove it, it does not find /opt/kde3/lib/libartsc.so because it is not in the search path. So we just do not detect it now, and do not detect it after removing it.
Ciao, Marcus
Marcus Meissner meissner@suse.de writes:
Currently: configure:10975: gcc -m32 -o conftest -D_FORTIFY_SOURCE=2 -O2 -Wall -I/opt/kde3/include/artsc -I/opt/gnome/include/glib-2.0 -I/opt/gnome/l ib64/glib-2.0/include conftest.c -lartsc -L/opt/kde3/lib64 -ldl -lartsc -lpthread -L/opt/gnome/lib64 -lgmodule-2.0 -ldl -lgthread-2.0 -l glib-2.0 >&5 /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /opt/kde3/lib64/libartsc.so when searchi ng for -lartsc /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: cannot find -lartsc
If I remove it, it does not find /opt/kde3/lib/libartsc.so because it is not in the search path. So we just do not detect it now, and do not detect it after removing it.
That sounds reasonable. I don't think we want to try to guess the paths (or if we do, then we should get rid of the config script completely, that's a broken concept anyway).
On Wed, Apr 05, 2006 at 11:45:09AM +0200, Alexandre Julliard wrote:
Marcus Meissner meissner@suse.de writes:
Currently: configure:10975: gcc -m32 -o conftest -D_FORTIFY_SOURCE=2 -O2 -Wall -I/opt/kde3/include/artsc -I/opt/gnome/include/glib-2.0 -I/opt/gnome/l ib64/glib-2.0/include conftest.c -lartsc -L/opt/kde3/lib64 -ldl -lartsc -lpthread -L/opt/gnome/lib64 -lgmodule-2.0 -ldl -lgthread-2.0 -l glib-2.0 >&5 /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /opt/kde3/lib64/libartsc.so when searchi ng for -lartsc /usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: cannot find -lartsc
If I remove it, it does not find /opt/kde3/lib/libartsc.so because it is not in the search path. So we just do not detect it now, and do not detect it after removing it.
That sounds reasonable. I don't think we want to try to guess the paths (or if we do, then we should get rid of the config script completely, that's a broken concept anyway).
I agree here.
Ciao, Marcus
-
Alexandre Julliard -
Marcus Meissner