| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Brought to you by -Duser_c_flags=/WARN=(ENABLE=LEVEL5,INFORMATIONAL=ALL)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Follow-up to fbcaf61123069fe46010699dd41ca5f60f448361 at Nicholas's
suggestion.
|
| | |
|
| | |
|
| |
|
|
|
| |
Only the one copied as part of the build should be removed in the
clean target. TODO: buildtoc is probably busted.
|
| |
|
|
|
|
|
|
|
|
|
| |
[DELTA]
* important changes in version 1.70 15/11/2010
- Add ptargrep utility courtesy of Grant McLean
** I think I found everywhere that needed updating
by grepping for 'ptardiff' and adding where needed.
This stuff is definitively not intuitive.
|
| |
|
|
|
|
| |
I noticed two dubious expressions that look as if they were
intended to be assignments. The comment above the code says
it's broken.
|
| |
|
|
|
|
|
|
|
|
|
| |
pp_reach, pp_rvalues, and pp_transr are aliases, but regen/opcode.pl
generates declarations for aliases as if they were C functions in
their own right. This is necessary for aliases that refer to mathoms
(as most of them do) but seems less right for new entries that will
never refer to an actual function of the same name. For now, these
need to be explicitly excluded when building the linker options file
on VMS. Failure to do so breaks the build with undefined symbol
warnings.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
For the first time we now have a symbol longer than 31 characters
in the API, not just internally or generated in xsubs. That means
we have to provide the shortened name in the linker options file
used to produce the shareable image, but the documentation on the
CRC used to produce the short name is incomplete. For a more
general solution, we may have to root through the demangler
database or parse the output of CC/WARN=ENABLE=NAMESHORTENED.
|
| | |
|
| | |
|
| |
|
|
|
| |
Let ExtUtils::MakeMaker deal with running these extraction scripts, rather than
repeating the logic in (at least) 5 places.
|
| |
|
|
|
| |
Let ExtUtils::MakeMaker deal with running these extraction scripts, rather than
repeating the logic in (at least) 5 places.
|
| |
|
|
|
| |
Let ExtUtils::MakeMaker deal with running these extraction scripts, rather than
repeating the logic in (at least) 5 places.
|
| |
|
|
|
| |
Let ExtUtils::MakeMaker deal with running this extraction script, rather than
repeating the logic in (at least) 5 places.
|
| |
|
|
|
|
|
|
| |
Suggested by Father Chrysostomos in:
[perl #77500] VMS::Filespec and PVLV globs
Affected routines are candelete_fromperl and rmscopy_from_perl.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The excluded routines are aliases, and while there are a lot of
aliases, most of them also exist in mathoms.c so there are actual
symbols to link against. These don't and aren't.
Before a4e744802906bbf8435494e7f5ab1823213b2448, there were quite
a few Perl_pp_xxx and Perl_ck_xxx symbols that were not getting
collected here.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Make embed.pl fully responsible for generating prototypes and embedding macros
for pp_* and ck_* functions, placing them in embed.h and proto.h
opcode.pl no longer generates pp_proto.h
Remove the (effectively) duplicate explicit entries for (all but 2) ck_*
functions from embed.fnc
We can't actually remove pp_proto.h from the distribution *yet*, as
ExtUtils::MM_Unix and ExtUtils::MM_VMS have hardcoded lists of the installed
headers. Once this is resolved, we can.
|
| |
|
|
|
| |
Since only the current one is copied from perldelta.pod, deleting
the previous one makes it disappear completely.
|
| |
|
|
|
|
|
|
| |
my_setenv, do_spawn, and do_aspawn are already in embed.h, though
they probably weren't when these were originally put in vmsish.h.
This change is a required follow-up to e64ca59f2852bc5d0450eea5ed412609a046829d;
without it the macro definitions differ in the non-multiplicity case.
|
| | |
|
| |
|
|
|
|
| |
uudmap.h is created first, so bitcount.h should depend on it
rather than vice versa. Correcting this avoids unnecessary
recompiles of globals.c.
|
| | |
|
| |
|
|
|
| |
This way patches including perldelta entries will apply properly, no matter when
they are applied. If there's conflicts, they'll at least be in the right file.
|
| |
|
|
|
| |
Follow-up to 6999193ba9069e620831bed0f85efa43ff6e283a, which broke
the build on VMS because the rule to build uudmap.h was unknown.
|
| |
|
|
|
| |
The fixes of Makefile.SH in 0f13ebd5d71f8177 also need to be applied on Win32
and VMS.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When porting/makerel runs, all files copied into the directory for the
tarball have the executable bit stripped and then only a specific set of
files have the executable bit restored.
There are many files in the repo that have the executable bit set in the
repo that will be stripped. So that the state of files in the repo is
as close as possible to the state of files in the release tarball, the
executable bit has been stripped from such files.
In one recent case, a file added from a dual-life module needed the
executable bit set. Because it had the bit in the repo but was
not listed in makerel to get an executable bit, tests using it
passed in the repo and failed in the tarball.
This commit refactors the list into a new file, Porting/exec-bit.txt
and add tests to detect a mismatch between files listed there
and actual executable bits in the repo.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
In Perl_rename() we were allocating the same thing twice.
In vms_fid_to_name() (used by realpath() and realname()), we had
another flagrant omission of freeing local storage.
|
| |
|
|
|
|
|
|
| |
Thanks to Mark Berryman in
Message-id: <52BFD39B-C4BA-4350-AA1F-C2E7F128EF21@theberrymans.com>
for the report and the fix.
|
| | |
|
| |
|
|
|
| |
Cherry picking this from 5.12.1 would lose all the 5.13.X additions, so
these edits have been made by hand.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The prototypes removed here, while in some ways superior to those
provided in the system-supplied headers, in other ways conflict
with them. The conflicts were masked in the default build by the
fact that the macros mapping lower case names to upper case were
undefined, so at compile time there were really two different
prototypes even though at link time the symbols were the same.
But the conflict broke the build when compiling with /NAMES=AS_IS
to preserve symbol name case. Overall, whatever modest benefit
maintaining our own prototypes might provide, it's just not worth
the risk of conflict. A better approach would be to define
__NEW_STARLET and work through whatever the compiler complains
about.
For sys$sigprc and lib$initialize, we do continue to provide our
own prototypes (and add lower case to upper case mapping macros)
because there are no system-supplied prototypes for them.
|
| |
|
|
|
| |
This was an oversight in 5.12.0 and without it some extension builds
fail.
|
| | |
|
| | |
|
| |
|
|
|
| |
We were checking a variable that doesn't exist in the non-default
case of disabling perlio. Now we only look at it when it exists.
|
| | |
|
| | |
|
| |
|
|
| |
Thanks to Ask for pointing it out.
|
| | |
|
