Free Web survey - get your questions answered

[Web-Survey-Free]

Link your page to a free web survey.

Easy administration to create and modify your questions.

Just give us a try http://osp.net/survey  


* This site allows you to create and modify a web survey very easily 

* Excellent graphical output of survey responses

* Export your survey information easly to an excel spreadsheet

* Do not pay web developers hundreds of dollars to develop and maintain a web survey

* No loading special software or learning complicated survey authoring tools 

* Modify your web survey information whenever you want and as much as you want

* Great business and educational tool


Register Now At! Websurvey - http://osp.net/survey  




  To remove your email from our list visit http://emailer.4it.bz/SurveyDefault.htm 



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Elizabeth Barham]

Bob Friesenhahn <[EMAIL PROTECTED]> writes:

> g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o  
>.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o 
>.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o 
>.libs/Montage.o .libs/Options.o .libs/Pixels.o .libs/STL.o .libs/Thread.o 
>.libs/TypeMetric.o  -L/usr/local/lib ../../magick/.libs/libMagick-5.dll 
>-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib 
>-L/mingw/lib/gcc-lib/mingw32/2.95.3-6 
>-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
>-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
>-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. 
>-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../.. -lstdc++ -luser32 -lkernel32 
>-ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt   -o .libs/libMagick++-5.dll

What about removing the first object file, the:

c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o

part?

The reason is that the multiple definitions were coming from within
that particular object file - what happens without it?

Elizabeth


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Bob Friesenhahn]

By the way, notice that this is a C++ DLL which is being linked
against a C DLL also built by libtool.  The C DLL did successfully
link using libtool.  The C DLL is based in part on a libtool
"convenience library".

To be honest, I believe that there are still some run-time issues with
C++ DLLs under MinGW, but it should still be possible to create the
DLL.

Bob

On 9 Oct 2002, Elizabeth Barham wrote:

> Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> > Ideas?
> >
> > g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o  
>.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o 
>.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o 
>.libs/Montage.o .libs/Options.o .libs/Pixels.o .libs/STL.o .libs/Thread.o 
>.libs/TypeMetric.o  -L/usr/local/lib ../../magick/.libs/libMagick-5.dll 
>-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib 
>-L/mingw/lib/gcc-lib/mingw32/2.95.3-6 
>-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
>-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
>-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. 
>-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../.. -lstdc++ -luser32 -lkernel32 
>-ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt   -o .libs/libMagick++-5.dll
>
> What happens if you run the above line by itself without the -shared
> switch?
>
> Elizabeth
>

==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Bob Friesenhahn]

The exact same error message is reported without -shared.

Bob

On 9 Oct 2002, Elizabeth Barham wrote:

> Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> > Ideas?
> >
> > g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o  
>.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o 
>.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o 
>.libs/Montage.o .libs/Options.o .libs/Pixels.o .libs/STL.o .libs/Thread.o 
>.libs/TypeMetric.o  -L/usr/local/lib ../../magick/.libs/libMagick-5.dll 
>-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib 
>-L/mingw/lib/gcc-lib/mingw32/2.95.3-6 
>-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
>-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
>-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. 
>-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../.. -lstdc++ -luser32 -lkernel32 
>-ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt   -o .libs/libMagick++-5.dll
>
> What happens if you run the above line by itself without the -shared
> switch?
>
> Elizabeth
>

==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: MinGW libtool DLL failure

[Elizabeth Barham]

Bob Friesenhahn <[EMAIL PROTECTED]> writes:

> Ideas?
> 
> g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o  
>.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o 
>.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o 
>.libs/Montage.o .libs/Options.o .libs/Pixels.o .libs/STL.o .libs/Thread.o 
>.libs/TypeMetric.o  -L/usr/local/lib ../../magick/.libs/libMagick-5.dll 
>-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib 
>-L/mingw/lib/gcc-lib/mingw32/2.95.3-6 
>-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
>-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
>-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. 
>-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../.. -lstdc++ -luser32 -lkernel32 
>-ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt   -o .libs/libMagick++-5.dll

What happens if you run the above line by itself without the -shared
switch?

Elizabeth


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

MinGW libtool DLL failure

[Bob Friesenhahn]

Earnie,

Using libtool from the head of libtool CVS, and test building
ImageMagick under MinGW (MSYS environment), I get multiple-defined
errors when linking the DLL as shown below.

Ideas?

g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o  
.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o 
.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o 
.libs/Montage.o .libs/Options.o .libs/Pixels.o .libs/STL.o .libs/Thread.o 
.libs/TypeMetric.o  -L/usr/local/lib ../../magick/.libs/libMagick-5.dll 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib 
-Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. 
-L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../.. -lstdc++ -luser32 -lkernel32 -ladvapi32 
-lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt   -o .libs/libMagick++-5.dll
c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o: In function 
`DllMainCRTStartup':
//c/cygmnt/samo/mingw/msys/dllcrt1.c(.text+0x0): multiple definition of 
`DllMainCRTStartup@12'
c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o(.text+0x0)://c/cygmnt/samo/mingw/msys/dllcrt1.c:
 first defined here
