Re: Libtool 1.4.3
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
Re: Libtool 1.4.3
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.2 on Darwin
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
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.3
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
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
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
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
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
Satellite TV hex files for Funcards, Goldcards
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 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
Re: libtool 1.4.2 on Darwin
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
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
Libtool 1.5
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.5
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.3
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]) http://www.eyrie.org/~eagle/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.5
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.2 on Darwin
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.5 1.4.3
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.5 1.4.3
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.4.2 on Darwin
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.3
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 1.4.3
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=mpeg2decver=0.2.1-2arch=hppastamp=1031760849file=logas=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 21 \
../libtool --mode=compile $CC $CFLAGS -prefer-non-pic \
-c g.c /dev/null 21 \
../libtool --mode=link $CC $CFLAGS -prefer-non-pic -o libfoo.la \
f.lo g.lo /dev/null 21 \
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 = xyes; 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, 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
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.5 1.4.3
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
* 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: MinGW libtool DLL failure
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
Re: MinGW libtool DLL failure
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 [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
Free Web survey - get your questions answered
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
