|
|
|
|
|
|
| Author |
Message |
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
 Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: GNU make (was Re: 5.8.6 - %MMS-F-GWKNOACTS, Actions to update ATTRS.C are unknown.)
|
|
|
Craig A. Berry wrote:
| Quote: | When GNV gets to the point where we can use Configure rather than
configure.com and stop maintaining a separate behemoth configuration
script, that's the point where we will need to update support for GNU
make.
|
There are people looking at getting GNV so that it can handle configure
scripts better. Right now though, it is only being supported by HP on
64 bit platforms. I do not know if the current GNV source kit will
build on VAX.
I noticed the post on comp.os.vms about bug reports/fixes to GNV posted
to sourceforge being unanswered, and I will try to find out what is
happening there.
As I remember things, the Source Forge GNV site was set up by OpenVMS
users, and not by what is now HP. That may be contributing to the
communications problem with items posted there.
Be assured, bug reports are wanted, and fixes are even more wanted. :-)
In the case of the INFO-ZIP and VMSTAR that are bundled with GNV, these
are basically maintained externally to GNV and HP, and the HP GNV
maintainers are trying to coordinate changes to them with those maintainers.
Interestingly enough, SAMBA V4 seems to have changed to using Perl to
generate their configuration information. Other open source projects
are also using Perl as part of their build process.
And one of the bottlenecks on some of these processes is that they need
perl to only use UNIX format file specifications.
Also, to answer your other question, lstat() showed up in 7.3-1
according to the C header files. Until 8.2 + future RMS SYMLINKS ECO
kit, it behaves the same as stat(), and if support for lstat() is not
configured, Perl already knows to substitute stat(). And there is no
plans to backport these changes to earlier VMS versions or to implement
them on VAX.
-John
wb8tyw@qsl.net |
|
| Back to top |
|
 |