c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o: In function `atexit':
//c/cygmnt/samo/mingw/msys/dllcrt1.c(.text+0xe8): multiple definition of `atexit'
c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o(.text+0xe8)://c/cygmnt/samo/mingw/msys/dllcrt1.c:
 first defined here
c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o: In function `onexit':
//c/cygmnt/samo/mingw/msys/dllcrt1.c(.text+0x114): multiple definition of `_onexit'
c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o(.text+0x114)://c/cygmnt/samo/mingw/msys/dllcrt1.c:
 first defined here
make[3]: *** [libMagick++.la] Error 1

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen




___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool 1.4.2 on Darwin

[Benjamin Reed]

On Wed, 2002-10-09 at 19:10, Robert Boehne wrote:
> If we added support for library namespace, all of the
> Darwin developers would start developing software with
> Libtool that used it, and therefore wouldn't link on
> other systems, correct?  I'm not claiming I have ever
> seen a Mac running X+ so you'll have to correct me if I'm wrong.
>   Libtool's philosophy is mostly to provide the common
> subset of linker/loader/compiler features, and to specifically
> NOT support features that aren't available elsewhere.  Now,
> this isn't always the case, but if you wanted to add support
> for library namespaces for other platforms *IN_Libtool*
> then it would be reasonable, but more work.  I doubt that
> is possible anyway.

Right,  that's why there's a problem...  libtool is already making the
decision for developers on Darwin (to a flat namespace), but that's not
always the best course of action; if possible it would be better to link
with a twolevel namespace to not have symbol collisions in the future.

The current behaviour is like libtool forcing -O0 on gcc because it's
less likely to cause compilation errors.  The flat namespace bit was
added to libtool assumedly because early in Darwin's history with
libtool it fixed some packages' building, but it's not necessarily
optimal.

Unfortunately I don't know the full consequences of changing it, which
is why it would be nice to choose on the libtool command-line, and leave
it up to developers.  It could be a no-op on platforms that don't
support multi-level namespaces (ie, every platform but Darwin), but let
the developer choose if he is of a mind to.

I don't have a problem with trying to hack this in, I expect it's not
terribly difficult, but I don't think I could get a patch for you before
any kind of release freeze, and I don't know in what manner (or if) it
would play well with the way libtool implements these things.  =)




___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.5 && 1.4.3

[David I. Lehn]

* Michel LESPINASSE <[EMAIL PROTECTED]> [20021009 19:57]:
> On Wed, Oct 09, 2002 at 06:27:18PM -0500, Robert Boehne wrote:
> > Ok, let me see if I understand this one,
> > under Linux hppa, (presumably with gcc) user has added -prefer-non-pic
> > to the CFLAGS explicitly, and configured with --enable-shared ??
...
> > What platforms (aside from Alpha & RS/6000) does this work on?
> 
> That package (using -prefer-non-pic unconditionally) is into debian
> now, it's been compiled successfully on all debian-supported arches
> except hppa, so that would be x86, m68k, sparc, alpha, powerpc, arm,
> mips/mipsel, ia64 and s390. I'm not sure exactly which of these use
> -fPIC or not. Only hppa breaks, as it tries to not use -fPIC where the
> architecture apparently requires -fPIC.
> 

I actually just got lazy and hacked it to not use -prefer-non-pic if the
host was hppa*.  walken's check is a better approach that I'll integrate
into the next deb release.  A libtool fix would be even better. ;)  It's
compiled for all archs now.  This is just -compiling- though.  I have no
idea if PIC tricks work at runtime on all archs in all situations.  But
I presume that's why the flag exists in the first place.

In case anyone wants to check which archs actually used -fPIC you can
check the build logs: http://buildd.debian.org/build.php?pkg=mpeg2dec

-dave


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.5 && 1.4.3

[Michel LESPINASSE]

On Wed, Oct 09, 2002 at 06:27:18PM -0500, Robert Boehne wrote:
> Ok, let me see if I understand this one,
> under Linux hppa, (presumably with gcc) user has added -prefer-non-pic
> to the CFLAGS explicitly, and configured with --enable-shared ??

The package adds -prefer-non-pic to the CFLAGS unconditionally (does
not depend on the target arch) and relies on libtool to determine if
it should pass -fPIC or not. As far as I know this works OK on all
arches except hppa. The configure workaround I posted compiles a dummy
library with -prefer-non-pic and checks if it fails.

The way its done in the package is that the configure.in was doing
LIBMPEG2_CFLAGS="$LIBMPEG2_CFLAGS -prefer-non-pic"
I replaced it with
AC_LIBTOOL_NON_PIC([LIBMPEG2_CFLAGS="$LIBMPEG2_CFLAGS -prefer-non-pic"])
with AC_LIBTOOL_NON_PIC as quoted in the previous email.

> What platforms (aside from Alpha & RS/6000) does this work on?

