Re: shared library depending on static library on Solaris
> > Having non-pic code in a shared lib has as effect that the lib > > actually isn't shared by several processes, so it's a waste of > > memory. Not everyone's top priority is memory. Non-pic code runs significantly faster on x86; for PHP scripts it can make about 30-50% difference in speed, depending on how the engine was built. There are various scenarios where this is particular useful. Think of a web server which loads various modules and afterwards only replicates itself using fork. The maps are shared between the related processes, so whether the code is pic or not makes no significant difference memory-wise. The increase in throughput is quite measurable though. - Sascha ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Creating lock file for compilers that don't support -c -o
> I'd rather see a link to the POSIX standard defining link as atomic. IEEE Std 1003.1-2003 http://www.opengroup.org/onlinepubs/007904975/functions/link.html "The link() function shall atomically create a new link for the existing file and the link count of the file shall be incremented by one." - Sascha ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
> 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.4.3
[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
[Cc line trimmed] > me too! :) I think we have heard all arguments by now. There is no need to reiterate them. Whatever the outcome of this thread might be -- I hope those who work on libtool will continue to provide a toolkit which is suitable for all of us -- developers and users alike. Thanks - Sascha ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
> I developed/maintain the configure script for ImageMagick. While the > total lines in the generated configure script is meaningless, it is > less than 1/2 of what you report for PHP, and PHP's configure script > is 4-8X larger than typical configure scripts for other large packages > (e.g. 4X larger than the configure script for OpenSSH). This seems > odd to me. There is lot of redundancy included which might be the reason for the slow down. I have thought about using shell functions instead of expanding m4 macros all the time. That might improve things a bit. > Having adopted every new Autoconf which has been released, I can > happily say that as long as you avoid using undocumented Autoconf > internals, it is not particularly difficult to make the minor > modifications required to stay current. PHP's system has been supporting autoconf 2.50 since its inception. 2.5x is a burden on the developer's though who improve the build system. The more time an edit/build cycle takes, the less likely someone will try to make modifications and/or test them properly. > I don't believe that the decision by some factions to stick with a > particular Autoconf software version for the rest of time should be > allowed to hinder the development of Libtool. Well, if it is possible for a complex framework as ours to maintain compatibility, there should be only few reasons why it cannot work for libtool as well. Of course, whoever spends their time on libtool development gets to make the final decision. - Sascha ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
> > There is one big question which must be answered first: will it have > > to be Autoconf 2.13 compatible? We use it for the PHP project (>80k lines configure script), because 2.5x is 5 to 6 times slower and contains a dependency-ignorant cache system. So, please don't create incompatibilities, unless you really have to. - Sascha ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Portability of find(1)
> I'm looking for information on the portability of find(1). Please,
> send me everything you know. In particular, I think I'm understanding
> that `{}' is portably replaced by the argument only when alone, i.e.,
> exactly
'{}' can only be used portable, if it is a separate argument.
Also refer to SUSv2 which says on this topic
-exec utility_name [argument..] ;
[..] A utility_name or argument containing only the two
characters {} will be replaced by the current pathname. If a
utility_name or argument string contains the two characters
{}, but not just the two characters {}, it is
implementation-dependent whether find replaces those two
characters with the current pathname or uses the string
without change.
http://www.opengroup.org/onlinepubs/007908799/xcu/find.html
- Sascha Experience IRCG
http://schumann.cx/http://schumann.cx/ircg
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
