The curl package is using Debian autoconf to generate its configure script, and I was advised to report this issue here for tracking and possible resolution by the curl team. Autoconf 2.63 is generating a configure script that set up the environment variable as_echo to spawn a shell that uses eval to write out text. This does not work well on OpenVMS. Due to a bug that I have not been able to trace down, the resulting configure script for curl hangs every time it is run. It does not look like it will be possible in the short or intermediate term to find and eliminate that bug. Changing configure to use: as_echo="echo" results in the configure script running to completion. Even with out the bug that prevents the configure script from completing, not using the built in "echo" command is a significant performance hit, as spawning processes on OpenVMS is much more expensive than on Unix. As a work around, on VMS, I am running a script to edit the configure script to force as_echo="echo" before running the configure in curl. bash$ uname -a OpenVMS EAGLE 0 V8.3 AlphaServer_DS10_617_MHz Alpha Regards, -John wb8tyw@qsl.net Personal Opinion Only
Hi This is not a curl bug. Marking it as such is not constructive. This is an autoconf bug. It generates bad/ineffective output that isn't very good to run on OpenVMS. Possibly curl can add a local hack to work around the flaw, but it cannot be more than a work-around then.
"John E. Malmberg" <wb8tyw@qsl.net> writes: What curl team is this, by the way? I don't understand why the Debian maintainers of curl would be considering OpenVMS issues. Does it occur with Autoconf 2.67?
[Please stop dropping the CC to the BTS! This is the only way that the discussion can be properly logged.] John Malmberg <wb8tyw@gmail.com> writes: OK. Please report your results. I do not have any access to OpenVMS. And you say that you do not have time to debug it. So we will probably have to just leave this bug open and unresolved, unless some helpful person comes along with a fix. It's hard for me to feel motivated about support for OpenVMS in any case.
reassign 619380 autoconf thanks Daniel Stenberg <daniel@haxx.se> writes: "John E. Malmberg" <wb8tyw@qsl.net> said that it should be resolved by the curl team: Now you say he is wrong about that, so I'm reassigning it back to autoconf.
The dropping on that last message was unintentional. I noticed that it was being sent from the wrong e-mail address and tried to cancel the send, but it only canceled the send to the cc: list. That is why I resent it with the correct from: address with the cc: intact. Regards, -John wb8tyw@qsl.net
http://curl.haxx.se/ Specifically Daniel Stenberg. His logic was that curl was using the Debian autoconf, so that notification of the issue should be reported to Debian autoconf as a first step in providing feedback to the autoconf project, as curl is probably going to continue to be maintained on Debian systems. http://curl.haxx.se/mail/lib-2011-03/0070.html I do not know. I can not do any additional checks until this evening. The issue is present in the configure scripts currently being generated and placed in the curl daily snapshots. Regards, -John wb8tyw@qsl.net
Curl daily tarball is reporting that configure is built by Autoconf 2.67. Examination of that section of that generated configure file shows that it is identical to the code generated by Autoconf 2.63. Currently I am using a quick patch script to get the curl configure script to work. The patch is dependent on the generated configure script not changing much, so it eventually will have to be replaced. It would be useful if there was an easy fix for autoconf that if as_echo was already assigned a value before Configure was started, that it would just use that value instead of doing the tests for alternatives. That way when OpenVMS gets support for "print -r or printf" as bash builtins, it looks like everything may start working with out additional hacks. For the short term, OpenVMS is stuck at bash 1.14.8 and other tools of that age. I seem to be one of the few OpenVMS programmers that are even trying to run the configure scripts when porting OpenSource projects. There is a VMS system for free / open access at Encompasserve.org that has the older GNU tool chain set up on it. I am quite sure that autoconf will not even begin to run on it at this time though. Regards, -John wb8tyw@qsl.net