That package (using -prefer-non-pic unconditionally) is into debian
now, it's been compiled successfully on all debian-supported arches
except hppa, so that would be x86, m68k, sparc, alpha, powerpc, arm,
mips/mipsel, ia64 and s390. I'm not sure exactly which of these use
-fPIC or not. Only hppa breaks, as it tries to not use -fPIC where the
architecture apparently requires -fPIC.

Hope this helps,

-- 
Michel "Walken" LESPINASSE
Is this the best that god can do ? Then I'm not impressed.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.5 && 1.4.3

[Robert Boehne]

Ok, let me see if I understand this one,
under Linux hppa, (presumably with gcc) user has added -prefer-non-pic
to the CFLAGS explicitly, and configured with --enable-shared ??

What platforms (aside from Alpha & RS/6000) does this work on?

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT ricardo-us DOT com


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool 1.4.2 on Darwin

[Robert Boehne]

Benjamin,

If we added support for library namespace, all of the
Darwin developers would start developing software with
Libtool that used it, and therefore wouldn't link on
other systems, correct?  I'm not claiming I have ever
seen a Mac running X+ so you'll have to correct me if I'm wrong.
  Libtool's philosophy is mostly to provide the common
subset of linker/loader/compiler features, and to specifically
NOT support features that aren't available elsewhere.  Now,
this isn't always the case, but if you wanted to add support
for library namespaces for other platforms *IN_Libtool*
then it would be reasonable, but more work.  I doubt that
is possible anyway.

HTH,

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT ricardo-us DOT com


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.5 && 1.4.3

[Michel LESPINASSE]

On Wed, Oct 09, 2002 at 02:57:39PM -0500, Robert Boehne wrote:
> I intend to spin a release 1.4.3 this weekend from the branch-1-4
> sources.

There is a bug in libtool 1.4.2 when using -prefer-non-pic on hppa:
libtool does not pass the -fPIC flag, and then the linker complains
about that. Alexandre Oliva confirmed to me that this counts as a bug,
as -prefer-non-pic should be ignored (i.e. we should still pass the
-fPIC flag) if the target architecture requires -fPIC.

For an example of a build failing because of that bug, see
http://buildd.debian.org/fetch.php?&pkg=mpeg2dec&ver=0.2.1-2&arch=hppa&stamp=1031760849&file=log&as=raw

Alexandre's proposed fix was to try removing the 'hppa* | ' from the
line just before 'lt_cv_deplibs_check_method=pass_all ;;' ; I have not
been able to test this yet as I dont have easy access to an hppa system.

It is possible to work around this by making the configure script test
for libtool bugs like in the example below, however I guess you'll all
agree this is really ugly:

dnl AC_LIBTOOL_NON_PIC ([ACTION-IF-WORKS], [ACTION-IF-FAILS])
dnl check for nonbuggy libtool -prefer-non-pic
AC_DEFUN([AC_LIBTOOL_NON_PIC],
[AC_MSG_CHECKING([if libtool supports -prefer-non-pic flag])
mkdir ac_test_libtool; cd ac_test_libtool; ac_cv_libtool_non_pic=no
echo "int g (int i); int f (int i) {return g(i);}" >f.c
echo "int g (int i) {return i;}" >g.c
../libtool --mode=compile $CC $CFLAGS -prefer-non-pic \
-c f.c >/dev/null 2>&1 && \
../libtool --mode=compile $CC $CFLAGS -prefer-non-pic \
-c g.c >/dev/null 2>&1 && \
../libtool --mode=link $CC $CFLAGS -prefer-non-pic -o libfoo.la \
f.lo g.lo >/dev/null 2>&1 && \
ac_cv_libtool_non_pic=yes
cd ..; rm -fr ac_test_libtool; AC_MSG_RESULT([$ac_cv_libtool_non_pic])
if test x"$ac_cv_libtool_non_pic" = x"yes"; then
ifelse([$1],[],[:],[$1])
else
ifelse([$2],[],[:],[$2])
fi])

Hope this helps,

-- 
Michel "Walken" LESPINASSE
Is this the best that god can do ? Then I'm not impressed.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool 1.4.2 on Darwin

[Benjamin Reed]

On Wed, 2002-10-09 at 16:15, Robert Boehne wrote:
> Christoph,
> 
> The patch against libtool.m4 is different from what is in
> CVS branch-1-4.  Does today's branch-1-4 have the problem
> your patch intends to fix?  It appears that this may
> be fixed in CVS.
>   If you would, please get Libtool cvs branch-1-4, if you
> don't have access to it for some reason, send me an email
> (directly) and I'll mail you a tarball.

OK, here's essentially the same patch but against the 1.4 tree.

Another thing I was wondering, while I'm at it.  Darwin has a strange
behavior in that there are two different ways that symbols can be
created for the dynamic loader, either "flat" namespace, or "twolevel"
namespace.  It has something to do with the prebinding support that's
built into the library dynamic loader for darwin and symbol clashes
between libraries.

(for more on what this means, see:)
http://developer.apple.com/techpubs/macosx/ReleaseNotes/TwoLevelNamespaces.html