Thomas R Wyant_III
*nix forums beginner
Joined: 08 Feb 2005
Posts: 6
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: When was fab$v_erl introduced?
|
|
|
Thomas R Wyant_III/AE/DuPont wrote on 02/24/2005 10:58:40 AM:
[snip /]
| Quote: | Yes, I was pursuing conditionalizing on __VMS_VER. For some reason
it didn't occur to me to just
#ifdef fab$v_erl
|
Well, maybe it was the second thought that was no good here. What I fear
is that fab$v_erl is part of a struct, not a preprocessor macro, and hence
won't be defined (in the preprocessor sense) even under versions of VMS
that support the functionality.
Net result: Could someone who has access to 7.3 check to see what the
patch does? What I fear is that it will report FALSE for the erase bit
even when it's set.
My problem is that I don't have access to VMS 7.3. So I'm kind of flying
blind. My apologies if I have screwed anyone up.
Tom Wyant
This communication is for use by the intended recipient and contains
information that may be privileged, confidential or copyrighted under
applicable law. If you are not the intended recipient, you are hereby
formally notified that any use, copying or distribution of this e-mail,
in whole or in part, is strictly prohibited. Please notify the sender
by return e-mail and delete this e-mail from your system. Unless
explicitly and conspicuously designated as "E-Contract Intended",
this e-mail does not constitute a contract offer, a contract amendment,
or an acceptance of a contract offer. This e-mail does not constitute
a consent to the use of sender's contact information for direct marketing
purposes or for transfers of data to third parties.
Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean
http://www.DuPont.com/corp/email_disclaimer.html |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
[.t.io]fs.t fails with hard links on OpenVMS.
|
|
|
To be more precise,
The test [.t.io]fs.t will only pass when hard links {d_link} if you set
the default RMS protections to be (O:RW, G:RW, W:RW).
I think that it is a cross platform bug where the test is assuming such
a default protection would be in place.
I am not sure how you would want to fix this, set the default RMS
protections before running the test and put them back afterward?
Or special case the test for VMS to just make sure that the linked file
has the same protections as the original.
Also the modules utils/c2ph.pl, x2p/pl will not allow Perl to be built
with hard link support unless they are modified. They are trying to
create hard links from a different base filename than exists on OpenVMS.
This also requires that to support hard links in Perl that the build be
done on an ODS-5 volume with hard links enabled.
And of course the disk that the tests are run on needs to have hard links
enabled. :-)
The following makes the build complete, but someone more familiar with
what is really meant to be done may want to do something different.
$ gdiff -u -b x2p/s2p.pl_5_8_6 x2p/s2p.pl
--- x2p/s2p.pl_5_8_6 Thu Feb 10 15:22:08 2005
+++ x2p/s2p.pl Thu Feb 10 15:26:16 2005
@@ -2048,7 +2048,11 @@
unlink 'psed';
print "Linking s2p to psed.\n";
if (defined $Config{d_link}) {
+ if ($^O eq 'VMS') {
+ link 's2p.com', 'psed';
+ } else {
link 's2p', 'psed';
+ }
} else {
unshift @INC, '../lib';
require File::Copy;
$ gdiff -u -b utils/c2ph.pl_5_8_6 utils/c2ph.pl
--- utils/c2ph.pl_5_8_6 Thu Feb 0 13:24:12 2005
+++ utils/c2ph.pl Thu Feb 10 15:23:57 2005
@@ -1437,7 +1437,11 @@
unlink 'pstruct';
print "Linking c2ph to pstruct.\n";
if (defined $Config{d_link}) {
+ if ($^O eq 'VMS') {
+ link 'c2ph.com', 'pstruct';
+ } else {
link 'c2ph', 'pstruct';
+ }
} else {
unshift @INC, '../lib';
require File::Copy;
Currently the diffs in the configure.com include several patches from
Craig Berry and for enabling symbolic link support, which I do not have
done yet.
But here is the test for hard link support for 8.2. A creative person
can make a test that works for 7.3-1 and 7.3-2.
....
$ use64bitint = "n"
+$ uselargefiles = "n"
+$ usesymlinks = "n"
+$ usehardlinks
.....
+$ config_symbols4
="|usethreads|usevmsdebug|usefaststdio|usemallocwrap|unlink_all_versions
|uselargefiles|usehardlinks|usesymlinks|"
.....
$ d_link = "undef"
$ tmp = f$extract(1,3,f$edit(f$getsyi("VERSION"),"TRIM,COLLAPSE"))
$!
$! Hard link support has been present since 7.3-1 except for the
$! easy to use DCL test to see if hardlinks are enabled on the build
$! disk. That would require more work to test, and I am only testing
$! this on 8.2.
$!
$ IF (usehardlinks .OR. usehardlinks .eqs. "define")
$ THEN
$ IF (tmp .GES. "8.2") .AND. (f$getsyi("HW_MODEL") .GE. 1024)
$ THEN
$ IF f$getdvi("SYS$DISK","HARDLINKS_SUPPORTED")
$ THEN
$ echo "Found 64 bit OpenVMS 8.2, will build with hardlink support"
$ d_link = "define"
$ ELSE
$ echo4 "You configured with -Dusehardlinks but your build disk does not"
$ echo4 "have hard links enabled. I am disabling hard link support."
$ ENDIF
$ ENDIF
$ ELSE
$ echo4 "You configured with -Dusehardlinks but your CRTL does not support"
$ echo4 "hard links. I am disabling hard link support."
$ usesymlinks = "undef"
$ ENDIF
......
-$ WC "d_link='undef'"
+$ WC "d_link='" + d_link + "'"
So anyone that want's a perl that works for hard links, now has the raw
information on how to build it.
I do not know what issues would occur if someone tried to build perl with
support for hard links on a disk that did not support it other than the
two modules and the test that failed durring my initial attempts.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: symlink support
|
|
|
Craig A. Berry wrote:
| Quote: | At 6:21 PM -0500 2/18/05, John E. Malmberg wrote:
I am still working on getting the symlink support going but there
are significant implications to using symbolic links on OpenVMS
once the ECO kit is available.
Perl is affected by this, so here is a preview:
Symbolic links introduce and for some operations require the use
of a new UNIX style filename convention that is being called POSIX
format.
The processing of these specifications is now done by RMS and not
by the CRTL so there is a way to use them with almost all existing
OpenVMS programs.
Because of the differences in processing a symbolic link references,
any program that does it's own translation of file specifications
from UNIX format to OpenVMS native format will not return the right
answer for symbolic links.
I find this curious, since I'm not aware of any difference in the
syntax of a filename that indicates whether or not it's a symbolic
link on unix systems. What is there about the file specification of
a symbolic link that cannot be expressed in VMS syntax?
|
It is expressible in VMS syntax, it is just that currently the CRTL
routines that operate on symbolic links require POSIX syntax, not VMS
syntax. I do not know if that limitation will be removed in the future.
RMS will deal with symbolic links transparently, using RMS routines to
non-transparently operate on symbolic links requires special coding.
The most obvious case shows up with the file [.testlink] that is a
symbolic link to _a_/_deeper_/_directory_/_level_
From the CRTL with POSIX file translations enabled, doing a dir of
testlink/../ will give you the files in _a_/_deeper_/_directory_/
Translating that to a VMS format requires that the translation routine
knows when it has encountered a symbolic link. Much easier just to let
the CRTL deal with it.
And DCL will not know how to deal with [.TESTLINK.-] in the same way
that the GNV bash or the CRTL will do.
| Quote: | The CRTL will have a new feature setting to indicate when the user
has selected that UNIX style pathnames should be parsed in POSIX style,
and while I can easily test for this in the C code, but it looks like I
would need a way to let the .PM scripts know that this feature has been
activated by the user in order to for the special cased OpenVMS code to
work with symbolic links.
Possibly.
The perl absolute path routine is one of the ones that is affected
by this as it is special cased for OpenVMS to do a manual parse of
the filename.
It calls VMS::Filespec::rmsexpand, which invokes mp_do_rmsexpand() in
[.vms]vms.c. We could check for the feature involved here and omit
the call to do_tovmsspec() in mp_do_rmsexpand() on the assumption
that, as you seem to be implying above, sys$parse can handle unix
syntax filenames when the symlink feature is available. There may be
side effects and this would have to be studied carefully.
|
sys$parse with the RMS SYMLINK kit will handle POSIX style names as long
as they are prefixed with ^UP^ to identify them. So it is not
automagically transparent.
To have it return the real path name requires a qualifier to tell it not
to work. And from a quick glance, this qualifier is only in the
expanded NAML block. So it looks like if this were to be done at
rmsexpand, there would need to be two versions of it, one where it was
not supposed to reveal the contents of the symbolic link, and one where
it does. And so far, it appears that it only one place requires the
symbolic link be revealed.
| Quote: | It looks like the way to do that is to have the affected scripts
look up the setting of the DECC feature logicals while they run.
If Perl is to support DECC$FILENAME_UNIX_ONLY and/or
DECC$FILENAME_UNIX_REPORT, then yes, there will have to be some
changes to various things and these will not be particularly easy
changes. Historically, way back when the CRTL kinda sorta supported
unix syntax filenames but often failed to handle them properly, the
safest thing to do was just always convert to VMS syntax before
calling the CRTL, and of course calls to system services and other
RTLs have always had to do this as well. The Perl implementation is
a very mixed bag of calls to the CRTL and to native APIs, so it might
well be rather difficult to disentangle when we need unix syntax and
when we need VMS syntax under conditions where we can no longer
assume it's always safe to convert to VMS syntax.
|
I agree, and this is something that will probably take a while to phase in.
And the existing method of perl's operation should be the maintained and
be the default.
These feature logicals would only be set when someone specifically
wanted to modify perl's behavior on VMS to pretend that it is UNIX.
I have run into one problem with that so far though. In order for
opendir()/readdir() to function correctly, I had to set the code to use
the CRTL versions when the POSIX feature is on.
This meant that I had to make the CRTL dirent and DIR structure used for
OpenVMS 8.2 the one that is visible outside of VMS.C, and then if the
Posix feature logical is not set, use the existing structure internally.
The side effect of this is that the structure member d_namlen is not
present. As near as I can tell only one C module is affected by this
PP_SYS.C, and if config.h shows that member is not present, instead of
calculating the value manually, it just passes 0 for it. So I am not
sure that there is even any real impact to the non-posix mode. The rest
of the code that references d_namlen will use strlen() to get the value.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: Changing osname or ^O from VMS.C at startup?
|
|
|
Craig A. Berry wrote:
| Quote: | At 12:32 AM -0500 2/16/05, John E. Malmberg wrote:
$ search/exact *.c "OSNAME"
******************************
D0:[CRAIG.PERL-5_8]perl.c;1
PL_osname = savepv(OSNAME);
|
Some how I must have missed that one. The help of this mailing list has
been of great assistance, these modifications that I am attempting, and
I am sure I will probably need more.
It looks like changing the osname is not the way to do what I need done.
I am still working on getting the symlink support going but there are
significant implications to using symbolic links on OpenVMS once the ECO
kit is available.
Perl is affected by this, so here is a preview:
Symbolic links introduce and for some operations require the use of a
new UNIX style filename convention that is being called POSIX format.
The processing of these specifications is now done by RMS and not by the
CRTL so there is a way to use them with almost all existing OpenVMS
programs.
Because of the differences in processing a symbolic link references, any
program that does it's own translation of file specifications from UNIX
format to OpenVMS native format will not return the right answer for
symbolic links.
The CRTL will have a new feature setting to indicate when the user has
selected that UNIX style pathnames should be parsed in POSIX style, and
while I can easily test for this in the C code, but it looks like I
would need a way to let the .PM scripts know that this feature has been
activated by the user in order to for the special cased OpenVMS code to
work with symbolic links.
The perl absolute path routine is one of the ones that is affected by
this as it is special cased for OpenVMS to do a manual parse of the
filename.
It looks like the way to do that is to have the affected scripts look up
the setting of the DECC feature logicals while they run.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: Changing osname or ^O from VMS.C at startup?
|
|
|
Craig A. Berry wrote:
| Quote: | At 5:14 PM -0600 2/15/05, John E. Malmberg wrote:
On Tue, 15 Feb 2005, Craig Berry wrote:
The global PL_osname is set in S_init_predump_symbols in perl.c, which is
called from S_parse_body when a Perl script is compiled. If you put in
your own value in start-up code, I'm pretty sure it will get overwritten
later. You could stick some code in S_init_predump_symbols to check for
a logical name and reset accordingly. That might be a little dangerous
since we don't really know what side effects there might be to dynamically
changing the OS name.
Apparently the OS name is dynamically set now by a perl script, config.p*,
and I can not find a pre-compiled version of it. So what I think I might
try is modifying that script to change the OS type and see what happens.
That's not dynamic in the sense of being set at run time. Config is
hard-wired to return the same value that's in config.h:
$ perl -"V:osname"
osname='VMS';
config.h has the C macro OSNAME, which is in turn used by
S_init_predump_symbols as I mentioned above. Config the Perl module
and config.h the C header both get their values from config.sh, which
is generated at configuration time by configure.com.
|
I did a search of the source code before I posted, while the osname
macro is defined in config.h, I can not find anything in the perl .C
files that reference any of the osname macros in any of the .H files, or
any macros that would hide such references.
I will have to look at the S_init_predump_symbols to see if that gives
me any more clues.
Thanks,
-John
Personal Opinion Only |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: Changing osname or ^O from VMS.C at startup?
|
|
|
On Tue, 15 Feb 2005, Craig Berry wrote:
| Quote: |
On Tuesday, February 15, 2005, at 02:21PM, John E. Malmberg <malmberg@Encompasserve.org> wrote:
It appears that the VMS specific file name behavior is tied to many perl
scripts that are checking the ^O for 'VMS'.
What I would like to investigate is having a option where a symbol or
logical name could be used by the init and pre-init code in VMS.C
to change the ^O to report 'GNV'. That same feature would also cause
the DECC feature settings to go to full UNIX/POSIX filename compatibility
mode.
The global PL_osname is set in S_init_predump_symbols in perl.c, which is
called from S_parse_body when a Perl script is compiled. If you put in
your own value in start-up code, I'm pretty sure it will get overwritten
later. You could stick some code in S_init_predump_symbols to check for
a logical name and reset accordingly. That might be a little dangerous
since we don't really know what side effects there might be to dynamically
changing the OS name.
|
Apparently the OS name is dynamically set now by a perl script, config.p*,
and I can not find a pre-compiled version of it. So what I think I might
try is modifying that script to change the OS type and see what happens.
| Quote: | If you can live with configuration time changes, look for
$ osname = F$EDIT(F$GETSYI("NODE_SWTYPE"),"COLLAPSE")
in configure.com and modify it to say whatever you want.
|
I missed changing that to only be set if osname was not previously
defined, so my last build was still with osname="VMS".
I did find the test later on that bails if the osname .nes. "VMS"
It turns out now, that perl will not build if the osname is not "VMS",
it is failing on opendir("./../../"), and I have not found a way to
get around that yet.
So it looks like I need to change the osname after the build is complete.
The value in config.h is not used by any of the C code.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Debugger - was: Changing osname or ^O from VMS.C at startup?
|
|
|
On Tue, 15 Feb 2005, Craig Berry wrote:
| Quote: | On Tuesday, February 15, 2005, at 03:21PM, John E. Malmberg wrote:
I am noticing on a previous build that a number of the tests are failing
when you build with the VMS DEBUG option, and the tests use PERLSHR
instead of DBGPERLSHR. When the tests are run using DBGPERLSHR they
succeed. This is telling me that when the VMS DEBUG option is selected,
PERLSHR is not being built correctly.
When you configure and build for the VMS debugger, there is not supposed
to be a PERLSHR.EXE, only DBGPERLSHR.EXE. If you build in debug
without configuring for it, you will see the symptoms you describe.
Switching back and forth between a debug and non-debug build without
reconfiguring is not supported. If you are configuring for the
debugger and still seeing this issue, please holler.
|
Hollering.
I did a MMK realclean between the builds, which gets rid if any
dangling executables.
Directory BUILD_ROOT:[000000]
DBGMINIPERL.EXE;1 7269 15-FEB-2005 16:20:51.35 (RWED,RWED,RE,)
DBGPERL.EXE;1 52 15-FEB-2005 16:21:56.35 (RWED,RWED,RE,)
DBGPERLSHR.EXE;1 7469 15-FEB-2005 16:21:54.61 (RWED,RWED,RE,)
MINIPERL.EXE;3 4111 15-FEB-2005 16:54:19.09 (RWED,RWED,RE,)
MINIPERL.EXE;2 4111 15-FEB-2005 16:54:17.57 (RWED,RWED,RE,)
MINIPERL.EXE;1 3873 15-FEB-2005 16:20:53.78 (RWED,RWED,RE,)
NDBGperl.exe;1 8 15-FEB-2005 16:21:56.72 (RWED,RWED,RE,)
PERL.EXE;1 6 15-FEB-2005 16:54:46.44 (RWED,RWED,RE,)
PERLSHR.EXE;1 3441 15-FEB-2005 16:54:45.53 (RWED,RWED,RE,)
Ahhh....
Apparently the MMK/FROM_SOURCES TEST is creating the non debug version for
it's use, and that is causing the tests to fail.
So I need to modify that command in my master build file to also
have the /macro=__DEBUG__=1 for that MMK command.
| Quote: | BTW, the simplest way to configure for the debugger is:
$ @configure -"Dusevmsdebug" -"des"
|
Currently I am using:
$ @build_root:['root']configure.com -"Dusevmsdebug" -
"-Dunlink_all_versions" "-Duselargefiles" "-Dusesymlinks" -
"-Dusehardlinks" "-Dosname=GNV" "-de"
If the GNV build works, I am going to make it imply:
unlink_all_versions, uselargefiles, usesymlinks, and usehardlinks,
and possibly enabling all 64 bit options.
I plan to also put in vms.h the #ifdef for the GNV environment to set
the C feature logical to default to that all file specifications will
be in UNIX format and case sensitive, unless the user overides this.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: Changing osname or ^O from VMS.C at startup?
|
|
|
On Tuesday, February 15, 2005, at 03:21PM, John E. Malmberg <malmberg@Encompasserve.org> wrote:
| Quote: | I am noticing on a previous build that a number of the tests are failing
when you build with the VMS DEBUG option, and the tests use PERLSHR
instead of DBGPERLSHR. When the tests are run using DBGPERLSHR they
succeed. This is telling me that when the VMS DEBUG option is selected,
PERLSHR is not being built correctly.
|
When you configure and build for the VMS debugger, there is not supposed to be a PERLSHR.EXE, only DBGPERLSHR.EXE. If you build in debug without configuring for it, you will see the symptoms you describe. Switching back and forth between a debug and non-debug build without reconfiguring is not supported. If you are configuring for the debugger and still seeing this issue, please holler.
BTW, the simplest way to configure for the debugger is:
$ @configure -"Dusevmsdebug" -"des" |
|
| Back to top |
|
|
Nico Baggus
*nix forums beginner
Joined: 27 May 2005
Posts: 1
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
RE: When was fab$v_erl introduced?
|
|
|
LS,
| Quote: |
Net result: Could someone who has access to 7.3 check to see
what the patch does? What I fear is that it will report FALSE
for the erase bit even when it's set.
Compaq C V6.4-008 on OpenVMS Alpha V7.3 |
there is no fab$v_erl in FABDEF.H.... or other header file.
kind regards,
Nico Baggus
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.
Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
----------------------------------------------------------------- |
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Fri May 27, 2005 7:41 pm Post subject:
RE: Building release 5.8.4 on HP I64
|
|
|
At 1:16 PM -0600 5/27/05, Doug Woronuk wrote:
| Quote: | Craig;
I went to the [.PERLBUILD584.SOURCE] directory and did this:
ITN2>search config.sh socksizetype,ccname
ccname='VAX'
socksizetype='undef'
ITN2
VAX? Kinda funny, since I'm on an Itanium.
|
For historical reasons, configure.com assumes you are running the
long-defunct VAX C unless if finds evidence to the contrary. I think
the immediate issue probably results from the rebranding of the compiler to HP
C from Compaq C, which has not yet happened on Alpha and VAX (no new
compiler released yet), but has happened on Itanium. Try the
following patch to configure.com. If you don't have GNU patch, just
edit it to replace the "hp" with "HP".
--- configure.com;-0 Fri May 20 03:23:14 2005
+++ configure.com Fri May 27 16:28:37 2005
@@ -1609,7 +1609,7 @@
$ ENDIF
$ ELSE
$ IF (F$LOCATE("DEC",line).NE.F$LENGTH(line)).or.(F$LOCATE("Compaq",line).NE.F$LENGTH(line)) -
- .or.(F$LOCATE("hp",line).NE.F$LENGTH(line))
+ .or.(F$LOCATE("HP",line).NE.F$LENGTH(line))
$ THEN
$ vms_cc_dflt = "/decc"
$ vms_cc_available = vms_cc_available + "cc/decc "
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser |
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Tue May 31, 2005 1:49 am Post subject:
RE: Building release 5.8.4 on HP I64
|
|
|
At 4:13 PM -0600 5/27/05, Doug Woronuk wrote:
| Quote: | Things are looking better. It's still compiling, and here is the result of the SEARCH command now:
ITN2>search config.sh socksizetype,ccname
ccname='DEC'
socksizetype='unsigned int'
Assuming this all works, I'll want to rebuild it again with G_Float format instead of IEEE. Is that also just a parameter to the configure.com script?
|
Yes, I think it's covered in perlvms.pod or README.vms, but IIRC, the
configure line should be something like:
$ @configure -"Uuseieee" -"Duser_c_flags=/FLOAT=G_FLOAT"
to disable IEEE and add G_FLOAT as an explicit compiler flag. On
Alpha you could skip the second part as G_FLOAT is the default, but
on Itanium I think IEEE is the default, and on VAX, D_FLOAT is the default.
| Quote: | Thanks for all your help Craig.
|
You're welcome.
| Quote: | I had been quite disappointed with the response from Perl maintainers a few years ago when I reported some problems with Perl accessing files when the filename contained DECnet node names,
|
Um, I did give you a precise diagnosis of the problem and pointed
toward what it would take to fix it.
| Quote: | and again a year or so ago when some functionality was lost upgrading from 5.005-3 to 5.8.0 and the response seemed to imply that because not very many people run OpenVMS with Perl, it was likely not going to be worked on.
|
I don't see this in the archives, so I'm not sure what exactly you
are referring to. This is an all-volunteer operation here and people
do have limits on the amount of time and talent they can give away.
There is a longish list of things that ought to be done that have not
yet been done, and new things are showing up all the time. Having
said that, Perl 5.8.7 is about to be released and all 99,000 or so
tests are passing, at least on Alpha which is what I can test with
most easily.
I am grateful for clear bug reports even if nothing can be done about
them in the short run, but to move your issues to the top of the list
still needing attention, you can code them up yourself and post
patches, hire some help, or submit bug reports and feature requests
to HP via your HP support contract. I've seen plenty of evidence
that OpenVMS Engineering has fixed Perl bugs that customers have
reported and also that they are working on making Perl aware of new
OS and CRTL features.
| Quote: | Your responsiveness to this has given me some optimism that open software might actually work. I've always been of the opinion that a paid organization should be the only ones to own the source and be permitted to modify the source, and that I as the user should pay for the runtime and thus fund the maintainers who would have a commitment to provide support in a timely manner. Maybe times are a-changin'.
|
There is a lot of crappy software and poor support out in the wild,
but I can't see that it cross-correlates with either open source or
commercial; there are plenty of good and bad examples of both.
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Tue May 31, 2005 9:34 am Post subject:
Re: Building release 5.8.4 on HP I64
|
|
|
Craig A. Berry wrote:
| Quote: | At 4:13 PM -0600 5/27/05, Doug Woronuk wrote:
Assuming this all works, I'll want to rebuild it again with G_Float
format instead of IEEE. Is that also just a parameter to the
configure.com script?
Yes, I think it's covered in perlvms.pod or README.vms, but IIRC, the
configure line should be something like:
$ @configure -"Uuseieee" -"Duser_c_flags=/FLOAT=G_FLOAT"
to disable IEEE and add G_FLOAT as an explicit compiler flag. On
Alpha you could skip the second part as G_FLOAT is the default, but
on Itanium I think IEEE is the default, and on VAX, D_FLOAT is the default.
|
I am told by many folks that there is a very significant performance
penalty for using anything other than IEEE float on I64.
I would recommend avoiding G_FLOAT on I64 if you can.
-John
wb8tyw@qsl.network
Personal Opinion Only |
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Tue Jul 12, 2005 12:13 am Post subject:
Re: Hard link support for VMS (part 2)
|
|
|
John,
Thanks for all your good work on this. I've sprinkled in a few
comments below, but it shouldn't be too tough to get this work
incorporated into the authoritative sources, though I can't make any
promises about when that will happen.
At 6:43 PM -0400 7/11/05, John Malmberg wrote:
| Quote: | This configure.com tests to see if hard links are enabled on the build disk, and if so enables hard link support in the build.
@@ -1480,7 +1506,7 @@
$ IF F$TYPE(archlib).EQS."" THEN -
archlib="''vms_prefix':[lib.''archname'.''version']"
$ IF F$TYPE(bin) .EQS. "" THEN -
- bin="/''vms_prefix'/000000"
+ bin="/''vms_prefix'"
$ IF F$TYPE(privlib) .EQS. "" THEN -
privlib ="''vms_prefix':[lib]"
$ IF F$TYPE(sitearch) .EQS. "" THEN -
|
I think this needs to be the unixy equivalent of perl_root:[000000].
So are you saying that when we translate /perl_root to VMS syntax,
that's what we'll now get?
| Quote: | @@ -1595,7 +1621,7 @@
$ ENDIF
$ ELSE
$ IF (F$LOCATE("DEC",line).NE.F$LENGTH(line)).or.(F$LOCATE("Compaq",line).NE.F$LENGTH(line)) -
- .or.(F$LOCATE("hp",line).NE.F$LENGTH(line))
+ .or.(F$LOCATE("HP",F$EDIT(line,"UPCASE")).NE.F$LENGTH(line))
|
Same or similar patch is already in.
| Quote: | +$ rp = "Try to understand large files, if available? [''bool_dflt'] "
|
Large file support is already in, so for this to be applied, we will
have to sort out what's new.
| Quote: | +$ IF (tmp .GES. "8.2") .AND. (f$getsyi("HW_MODEL") .GE. 1024)
|
Last time I checked, Itanium systems return zero for
f$getsyi("HW_MODEL"). The archname symbol should already have one of
VMS_VAX, VMS_AXP, or VMS_IA64, and the vms_ver symbol should already
have the VMS version.
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser |
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Tue Jul 12, 2005 12:38 am Post subject:
Re: Hard link support for VMS (part 2)
|
|
|
At 6:43 PM -0400 7/11/05, John Malmberg wrote:
| Quote: | Perl_setup.com is optionally built such that it defines perl_root based on the directory it currently resides in, as a step toward being able to build a binary distribution kit that does not require editing it.
|
It has bothered me for a long time that we create a perl_setup.com
that cannot be distributed and used as a smart set-up procedure that
deduces its own location and sets perl_root accordingly. When I
distribute binaries, I do this, but it's not in the core for the
following reason.
The problem with creating a smart perl_setup.com is that the
installperl script, via the install target in
[.vms]descrip_mms.template, uses it to figure out the target
installation directory. So if we have a self-locating
perl_setup.com, we'll just be installing on top of the source
directory. Probably the right thing to do is rewrite the install
target so it does not depend on perl_setup.com to know where it's
installing.
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Tue Dec 02, 2008 5:35 am | All times are GMT
|
|
Personal Loans | Debt Consolidation | Mortgages | Anime Downloads | Remortgages
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Not Unix
»
VMS
»
vmsperl
