# Fwd: Re: dl() problem - Thread: https://externals.io/message/7727 - Original archive: https://news-web.php.net/php.internals/7727 - Started by Andi Gutmans on 2004-02-11T12:05:41+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #7727 — Andi Gutmans — 2004-02-11T12:05:41+00:00 URL: https://externals.io/message/7727#7727 >Date: Wed, 11 Feb 2004 14:02:41 +0200 >To: Pierre-Alain Joye >From: Andi Gutmans >Subject: Re: `dl()` problem >Cc: Pierre-Alain Joye ,zeev@zend.com > >Pierre, > >dl() should have been deprecated a long time ago. >It's not secure (for example on a shared server where you don't have >access to php.ini), it's slow and it doesn't work in multi-threaded >environments. >Besides that there are many chicken&eggs problems with `dl()` and we don't >feel it's worth screwing up the Zend/PHP source code just to work around >such problems. > >Andi > >At 12:59 PM 2/11/2004 +0100, Pierre-Alain Joye wrote: > > […] --- ## #7728 — Andi Gutmans — 2004-02-11T12:07:16+00:00 URL: https://externals.io/message/7727#7728 · In reply to: #7727 Pierre, Just to add to this, the fact that it's deprecated doesn't mean you can't use it. It just means that there are known bugs which won't be fixed and the function won't be maintained. We've been through this a few times in the past few years and the conclusion has always been that `dl()` sucks. Andi At 02:05 PM 2/11/2004 +0200, Andi Gutmans wrote: > > […] --- ## #7731 — Pierre-Alain Joye — 2004-02-11T12:18:37+00:00 URL: https://externals.io/message/7727#7731 · In reply to: #7728 Organization: Freelancer X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 11 Feb 2004 14:07:16 +0200 Andi Gutmans wrote: > Pierre, > > Just to add to this, the fact that it's deprecated doesn't mean you > can't use it. > It just means that there are known bugs which won't be fixed and the > function won't be maintained. > We've been through this a few times in the past few years and the > conclusion has always been that `dl()` sucks. Well, php dl sucks? Why it sux for php and not for other langages? (not kidding here :) ). I feel this problem in the same way as the auto* tools. Each time someone came in and say: "got errors using version x", "we" answer please use the(damn old) version 2.x or whatever. As most of other applications use recent auto* tools without problem. If we have to deprecate dl, then we have to provide an alternative (aka python import for instance). pierre --- ## #7753 — Jani Taskinen — 2004-02-11T16:10:40+00:00 URL: https://externals.io/message/7727#7753 · In reply to: #7731 > >I feel this problem in the same way as the auto* tools. Each time >someone came in and say: "got errors using version x", "we" answer >please use the(damn old) version 2.x or whatever. As most of other >applications use recent auto* tools without problem. Our codebase is much larger than any other plus we 'misuse' the auto* tools. :) Feel free to bring the stuff up-to-date so we actually COULD update to latest libtool/autoconf, etc. I looked at this once and decided it wasn't worth the effort.. Just use the snapshots if your auto* tools don't work. :) (autoconf > 2.13 is slow too. And the generated configure is REALLY slow. Not to forget the fact that the versions I tested are also buggy in some cases, can't remember right now in what way and too busy to actually test again) --Jani --- ## #7755 — Pierre-Alain Joye — 2004-02-11T16:22:18+00:00 URL: https://externals.io/message/7727#7755 · In reply to: #7753 Organization: Freelancer X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Organization: Freelancer X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 11 Feb 2004 18:10:40 +0200 (EET) Jani Taskinen wrote: > Our codebase is much larger than any other plus we 'misuse' > the auto* tools. :) Feel free to bring the stuff up-to-date so > we actually COULD update to latest libtool/autoconf, etc. > I looked at this once and decided it wasn't worth the effort.. I used the auto* tools as a sample of another similar case :). Note I'm not an expert of auto* as you seems to be, and only wondering why it does not work. Is it another good reason to delay the php5 release and fix it? It seems we are all busy as hell, and many "bugs" are left due to this fact. What do you mean by 'misuse'? maybe some informations/tips can help to get fixes? I can give it a try in 2 or 3 weeks, not before and absolutely no warranty. I'm only a poor user of these tools ;). > Just use the snapshots if your auto* tools don't work. :) I use CVS for now ;) > (autoconf > 2.13 is slow too. And the generated configure is > REALLY slow. lol who cares? Do you generate a configure every hour? > Not to forget the fact that the versions I tested are also buggy in > some cases, can't remember right now in what way and too busy to > actually test again) Could help if you remember these issues :) pierre --- ## #7759 — Sascha Schumann — 2004-02-11T16:28:51+00:00 URL: https://externals.io/message/7727#7759 · In reply to: #7755 > not an expert of auto* as you seems to be, and only wondering why it > does not work. - autoconf 2.50 is six times slower. Which in turn means that developing with it takes 6 times longer (think of edit, compile, run cycle. Yeah, someone wrote that build system with a couple thousand LOC) - limited support of m4 command set. We use some commands such as esyscmd which are supposedly unsupported by the newer autoconf tools (or as the main autoconf guy puts it "It was never supported!!!! Read the documentation!!!!"). We work around that by trashing the autoconf cache every time. > lol who cares? Do you generate a configure every hour? Try "per minute" and you get close. - Sascha --- ## #7764 — Jani Taskinen — 2004-02-11T17:09:33+00:00 URL: https://externals.io/message/7727#7764 · In reply to: #7755 >Jani Taskinen wrote: > > > […] > >I used the auto* tools as a sample of another similar case :). Note I'm >not an expert of auto* as you seems to be, and only wondering why it >does not work. Is it another good reason to delay the php5 release and >fix it? It seems we are all busy as hell, and many "bugs" are left due >to this fact. Delay it another year? Then maybe. :) I'm sure not gonna spend my precious time with this non-issue as the versions we rely on work fine. >What do you mean by 'misuse'? maybe some informations/tips can help to >get fixes? Sascha propably can explain better, I remember that the auto*/libtool developers once said we use the tools wrong or something like that. :) > > […] > >lol who cares? Do you generate a configure every hour? Yes, I generate it quite often. And my machine isn't the fastest in the world so for me it's an issue if generating configure takes very long time..here are quick'n'dirty benchmarks: Latest auto*/libtool: # time ./buildconf real 1m28.287s user 1m22.080s sys 0m5.710s "Old" auto*/libtool: # time ./buildconf real 0m18.772s user 0m15.750s sys 0m5.350s Running ./configure only takes about 20s more with new tools, so that's not so big issue. > > […] > >Could help if you remember these issues :) I have no time nor interest in testing it all again.. --Jani