Currently libtool forces it to the flat namespace, which will fix
compilation with some older software that wasn't written with prebinding
in mind, but it's really non-optimal.  Is there any way we could add
support for some type of command-line option to choose the twolevel
namespace?  There is currently no way to choose at build time other than
to hack libtool, which is very non-optimal (and also means that the
Darwin KDE tree could never be fully integrated into KDE mainline, since
they will only accept libtool changes that have been accepted into
libtool CVS or a release).

I'm not sure if you have any way (or more importantly, if it
breaks/bends libtools goals) of adding platform-specific flags or some
other way to implementing choosing the namespace behaviour at link time,
but that would be incredibly helpful.  Forcing everything to a flat
namespace is really a workaround for libraries that are doing dodgy
things with public symbols, from what I understand.


Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.166.2.43
diff -u -b -r1.166.2.43 libtool.m4
--- libtool.m4  10 Sep 2002 13:50:54 -  1.166.2.43
+++ libtool.m4  9 Oct 2002 20:45:11 -
@@ -1583,7 +1583,7 @@
 #cross-compilation, but unfortunately the echo tests do not
 #yet detect zsh echo's removal of \ escapes.  Also zsh mangles
 #   `"' quotes if we put them in here... so don't!
-archive_cmds='$nonopt $(test .$module = .yes && echo -bundle || echo -dynamiclib) 
$allow_undefined_flag -o $lib $libobjs $deplibs$linker_flags -install_name 
$rpath/$soname $verstring'
+archive_cmds='$CC -r -keep_private_externs -nostdlib -o ${lib}-master.o $libobjs 
+&& $CC $(test .$module = .yes && echo -bundle || echo -dynamiclib) 
+$allow_undefined_flag -o $lib ${lib}-master.o $deplibs$linker_flags $(test .$module 
+!= .yes && echo -install_name $rpath/$soname $verstring)'
 # We need to add '_' to the symbols in $export_symbols first
 #archive_expsym_cmds="$archive_cmds"' && strip -s $export_symbols'
 hardcode_direct=yes
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/ltmain.in,v
retrieving revision 1.259.2.24
diff -u -b -r1.259.2.24 ltmain.in
--- ltmain.in   9 Sep 2002 18:27:14 -   1.259.2.24
+++ ltmain.in   9 Oct 2002 20:45:12 -
@@ -3175,6 +3175,14 @@
;;
   esac
 
+  case $host in
+  *darwin*)
+# Don't allow lazy linking, it breaks C++ global constructors
+compile_command="$compile_command ${wl}-bind_at_load"
+finalize_command="$finalize_command ${wl}-bind_at_load"
+;;
+  esac
+
   compile_command="$compile_command $compile_deplibs"
   finalize_command="$finalize_command $finalize_deplibs"
 

Re: libtool 1.4.2 on Darwin

[Robert Boehne]

Christoph,

The patch against libtool.m4 is different from what is in
CVS branch-1-4.  Does today's branch-1-4 have the problem
your patch intends to fix?  It appears that this may
be fixed in CVS.
  If you would, please get Libtool cvs branch-1-4, if you
don't have access to it for some reason, send me an email
(directly) and I'll mail you a tarball.

Thanks,

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT ricardo-us DOT com


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.5 && 1.4.3

[Ossama Othman]

Hi Robert,

On Wed, Oct 09, 2002 at 02:57:39PM -0500, Robert Boehne wrote:
> I intend to spin a release 1.4.3 this weekend from the
> branch-1-4 sources.  Any properly formatted patches will
> be considered for inclusion before the release.  I have
> seen a tendency to post patches on any list in any
> format, which makes it more work to get that particular
> patch installed in CVS.  As of late, Gary and I have
> precious little of that!

Perhaps it might be useful to refresh everyone's memory about the
Libtool contribution guidelines available on the Libtool web site
here:

http://www.gnu.org/software/libtool/contribute.html

-Ossama
-- 
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068  70E6 5EB7 5E71 F7A3 94A8


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.5 && 1.4.3

[Robert Boehne]

All,

I intend to spin a release 1.4.3 this weekend from the
branch-1-4 sources.  Any properly formatted patches will
be considered for inclusion before the release.  I have
seen a tendency to post patches on any list in any
format, which makes it more work to get that particular
patch installed in CVS.  As of late, Gary and I have
precious little of that!

I may get a chance to review some patches before the
weekend (with a little luck) but likely I'll have
to go it alone on Saturday.

After 1.4.3 is released, branch-1-4 will no longer
be maintained.  A release of 1.5 should follow shortly.

Ok?

Robert

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne AT ricardo-us DOT com


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool 1.4.2 on Darwin

[Christoph Egger]

> > Yes, you already said that. The stuff above is about the libtool 1.4
> > _branch_, while the libtool-darwin patch is in the mainstream
> development tree.
> 
> Right, and I have not yet seen anything that said there will be a
> libtool 1.4.3 release, only that there will be a libtool release in
> general, so I posted the patch against the tree that it sounds like most
> development is going on in.  It should be very easy to backport.

