|
|
|
|
|
|
| Author |
Message |
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
 Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: BUG: 5.8.6 IEEE float build support incomplete.
|
|
|
On Monday, February 28, 2005, at 02:16PM, John E. Malmberg <malmberg@Encompasserve.org> wrote:
| Quote: |
If you chose IEEE float, the build scripts do not set everything needed to
build in IEEE floating point mode.
|
Yes, they do, but you don't need to choose anything. IEEE is the default on Alpha (and now Itanium) in Perl 5.8.0 and later. See the section entitled "Floating Point Considerations" in README.vms.
I suppose it's possible we don't properly handle:
$ @configure -"Duseieee"
since that's the default behavior (and thus unnecessary) and possibly wasn't tested. I do vaguely remember testing to make sure you can disable it via:
$ @configure -"Uuseieee"
which will revert to the compiler default. I believe the compiler flags we add for IEEE are redundant on Itanium, but it's easier to minimize the number of differences. |
|
| 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: 5.8.6 - test lib/extutils/t/basic can not find mm.pm
|
|
|
On Monday, February 28, 2005, at 02:42PM, John E. Malmberg <malmberg@Encompasserve.org> wrote:
| Quote: |
I am trying to chase down some bugs in my last few test builds of perl.
The test [.lib.extutils.t.basic] is failing because:
ok 1 - chdir'd to Big-Dummy
Can't locate ExtUtils/MM.pm in @INC
(@INC contains: BFD_TEST_ROOT:lib ../lib lib) at
lib/MakeMaker/Test/Utils.pm line 249.
|
As I recently posted, the 5.8.6 MakeMaker test failures were really the result of a bug in File::Spec (now part of the PathTools distribution). Don't waste your time on this, it's been fixed. If you are preparing a custom distribution, I recommend upgrading PathTools from CPAN. |
|
| 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?
|
|
|
"Craig A. Berry" <craigberry@mac.com> wrote on 02/24/2005 06:40:32 PM:
[snip /]
| Quote: |
It looks like it's there as a macro on v7.3-1:
$ sea sys$common:[decc$lib.reference.sys$starlet_c]*.h fab$v_erl
******************************
SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C]FABDEF.H;3
unsigned fab$v_erl : 1; /* Erase Regardless of Lock */
#define fab$v_erl fab$r_fop_bits_overlay.fab$v_erl
unsigned fab$v_erl : 1; /* Erase Regardless of Lock */
#define fab$v_erl fab$r_fop_overlay.fab$r_fop_bits_overlay.fab$v_erl
|
YES!!!! It looks to me like the
#define fab$v_erl fab$r_fop_overlay.fab$r_fop_bits_overlay.fab$v_erl
is all I need for the patch to work for me (under 7.1) without subtly
breaking the functionality under systems that actually support this bit.
Both a bit mask _and_ a macro. How quantum.
Anyhow, it looks to me again like the published patch should be good.
Though I hope Peter (or someone who has 7.3 - maybe Nico, since he failed
to confirm Craig's finding?) will actually set this bit on a file and
confirm that the patched VMS::Stat returns TRUE.
Sorry to involve the mailing list in my dithering, and thank you very much
Craig for providing me the confirmation I needed.
Have I thoroughly confused the issue? Should I republish the patch? It's
the same as yesterday, it's just that yesterday afternoon I thought it was
bad, and now I'm convinced it's OK.
Tom Wyant
PS to Nico, but really to everyone -
My original dithering was because I was conscious of the definitions like
unsigned fab$v_erl : 1; /* Erase Regardless of Lock */
which are _not_ macros. The macros Craig found were farther down. The
doubled hits were because of a conditionalization on __NEW_STARLET.
TRW
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:
stat() and the NLA0: device.
|
|
|
I notice that Perl is checking if the stat is being done on the NULL
device, and generating a fake stat structure.
Is there a specific version of stat() on OpenVMS that does not return
the correct data for stat?
stat() should return the correct information from either a filespec of
"NLA0:" or "NL:" or even "/dev/null"
-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: stat() and the NLA0: device.
|
|
|
On Wed, 2 Feb 2005, Craig A. Berry wrote:
| Quote: | At 2:41 PM -0600 2/2/05, John E. Malmberg wrote:
I notice that Perl is checking if the stat is being done on the NULL
device, and generating a fake stat structure.
stat() should return the correct information from either a filespec of
"NLA0:" or "NL:" or even "/dev/null"
Sure, on recent versions of VMS. I'd be reluctant to break older
versions, at least without knowing exactly which ones I was breaking
so I could document it.
|
It may more be a case of only conditionally compiling the code in for
versions of VMS older than what it is know to work for.
Any idea what the oldest version of VMS that the current release of
Perl will still build on? HP/COMPAQ/DECC is avaialable in one flavor
or another back to OpenVMS 5.5-2.
With OpenVMS 8.2 and when using the standard compliant stat structure,
the code handling the NULL device is producing the wrong answer.
In looking at what it would take to use the standard stat structure in
Perl, the only stumbling block I am seeing is the routine Perl_cando().
With the standard compliant stat, there is no pointer to the device name,
instead a unique 64 bit number for the st_dev member is returned, and
I am currently ignorant of anyway to use that to determine the real device
name as Perl_cando() needs.
Until that is resolved, building Perl with _USE_STD_STAT will not work
right.
And with the _LARGEFILE option, mystat might as well use __ino64_t for
the ino_type and not use the rvn and fill members.
Also, the dbgminiperl.exe is not being LINKED/DEBUG, should it be?
Now I have to use LINK/DEBUG before running the build.
-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: stat() and the NLA0: device.
|
|
|
On Thu, 3 Feb 2005, Craig A. Berry wrote:
| Quote: | At 11:29 AM -0600 2/3/05, John E. Malmberg wrote:
On Wed, 2 Feb 2005, Craig A. Berry wrote:
At 2:41 PM -0600 2/2/05, John E. Malmberg wrote:
With OpenVMS 8.2 and when using the standard compliant stat structure,
the code handling the NULL device is producing the wrong answer.
Go ahead and conditionalize it out when __CRTL_VER is older than the
earliest version you can easily test with or find documented in CRTL
ECOs: 7.2, 7.3, or whatever. If we can move the version number
back at some point, so much the better, but not a priority since the
workaround does work on all pre-8.2 versions as far as I know.
In looking at what it would take to use the standard stat structure in
Perl, the only stumbling block I am seeing is the routine Perl_cando().
With the standard compliant stat, there is no pointer to the device name,
instead a unique 64 bit number for the st_dev member is returned, and
I am currently ignorant of anyway to use that to determine the real device
name as Perl_cando() needs.
Until that is resolved, building Perl with _USE_STD_STAT will not work
right.
Ah, good, we can also conditionalize out the encode_dev() hack, which
has served us well for years but shouldn't be necessary with the new
stat structure if I understand what you are saying. The reason that
Perl_cando() uses the device name from the stat structure is that
lib$fid_to_name returns a device name that may not be up to snuff.
For example, it will return DISK$USER as the device name if the
volume label is USER even if DISK$USER has been overriden by an outer
mode logical. I'm not sure if that helps, and I'm not sure what to
suggest about st_devnam.
|
A partial answer is that a translation of the innermode logical name that
was set up by the mount command can be used to get the real device name.
I will have to look if the existing routines in vms.c can be used to get this.
| Quote: | And with the _LARGEFILE option, mystat might as well use __ino64_t for
the ino_type and not use the rvn and fill members.
Hmm. I'll try to look at that sometime. Is that only when
_USE_STD_STAT is in effect, or regardless?
|
Regardless. Look at the code in stat.h.
| Quote: |
Also, the dbgminiperl.exe is not being LINKED/DEBUG, should it be?
Now I have to use LINK/DEBUG before running the build.
What do you see when you do
$ search config.sh vmsdebug
config_args='-"Dusedevel" -"Dusevmsdebug" -"des"'
usevmsdebug='define'
|
That was a while back and I did not save config.sh file. The code got
compiled /DEBUG, just nothing was linked in debug.
I also discovered that CONFIGURE.COM does not protect itself from
LINK :== link/debug
I am chasing down my next problem now.
@make_ext "Sys$Disk:[]miniperl.exe" "MMS"
Making attrs (dynamic)
Descrip.MMS out-of-date with respect to MAKEFILE.PL, [--.LIB]CONFIG.PM,
[--]CONFIG.H
Cleaning current config before rebuilding Descrip.MMS ...
Rename/NoConfirm Descrip.MMS Descrip.MMS_old
MMS /Descrip=Descrip.MMS_old clean
MCR [--]miniperl.exe "-I[--.lib]" "-I[--.lib]" "-MExtUtils::Command" -e rm_f *.M
ap *.Dmp *.Lis *.cpp *.exe *.obj *.olb *.Opt attrs.bs attrs.bso .MM_Tmp
MCR [--]miniperl.exe "-I[--.lib]" "-I[--.lib]" "-MExtUtils::Command" -e rm_rf
[--.lib.auto.attrs]extralibs.all attrs.c pm_to_blib.ts Makeaperl.MMS perlmain.c
MCR [--]miniperl.exe "-I[--.lib]" "-I[--.lib]" "-MExtUtils::Command" -e rm_rf
[--.lib.auto.attrs]extralibs.ld blib pm_to_blib
MCR [--]miniperl.exe "-I[--.lib]" "-I[--.lib]" Makefile.PL "INST_LIB=[--.lib]"
"
INST_ARCHLIB=[--.lib]" "PERL_CORE=1"
Writing Descrip.MMS for attrs
Descrip.MMS has been rebuilt.
Please run MMS to build the extension.
Skip [--.lib]attrs.pm (unchanged)
MCR [--]miniperl.exe "-I[--.lib]" "-I[--.lib]" -e "use ExtUtils::Mksymlists;"
-e "Mksymlists('NAME' => 'attrs', 'DL_FUNCS' => { }, 'DL_VARS' => [],
'FUNCLIST' => [])"
MCR [--]miniperl.exe -e "print ""[--.lib.auto.attrs]attrs.olb/Include=attrs\n[--
..lib.auto.attrs]attrs.olb/Library\n"";" >>ATTRS.OPT
MCR [--]miniperl.exe -e "print qq{[--]DBGPerlShr.exe/Share\n}" >>ATTRS.OPT
MCR [--]miniperl.exe -e "print qq{[--]DBGPerlShr.exe/Share\n}" >>ATTRS.OPT
Copy/NoConfirm ATTRS.OPT [--.LIB.AUTO.ATTRS]ATTRS.OPT
%MMS-F-GWKNOACTS, Actions to update ATTRS.C are unknown.
%MMS-F-ABORT, For target DYNEXT, CLI returned abort status: %X10EE805C.
Inspecting the resuling DESCRIPT.MMS shows the dependency and the translation
of the MMS macro that are failing:
XSUBPPDEPS = [--.lib.ExtUtils]typemap
attrs.c : $(XSUBPPDEPS)
And it is right, there is no rule for how to build attrs.c if it is missing
or that rule fails.
So not being able to figure out what the problem is, I backed out all the
changes that I have made to 5.8.6 and ran the configure with "-de" option.
As I am typing it, it just stopped at:
$ @BUILD_ROOT:[000000]configure.com "-de"
$mms
MCR Sys$Disk:[]miniperl.exe "-I[.lib]" "-I[.ext.re]" [.lib.extutils]xsubpp -nop
Perl v0.0.0 required--this is only v5.8.6, stopped at [.lib.extutils]xsubpp lin
%SYSTEM-F-ABORT, abort
%MMS-F-ABORT, For target [.EXT.DYNALOADER]DL_VMS.C, CLI returned abort status:
-SYSTEM-F-ABORT, abort
-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:
5.8.6 - %MMS-F-GWKNOACTS, Actions to update ATTRS.C are unknown.
|
|
|
On Thu, 3 Feb 2005, John E. Malmberg wrote:
| Quote: |
I am chasing down my next problem now.
@make_ext "Sys$Disk:[]miniperl.exe" "MMS"
Making attrs (dynamic)
Descrip.MMS out-of-date with respect to MAKEFILE.PL, [--.LIB]CONFIG.PM,
[--]CONFIG.H
Cleaning current config before rebuilding Descrip.MMS ...
Rename/NoConfirm Descrip.MMS Descrip.MMS_old
MMS /Descrip=Descrip.MMS_old clean
MCR [--]miniperl.exe "-I[--.lib]" "-I[--.lib]" "-MExtUtils::Command" -e rm_f *.M
ap *.Dmp *.Lis *.cpp *.exe *.obj *.olb *.Opt attrs.bs attrs.bso .MM_Tmp
MCR [--]miniperl.exe "-I[--.lib]" "-I[--.lib]" "-MExtUtils::Command" -e rm_rf
[--.lib.auto.attrs]extralibs.all attrs.c pm_to_blib.ts Makeaperl.MMS perlmain.c
MCR [--]miniperl.exe "-I[--.lib]" "-I[--.lib]" "-MExtUtils::Command" -e rm_rf
[--.lib.auto.attrs]extralibs.ld blib pm_to_blib
MCR [--]miniperl.exe "-I[--.lib]" "-I[--.lib]" Makefile.PL "INST_LIB=[--.lib]"
"
INST_ARCHLIB=[--.lib]" "PERL_CORE=1"
Writing Descrip.MMS for attrs
Descrip.MMS has been rebuilt.
Please run MMS to build the extension.
Skip [--.lib]attrs.pm (unchanged)
MCR [--]miniperl.exe "-I[--.lib]" "-I[--.lib]" -e "use ExtUtils::Mksymlists;"
-e "Mksymlists('NAME' => 'attrs', 'DL_FUNCS' => { }, 'DL_VARS' => [],
'FUNCLIST' => [])"
MCR [--]miniperl.exe -e "print ""[--.lib.auto.attrs]attrs.olb/Include=attrs\n[--
.lib.auto.attrs]attrs.olb/Library\n"";" >>ATTRS.OPT
MCR [--]miniperl.exe -e "print qq{[--]DBGPerlShr.exe/Share\n}" >>ATTRS.OPT
MCR [--]miniperl.exe -e "print qq{[--]DBGPerlShr.exe/Share\n}" >>ATTRS.OPT
Copy/NoConfirm ATTRS.OPT [--.LIB.AUTO.ATTRS]ATTRS.OPT
%MMS-F-GWKNOACTS, Actions to update ATTRS.C are unknown.
%MMS-F-ABORT, For target DYNEXT, CLI returned abort status: %X10EE805C.
Inspecting the resuling DESCRIPT.MMS shows the dependency and the translation
of the MMS macro that are failing:
XSUBPPDEPS = [--.lib.ExtUtils]typemap
attrs.c : $(XSUBPPDEPS)
And it is right, there is no rule for how to build attrs.c if it is missing
or that rule fails.
So not being able to figure out what the problem is, I backed out all the
changes that I have made to 5.8.6 and ran the configure with "-de" option.
|
I did a $MMS realclean and now I am getting the same build error with all
files from the 5.8.6 kit.
It looks like for some reason either MAKEMAKER is not generating the required
action line, or that the dependency line should really be something like:
attrs.c : attrs.xs $(XSUBPPDEPS)
which there is a rule for. But I am not sure what to do get beyond this point.
-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: 5.8.6 - %MMS-F-GWKNOACTS, Actions to update ATTRS.C are unknown.
|
|
|
Craig A. Berry wrote:
| Quote: | At 3:52 PM -0600 2/3/05, John E. Malmberg wrote:
I'm pretty sure this is an MMS bug. I've never been able to whittle
it down to a really simple reproducer, but removing MMS from the
equation or removing mixed-case filenames from the equation has
always solved the problem. It's probably comparing ".xs" with ".XS"
somewhere, not finding a match, and deciding it doesn't have a rule
to apply.
|
On the todo list for Monday, make a small reproducer and submit a bug
report for MMS.
| Quote: | It looks like for some reason either MAKEMAKER is not generating the required
action line, or that the dependency line should really be something like:
attrs.c : attrs.xs $(XSUBPPDEPS)
That makes it explicit, but the impliicit rule should work.
|
I have always used explicit rules in the .MMS scripts that I write, even
on ODS-2 I have had problems getting some implicit rules to work, so I
gave up trying a long time ago.
| Quote: | Switch to MMK or force your filenames to be all upper case by unpacking your archive like so:
|
Installing MMK is faster than unpacking the archive again.
Has anyone tried using the GNV supplied make to build Perl? The
configure.com script seems to find it.
-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: GNU make & lstat() topic
|
|
|
On Sun, 6 Feb 2005, Craig A. Berry wrote:
| Quote: | At 7:30 PM -0500 2/4/05, John E. Malmberg wrote:
Craig A. Berry wrote:
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.
|
I modified my local copy of the configure.com to accept a "-Dbuilder=make"
so that on the command line I could set the default.
The build failed because [.vms]Makefile.in was not found.
So I am now falling back to MMK.
| Quote: | Perl has been able to use unix syntax file specification for 10 years
or so. If what you mean is the behavior that results from
DECC$FILENAME_UNIX_REPORT, that's a different matter. This is a
really a problem with other packages not handling file specs reported
in VMS syntax. Perl's tendency is that, when in doubt, convert to
native syntax. This was essential for older CRTL versions that often
did not handle unix syntax fully. But reporintg filenames in VMS
syntax will of course cause trouble for other packages that can't
handle that. So yes, there is work to be done in Perl to make it
only report unix syntax filenames.
|
It apparently a case where the perl script output is expected to be used
by an application that does not understand VMS file specifications.
I am going by second hand knowledge here. When I actually try to build
one of these products, I may find out more information.
| Quote: | On my 7.3-1 system:
$ search sys$library:decc$crtl.exe lstat
%SEARCH-I-NOMATCHES, no strings matched
|
Wrong image file, try:
$ search sys$share:decc$shr lstat/format=nonull
| Quote: | I suppose it could be a macro that references decc$stat, though I see
no evidence of that in the header.
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.
We'll have to explicitly test for lstat in configure.com, including
some sort of test that it not only is present in the CRTL but
actually works, i.e., has the underlying OS support.
|
The 8.2 CRTL will do the right thing even if the actual SYMLINK support is
missing, so just a test for 64 bit OpenVMS 8.2 should be all that is needed for
Configure.com.
The only thing that would be significant to test for is if a symbolic link
can be created. I have not looked at what Perl does in that case that is
different than if the symlink() routine is missing.
No need to test for earlier versions, the routines will just return the
same results as if they did not find a symlink for the argument that was
called.
-John
wb8tyw@qsl.net
malmberg@encompasserve.org
Personal Opinion Only |
|
| Back to top |
|
|
Michael G Schwern
*nix forums beginner
Joined: 08 Jul 2005
Posts: 27
|
| Posted: Fri May 27, 2005 4:12 pm Post subject:
Re: Where were we at?
|
|
|
On Tue, Feb 08, 2005 at 07:21:19AM -0600, Craig A. Berry wrote:
| Quote: | I'm of half a mind to just say that having a logical called 'bin' is
likely to break lots of unixy software if it makes "bin/foo" unsafe.
I'm sure there's lots of other places in MakeMaker which use "foo/bar" to
mean "./foo/bar" and something else will just break in the future.
Well, File::Spec->catdir(File::Spec->curdir(), 'bin') seems to always
do the right thing.
|
I'm not going to rework the code so it translates foo/bar into ./foo/bar
everywhere. Doing so in one place just covers up the problem. It will
emerge again.
| Quote: | In fact I'm a little surprised it hasn't. Could you check if it applies
to C<open(F, qq/$ARGV[0]/)> as well? cp_if_diff() is one of the few places
that uses < in open in MakeMaker.
It does apply to other forms of open. I don't think it's shown up
before because it's relatively new to have a test in MakeMaker that
uses 'bin' as a directory name.
|
But having bin as a directory name is very common.
Unless convinced otherwise I'm considering this to be broken Unix->VMS
path translation at the user end. The meaning of open(FILE, "foo/bar")
is pretty clear, it should always be equivalent to open(FILE, "./foo/bar").
Since you can shut off the translation I'd recommend you do so.
And that clears the decks for a release of _08. |
|
| 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:
lstat() and hardlinks start with OpenVMS 7.3-1
|
|
|
| Quote: | On Sun, 6 Feb 2005, Craig A. Berry wrote:
We'll have to explicitly test for lstat in configure.com, including
some sort of test that it not only is present in the CRTL but
actually works, i.e., has the underlying OS support.
|
According to the new features documentation for 7.3-1, link() and the
related routines except for symlink() were implemented and supported.
The link() routine only works on ODS-5 volumes that have been enabled for
hardlinks.
Currently if you build perl with d_link and friends, defined, two perl
modules will attempt use it to create hard links instead of copies on
the build disk in at least two places.
So that would imply that the build disk needs to be ODS-5 and have hard
links enabled.
The only issue with that is that the f$getdvi() call to let you that
information does not seem to have shown up until OpenVMS 8.2.
I have not checked if SYS$GETDVI() will return that information or if
for older versions the output of show device/full would be needed.
Once you get past that, those two perl modules still fail to create the
hard link because they have VMS specific code to append ".com" to the
file they are creating where it is created, but that file extension is
not there when the new name is linked, or a copy made. It appears that
the syscopy module calls an rmscopy module that somehow figures out to try
some extensions.
Those modules are:
Directory BUILD_ROOT:[000000.utils]
c2ph.PL;1 76 10-FEB-2005 13:24:12.81 (RWED,RWED,RE,)
Directory BUILD_ROOT:[000000.x2p]
s2p.PL;1 107 10-FEB-2005 15:22:08.05 (RWED,RWED,RE,)
So in order to get the build to complete, these modules need to be changed
to either always copy on OpenVMS, or use the extension on the link operation.
I have not checked the perl source to see if there are other places hard
links are used where I did not have to make any changes.
symlinks() will be a different issue, and they will likely require POSIX
style filespecifications given to them.
-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: 5.8.6 - test lib/extutils/t/basic can not find mm.pm
|
|
|
On Mon, 28 Feb 2005, Craig Berry wrote:
| Quote: |
On Monday, February 28, 2005, at 02:42PM, John E. Malmberg wrote:
I am trying to chase down some bugs in my last few test builds of perl.
The test [.lib.extutils.t.basic] is failing because:
ok 1 - chdir'd to Big-Dummy
Can't locate ExtUtils/MM.pm in @INC
(@INC contains: BFD_TEST_ROOT:lib ../lib lib) at
lib/MakeMaker/Test/Utils.pm line 249.
As I recently posted, the 5.8.6 MakeMaker test failures were really the
result of a bug in File::Spec (now part of the PathTools distribution).
Don't waste your time on this, it's been fixed. If you are preparing a
custom distribution, I recommend upgrading PathTools from CPAN.
|
Ok, I pulled down the tarball. I just need to replace the files in that
directory tree and do a build for just it?
This looks like a module that I will need to modify to get symbolic links
to work correctly. I need cwd to use realpath() when symbolic links are
to be used or it will give the wrong answer if a when the default as been
set to a directory path via a symbolic link.
Thanks,
-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: BUG: 5.8.6 IEEE float build support incomplete.
|
|
|
On Mon, 28 Feb 2005, Craig Berry wrote:
| Quote: |
On Monday, February 28, 2005, at 02:16PM, John E. Malmberg wrote:
If you chose IEEE float, the build scripts do not set everything needed to
build in IEEE floating point mode.
Yes, they do, but you don't need to choose anything. IEEE is the default
on Alpha (and now Itanium) in Perl 5.8.0 and later. See the section
entitled "Floating Point Considerations" in README.vms.
|
I have looked at it. I also see that I made an error when I merged in
your large file patch, and dropped the $(flags) for a couple of the build
cases.
| Quote: | which will revert to the compiler default. I believe the compiler flags
we add for IEEE are redundant on Itanium, but it's easier to minimize
the number of differences.
|
You will still need /IEEE=DENORM, as that may not be the default.
Ok, that's 2 out of three issues solved.
Thanks,
-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: 24318 warnes on OpenVMS V7.2
|
|
|
On Wed, 27 Apr 2005, Craig A. Berry wrote:
| Quote: | At 12:58 AM -0400 4/27/05, John E. Malmberg wrote:
[only monitoring vmsperl list]
Abe Timmerman wrote:
Hi,
I still can't build bleadperl on the VAX (without /ignore=warning):
CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=GLOBALS.obj/NoList/
Define=PERL_CORE GLOBALS.C
%VCG-W-BADPSECT, The program section(psect) specified by this statement has
conflicting 'nowrite' attributes with another definition
of the same program section.
At line number 1002 in BLDROOT:[000000]PERLAPI.H;1.
That looks like a serious programming error, any idea what is causing it?
It looks like it is saying that the same storage has been declared both as readonly and as writable at the same time.
More specifically, the likely cause would be something declared EXT in
one place and EXTCONST elsewhere, which on VMS means globaldef and
globaldef readonly, respectively. But the error message is less than
helpful in identifying the problem since it points you to the last
line in perlapi.h, well after any declarations. Nothing pops out in
a quick look at Abe's listing file, but I'll try to dig into more
later.
|
Much of the time the line number is set to point to just before the next
line that the compiler sees that generates code or data.
You have to read backwards skipping all non-code or data generating
pre-processor statements.
I am noticing that in 5.8.6, EXTERN.H and INTERN.H have different definitions
for EXTCONST that might produce that type of error message if they got
mixed.
At the moment I can not think of an DECC ANSI acceptable syntax to replace this
usage of globalref/globaldef.
In ANSI mode, I think that specifying the psect name requires a #pragma which
needs to be on it's own line, but I would have to look that up to be sure.
Also, check to see if the symbol "readonly" is being defined to something else,
as I have encountered that as a problem on other open source products.
-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 02:21PM, John E. Malmberg <malmberg@Encompasserve.org> wrote:
| Quote: | 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.
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.
| Quote: | In investigating why the first standard test for symlinks on perl was
failing, it turns out that the fast_abs_path() and abs_path() call VMS
specific code including using rms calls to return the path. This
existing code does not know how to follow a symbolic link to the
real path, and since other code calls those same routines that should
not return a real path, but the link value, a new routine would be needed
for the abs_path routines to use.
Alternatively, symbolic links virtually require UNIX/POSIX path names to
function, which means that they are most likely only to be used in a
full POSIX environment.
It looks like when Perl does not recognize the value of ^O, it defaults
to POSIX/UNIX behavior on file handling.
I have not found out yet how to read or change the value of ^O from C, as
it seems to only be set by config.pm, and I am not sure if config.pm is
used after Perl is built.
If anyone has any suggestions on an easy way to do this, please let me
know.
Thanks,
-John
wb8tyw@qsl.net
Personal Opinion Only
|
|
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Tue Dec 02, 2008 5:24 am | All times are GMT
|
|
Loans | Repair Bad Credit | Free Credit Score | Ringtones | Loans
|
|
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