Right. The ltmain.in patch works without modifications, the libtool.m4 patch
had to be modified. I am using it now.
I've attached a diff against native libtool 1.4.2. I hope, someone puts it
into CVS.
 
> > BTW: When will the first libtool version be released containing the
> > libtool-darwin patch officially?
> 
> Got me, this is the first time I've ever even written anything to the
> libtool list I think, I'm just a lurker.  =)
> 
> I don't even know if anyone with commit access has looked at the patch,
> for that matter.

Would be nice, if someone were doing it.

-- 
CU,

Christoph Egger
E-Mail: [EMAIL PROTECTED]

+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!


libtool-darwin.diff
Description: Binary data

Re: Libtool 1.4.3

[Paul Eggert]

> From: Sascha Schumann <[EMAIL PROTECTED]>
> Date: Wed, 9 Oct 2002 19:49:57 +0200 (CEST)
> 
> > Did you send a bug report?  Do you have a test case?
> 
> I'm sorry, it was noticed by so many people, I supposed it
> would make its way to you.

It's the first I've heard of it.  Do you have a URL describing the
problem?


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.5

[Albert Chin]

On Wed, Oct 09, 2002 at 12:29:44PM -0500, Bob Friesenhahn wrote:
> On Wed, 9 Oct 2002, Guido Draheim wrote:
> 
> > > In my experience, the 1.5 code-base is a solid product on systems
> > > supported by 1.4.2, and provided that it is patched and proven to work
> > > under MinGW and Darwin then 1.5 should be ready to release.
> > >
> >
> > That's another argument. And since it was missed to push 1.4.3 out
> > to the world when it was due, we can as well dump the work that
> > I and others have done on the libtool-1-4 branch and well move
> > ahead. Anyway, it would be nice if you'd find some nice words for
> > those who were not on your branch of the developments, for which
> > I understand you are proud of what you've achieved and that you
> > want to have it out and recognized.
> 
> I do not mean to slight the supporters of a 1.4.3 release at all.  I
> believe that supporters of a 1.4.3 release have only the best
> intentions and that many libtool users (but not libtool itself) would
> benefit from a 1.4.3 release.
> 
> To clarify things, until very recently I have served only the role of
> a libtool user, not a libtool developer.  While I have used the
> libtool code which would become 1.5 through its entire development, I
> have contributed little to it.
> 
> The gestation period for 1.5 spans well over two years because for
> quite a long time it lived in the multi-language-branch.  Developers
> like Ossama Othman, Robert Boehne, and Gary Vaughan deserve credit for
> this work.

I won't debate the value of 1.5. Are developers moving to autoconf
2.5x in droves? I think the developers interested in moving to 2.5x
will be interested in a 1.5 release as it will force them to move to
2.5x. However, for those that don't, I support the 1.4.3 interim
release for those wishing to remain at 2.13 for whatever reason.

If someone is willing to spin the release, I'd like to see us move
ahead with a 1.4.3.

-- 
albert chin ([EMAIL PROTECTED])


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Sascha Schumann]

> You want autoconf -f then.

-f, --force  consider all files obsolete

We do a ./cvsclean right now for autoconf +2.50 which purges
all generated data.  I guess that is basically the same.

> You know, you are typically the kind of people who has valid grieves
> against Autoconf, but using things that were never documented.

You have lost me.  Why should autoconf document any valid m4
command?

> esyscmd is definitely excluded from our framework.

Then you need to document that.  Neither 2.13's nor 2.54's
autoconf.info says anything to that effect.

> But you kept developping your Autoconf instead of coming and
> deciding for a solution.

I cannot parse that sentence.

> How do I know?  Did you send a bug report?  Do you have a test case?

I'm sorry, it was noticed by so many people, I supposed it
would make its way to you.

> And BTW, do PHP's extensions finally produce valid HTML code?

PHP's output, where applicable, conforms to XHTML-1.0-STRICT
as defined by the W3C.

- Sascha



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.5

[Bob Friesenhahn]

On Wed, 9 Oct 2002, Guido Draheim wrote:

> > In my experience, the 1.5 code-base is a solid product on systems
> > supported by 1.4.2, and provided that it is patched and proven to work
> > under MinGW and Darwin then 1.5 should be ready to release.
> >
>
> That's another argument. And since it was missed to push 1.4.3 out
> to the world when it was due, we can as well dump the work that
> I and others have done on the libtool-1-4 branch and well move
> ahead. Anyway, it would be nice if you'd find some nice words for
> those who were not on your branch of the developments, for which
> I understand you are proud of what you've achieved and that you
> want to have it out and recognized.

I do not mean to slight the supporters of a 1.4.3 release at all.  I
believe that supporters of a 1.4.3 release have only the best
intentions and that many libtool users (but not libtool itself) would
benefit from a 1.4.3 release.

To clarify things, until very recently I have served only the role of
a libtool user, not a libtool developer.  While I have used the
libtool code which would become 1.5 through its entire development, I
have contributed little to it.

The gestation period for 1.5 spans well over two years because for
quite a long time it lived in the multi-language-branch.  Developers
like Ossama Othman, Robert Boehne, and Gary Vaughan deserve credit for
this work.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.5

[Guido Draheim]

Bob Friesenhahn wrote:
> Time spent on libtool 1.4.3 is time spent doing work which must
> either be done a second time, or has already been done, for libtool
> 1.5.

Not true. There were some patches backported even before now,
I was doing some of the work under the expectation that we can
see a libtool update somewhen.

> 
> If a libtool 1.4.3 is prepared, then the next request will be for a
> libtool 1.4.4, regardless of whether a libtool 1.5 is released.
> Releasing a libtool 1.4.3 will encourage the same sort of behavior
> which has caused so much trouble for Autoconf.  It is better to let
> the 1.4 line die of its own accord than to prop it up and encourage
> developers not to use 1.5.

Shortsighted. Actually, the 1.4.3 should have been pushed out in
august, so it would now be part of mandrake 9.0, redhat 8.0 and
suse 8.1. It would have been a bugfix release only and the distro
makers would be easy to pick that up even late in the making.
Such is different with a source tree that one can not easily
diff to see visually if it is safe to bring it in late.

> 
> In my experience, the 1.5 code-base is a solid product on systems
> supported by 1.4.2, and provided that it is patched and proven to work
> under MinGW and Darwin then 1.5 should be ready to release.
> 

That's another argument. And since it was missed to push 1.4.3 out
to the world when it was due, we can as well dump the work that
I and others have done on the libtool-1-4 branch and well move
ahead. Anyway, it would be nice if you'd find some nice words for
those who were not on your branch of the developments, for which
I understand you are proud of what you've achieved and that you
want to have it out and recognized.



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool 1.4.2 on Darwin

[Benjamin Reed]

> Yes, you already said that. The stuff above is about the libtool 1.4
> _branch_, while the libtool-darwin patch is in the mainstream development tree.

Right, and I have not yet seen anything that said there will be a
libtool 1.4.3 release, only that there will be a libtool release in
general, so I posted the patch against the tree that it sounds like most
development is going on in.  It should be very easy to backport.

> BTW: When will the first libtool version be released containing the
> libtool-darwin patch officially?

Got me, this is the first time I've ever even written anything to the
libtool list I think, I'm just a lurker.  =)

I don't even know if anyone with commit access has looked at the patch,
for that matter.



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Russ Allbery]

Akim Demaille <[EMAIL PROTECTED]> writes:

> If people consider we deliberatedly broken bugward compatibility, then
> fine, you're free to be wrong.  It's not what happened (and I can tell
> you that a lot of code would not have been written if that was our
> intention), but I don't care what people think wrt this now, because...

For what it's worth, I don't think you deliberately broke it, and I'm not
arguing intentions at all.  I'm just trying to relate how it looks from
entirely outside the project, when the only information one has to go on
is how Autoconf 2.13 works and how Autoconf 2.54 works.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Libtool 1.5

[Bob Friesenhahn]

After seeing what has happened with Autoconf, and given the current
state of libtool, I recommend that the focus of libtool development be
to produce a libtool 1.5 as soon as possible and not spend time
producing a libtool 1.4.3.

Time spent on libtool 1.4.3 is time spent doing work which must
either be done a second time, or has already been done, for libtool
1.5.

If a libtool 1.4.3 is prepared, then the next request will be for a
libtool 1.4.4, regardless of whether a libtool 1.5 is released.
Releasing a libtool 1.4.3 will encourage the same sort of behavior
which has caused so much trouble for Autoconf.  It is better to let
the 1.4 line die of its own accord than to prop it up and encourage
developers not to use 1.5.

In my experience, the 1.5 code-base is a solid product on systems
supported by 1.4.2, and provided that it is patched and proven to work
under MinGW and Darwin then 1.5 should be ready to release.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen




___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Bonzini]

> The community are the maintainers, therefore a maintainer has spoken for
> a minor version increment, rather than a patch release increment.

Do you mean a minor version increment starting from branch-1_4 or from HEAD?

Paolo




___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool 1.4.2 on Darwin

[Christoph Egger]

> 
> On Wednesday, October 9, 2002, at 01:20 AM, Christoph Egger wrote:
> 
> >> so diff would be just in the last part around `-install_name
> >> $parth/$soname`
> >>
> >
> > Good to know. Is there an anonymous CVS access? If yes, where and how?
> > Then I could give you a diff against this branch, if merging makes you
> > trouble.
> 
> The patch I posted yesterday for darwin contains the -install_name 
> fixes already if you want to use that...

Yes, you already said that. The stuff above is about the libtool 1.4
_branch_, while the libtool-darwin patch is in the mainstream development tree.
BTW: When will the first libtool version be released containing the
libtool-darwin patch officially?

-- 
CU,

Christoph Egger
E-Mail: [EMAIL PROTECTED]

+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Akim Demaille]

| > Sascha> and contains a dependency-ignorant cache system.
| >
| > What do you mean?
| 
| Each of PHP's bundled extensions has a config.m4 which can be
| maintained separately.  Autoconf 2.50 and later insert stale
| code into configure, when such a config.m4 file changes.

You want autoconf -f then.

| These files are sourced using
| 
| esyscmd(./scripts/config-stubs ext)
| 
| The shell script prints out an sinclude() line for each
| existing config.m4 in a particular sub-directory (e.g.
| ext/mysql, ext/session).  Apparently, autoconf/autom4te does
| not keep track of the time stamp of each sourced file which
| then causes the described issue.

You know, you are typically the kind of people who has valid grieves
against Autoconf, but using things that were never documented.
esyscmd is definitely excluded from our framework.  But you kept
developping your Autoconf instead of coming and deciding for a
solution.


| Oh, btw, has autoconf 2.5x stopped to generate empty "case..esac"
| constructs?  FreeBSD's /bin/sh bombed out on that, and it
| violated POSIX.

How do I know?  Did you send a bug report?  Do you have a test case?

And BTW, do PHP's extensions finally produce valid HTML code?


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Satellite TV hex files for Funcards, Goldcards

[Jay]

 
Hello there 
 
Did you know that you can program smart 
cards with files from the internet and open lots of pay per view chanells
for 
your televisual pleasure.  
   
 
Take a look at http://MagicFun.da.ru for the latest hex 
files.  
   
 
Many thanks Jay.  

Re: Libtool 1.4.3

[Sascha Schumann]

[Cc trimmed]

> That's because it does provide a better service too :(  I have timed a
> lot of the code, and I can tell that we're hitting a M4 limitation
> here.  Hopefully future version of GNU M4 will help.

In the mean time, we are happy to pursue our use of
autoconf 2.13.

> Sascha> and contains a dependency-ignorant cache system.
>
> What do you mean?

Each of PHP's bundled extensions has a config.m4 which can be
maintained separately.  Autoconf 2.50 and later insert stale
code into configure, when such a config.m4 file changes.

These files are sourced using

esyscmd(./scripts/config-stubs ext)

The shell script prints out an sinclude() line for each
existing config.m4 in a particular sub-directory (e.g.
ext/mysql, ext/session).  Apparently, autoconf/autom4te does
not keep track of the time stamp of each sourced file which
then causes the described issue.

Oh, btw, has autoconf 2.5x stopped to generate empty "case..esac"
constructs?  FreeBSD's /bin/sh bombed out on that, and it
violated POSIX.

- Sascha



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Earnie Boyd]

Paolo Bonzini wrote:
 >>Wouldn't it be better to get libtool 1.5 out the door?  The resources
 >>required to achieve a releasable product are similar and CVS libtool
 >>already contains most of the fixes that would go into a 1.4.3.
 >
 >
 > But it also contains more features.  Releasing 1.5 should be done by
 > the maintainers, not by a "community" process; instead I think that
 > such a process is perfectly valid to review patches and ChangeLogs and
 > put them together.
 >

The community are the maintainers, therefore a maintainer has spoken for
a minor version increment, rather than a patch release increment.
Enough has changed to increment the minor version number.

 > Yes, libtool would-be-1.5 has been used by gcc at least since 3.0, so it
 > should be pretty good, but I think that it is easier (in terms of
 > brainwork, not of needed resources) to do a "definitive" 1.4.x release.
 >

Since I'm one of the community, I suggest the release to be 1.5 and that
Akim's suggestion for AC_PREREQ a strong point.  Perhaps, both a 1.4.3
and a 1.5 where 1.4.3 does a AC_PREREQ 2.13.

Earnie.



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Thomas E. Dickey]

On 9 Oct 2002, Akim Demaille wrote:

> Whatever your opinion is, this debate is anyway a total loss of time
> for all of us (except for having the opportunity of reading the few
> usual good laughs from TEDdy Bear, the great clown of our mailing
> lists) since Autoconf will not be more 2.13 compatible in the future.

I don't expect it to be - if you didn't keep adding spurious (random walk)
design changes, you would soon run out of things to claim that older
versions (even of autoconf 2.5x) are defective.

it's a poor workman who blames the tool.

-- 
T.E.Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Akim Demaille]

> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:

Robert> Ok, So a 1.4.3 version is desired, that's established.  The
Robert> million-dollar question is: Does current branch-1-4 Libtool do
Robert> the trick?

Robert> If so, then a roll out could be done within the week.

I would like to find a tarball somewhere (I'm bing cut from CVS
currently), and read the M4 code.  I'll subscribe to libtool-patches too.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Akim Demaille]

> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:

Great thread people!  I'm happy to see you're alive :)


Russ> There were a variety of reasons for breaking backward
Russ> compatibility, like choosing to clean up quoting, but that's a
Russ> justification for doing it, not an argument that it didn't
Russ> happen.  It very clearly did happen.  Calling the autoconf
Russ> scripts that worked in autoconf 2.13 but not in 2.5x "broken" is
Russ> a deflection that I'd be more sympathetic to if the ways in
Russ> which they were "broken" were clearly documented in autoconf
Russ> 2.13, but they weren't.  Which means that the language
Russ> definition was changed (to something much more precise, mind),
Russ> not that scripts that followed the previous language definition
Russ> such as it was were broken.

I don't want to dive into this debate, and I think that Russ' summary
is very satisfying in that it exposes the point of view of all the
parties.

Whatever your opinion is, this debate is anyway a total loss of time
for all of us (except for having the opportunity of reading the few
usual good laughs from TEDdy Bear, the great clown of our mailing
lists) since Autoconf will not be more 2.13 compatible in the future.

If people consider we deliberatedly broken bugward compatibility, then
fine, you're free to be wrong.  It's not what happened (and I can tell
you that a lot of code would not have been written if that was our
intention), but I don't care what people think wrt this now,
because...

Because today the only reasonable attitude is asking ourselves how can
we help people making the move.  I worked *immensely* on autoupdate,
it took me days to write such a complex tool.  I wrote documentation
explaining proper Autoconf programming.  I added sections to ease the
transition.  I made public calls for people looking for help.  I'm
ready to do more, but please, tell me what is needed.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Akim Demaille]

> "Sascha" == Sascha Schumann <[EMAIL PROTECTED]> writes:

Sascha> We use it for the PHP project (>80k lines configure script),
Sascha> because 2.5x is 5 to 6 times slower 

That's because it does provide a better service too :(  I have timed a
lot of the code, and I can tell that we're hitting a M4 limitation
here.  Hopefully future version of GNU M4 will help.

Sascha> and contains a dependency-ignorant cache system.

Err.  It doesn't compute.

What do you mean?



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Andreas Schwab]

Thomas Dickey <[EMAIL PROTECTED]> writes:

|> On Wed, Oct 09, 2002 at 12:09:09PM +0200, Andreas Schwab wrote:
|> > In my experience almost all problems that occur while moving to autoconf
|> > 2.5x are outright bugs in the configure.in/aclocal.m4 scripts.
|> 
|> We've already discussed this before, and I decided not to rely upon your opinion

You are free do so, of course, but then don't complain that the rest of
the world is moving forward.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Thomas Dickey]

On Wed, Oct 09, 2002 at 01:15:07PM +0200, Andreas Schwab wrote:
> Thomas Dickey <[EMAIL PROTECTED]> writes:
> 
> |> On Wed, Oct 09, 2002 at 12:09:09PM +0200, Andreas Schwab wrote:
> |> > In my experience almost all problems that occur while moving to autoconf
> |> > 2.5x are outright bugs in the configure.in/aclocal.m4 scripts.
> |> 
> |> We've already discussed this before, and I decided not to rely upon your opinion
> 
> You are free do so, of course, but then don't complain that the rest of
> the world is moving forward.

or going in circles, or - in this case, a random walk.

-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool 1.4.2 on Darwin

[Benjamin Reed]

On Wednesday, October 9, 2002, at 01:20 AM, Christoph Egger wrote:

>> so diff would be just in the last part around `-install_name
>> $parth/$soname`
>>
>
> Good to know. Is there an anonymous CVS access? If yes, where and how?
> Then I could give you a diff against this branch, if merging makes you
> trouble.

The patch I posted yesterday for darwin contains the -install_name 
fixes already if you want to use that...



___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Thomas Dickey]

On Wed, Oct 09, 2002 at 12:09:09PM +0200, Andreas Schwab wrote:
> In my experience almost all problems that occur while moving to autoconf
> 2.5x are outright bugs in the configure.in/aclocal.m4 scripts.

We've already discussed this before, and I decided not to rely upon your opinion

-- 
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Libtool 1.4.3

[Andreas Schwab]

"Thomas E. Dickey" <[EMAIL PROTECTED]> writes:

|> On Tue, 8 Oct 2002, Lars Hecking wrote:
|> 
|> > Bob Friesenhahn writes:
|> > > On 8 Oct 2002, Akim Demaille wrote:
|> > > >
|> > > > There is one big question which must be answered first: will it have
|> > > > to be Autoconf 2.13 compatible?
|> > > >
|> > > > I *strongly* suggest that it must not.  It should AC_PREREQ 2.54
|> > > > immediately.  Then, I'm fine with checking the M4 code and making it
|> > > > up to date.  If needed, I'll wrap a 2.55 with whatever is needed to
|> > > > have Libtool work better with Autoconf.
|> > >
|> > > I agree.  I can't imagine why anyone would want to use an antique
|> > > version of Autoconf which dates from 1996.
|> >
|> >  Because it works? In any case, it's the respective maintainer's choice.
|> >
|> >  Making autoconf incompatible with previous versions of itself while not
|> >  upping the major release number at the same time was a pretty bad move IMHO.
|> 
|> Deliberately introducing design incompatibilities simply encourages people
|> to use other tools.

In my experience almost all problems that occur while moving to autoconf
2.5x are outright bugs in the configure.in/aclocal.m4 scripts.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool