| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
In Configure, check whether _NSGetExecutablePath() can be used to find the
absolute pathname of the executable. If so, set usensgetexecutablepath in
config.sh and USE_NSGETEXECUTABLEPATH in config.h. If this is set, then use
this approach in S_set_caret_X() to canonicalise $^X as an absolute
path. This approach works on OS X, and possible on other platforms that
use dyld.
|
|
|
|
|
|
|
|
|
|
| |
In Configure, check whether sysctl() and KERN_PROC_PATHNAME can be used
to find the absolute pathname of the executable. If so, set
usekernprocpathname in config.sh and USE_KERN_PROC_PATHNAME in config.h.
If this is set, then use this approach in S_set_caret_X() to canonicalise
$^X as an absolute path. This approach works on (at least) FreeBSD, and
doesn't rely on the /proc filesystem existing, or /proc/curproc/file being
present.
|
|
|
|
|
| |
The comments in the header itself say that it needs DEC C 6.4 or
later.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SOCKETSHR is/was an interface to abstract out TCP/IP calls for the
various vendors' networking implementations, including the freeware
CMU-IP stack. Neither SOCKETSHR nor CMU-IP has seen any maintenance
for over a decade and are likely not even C89-compliant. The CRTL
socket routines have been supported by the different vendors' stacks
for many years so there is no reason to maintain an alternative, and
there probably hasn't been a real working alternative for some years
anyway.
The code is still there in maint-5.14 and earlier branches if
anyone has need of it.
|
| |
|
| |
|
|
|
|
|
| |
Some bits were missing and others were incompletely renamed back
in 6b356c8efb963846940ef92952cf77e5b86bd65e.
|
|
|
|
|
|
|
|
|
|
| |
Follow-up to adf2bd2837. This is being used for compile-time
comparisons; sizeof may be compile-time, but is apparently not
available before macro substitution, leading to problems like:
....^
%CC-I-IGNOREEXTRA, Spurious token(s) ignored on preprocessor directive line.
at line number 2837 in file MDA0:[SMOKE.blead]pp_sys.c;1
|
|
|
|
| |
Follow-up to dd35fa16610ef2fa0d46f5129e626b99cf350d77.
|
|
|
|
| |
Follow-up to 668fdbe135fd76c7a654bedba52770966925f562.
|
|
|
|
| |
It has been deprecated in 5.14. Now is the time to remove it.
|
| |
|
|
|
|
|
| |
3b28d668e9efe9433c3099521167a6723cbddc26 depended on command-line
specification of usethreads, which of course may not be there.
|
|
|
|
|
|
| |
It's hard-wired in perl.h, so it doesn't make any difference to
what's seen by the C code, but $Config{multiplicity} should reflect
what we're actually doing (and track what Configure does).
|
|
|
|
|
|
|
|
|
|
| |
Now that we have the relevant questions answered before we set
archname, add the appropriate components to archname at the right
time so they'll become part of the architecture-specific
directory names.
FIXME: We don't (yet) set archname64, so at present we're not
adding it to archname.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By moving these to after other questions have been asked, we can
construct a proper $Config{archname} that indicates threads, long
doubles, multiplicity, or anything else that needs to be appended
to the architecture name.
This means letting go of the ability to configure for a different
architecture than the one you're running on, but that feature is
unlikely to have worked very well in recent years anyway as there
have been an increasing number of features that are not available
on all architectures.
|
|
|
|
|
|
|
|
|
| |
We were only using the base archname (e.g., "VMS_AXP"), which is
ok for a default bulid, but if any additions were made to it,
such as "-thread", there would be a discrepancy between the
actual directory on disk and what perl.c:S_incpush would look for
when loading up @INC. The net effect was that the architecture-
specific directory would not get loaded into @INC.
|
|
|
|
|
|
|
| |
Instead of testing for equality, look for the first minus sign-
delimited element. This means it won't matter which order these
checks are done in relation to adding things like "-thread-multi"
to archname.
|
|
|
|
|
| |
It's present on recent versions, but not all versions. Follow-up
to f53580fec42f3b12264ee27b756dec257c0bb77a.
|
| |
|
|
|
|
|
| |
It's available on anything decent and recent, but it requires
_SOCKADDR_LEN defined to make it visible.
|
|
|
|
| |
Sorry for the huge config_h.SH re-order. Don't know (yet) what caused that
|
|
|
|
|
|
|
|
|
|
|
| |
[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.
|
|
|
|
|
|
|
|
|
| |
It used to be that once or twice per decade a symbol longer than
31 characters snuck into the core and we had to manually shorten
it to get the build working. But it's happened twice in the last
month, most recently with the humanly unswallowable function name
XS_XS__APItest__XSUB_XS_VERSION_undef, so the need for a more
general solution has become not only apparent but mandatory.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Traditionally Perl does its own name shortening in
ExtUtils::XSSymSet to get around the 31-character limit
on symbol names in the VMS linker. That method predates
the availability of the /NAMES=SHORTENED option in the
C compiler, which uses the same algorithm as the C++
name mangler to produce shortened symbols. This change
makes configuration with -Duseshortenedsymbols select
the compiler's shortening over the home-grown shortening.
The advantages of the compiler option over the home-grown
option are that hand-coded long symbols in the core can be
handled (instead of only generated XS_... symbols); long
symbols in external libraries can be handled; and eventually
we can remove XSSymSet and have less to maintain.
84efe3dfc6afbd8ea017ddcc4d5d213cc1a35c72 is required to travel
wherever this change travels for extension building to work
properly.
|
|
|
|
|
| |
This assumes all VMS compilers that build perl will
support 'static inline'.
|
|
|
|
|
| |
Formerly it only worked if you went through all the questions
interactively and explicitly answered no.
|
|
|
|
|
|
| |
DCL symbol length was limited to 1K up until about seven years or
so ago, but there was no particularly deep reason to prevent those
older systems from configuring and building Perl.
|
|
|
|
| |
This was missing from c796e3db23c597b99f07485542338844e61a6a69
|
|
|
|
|
| |
Follow-up to d03b3b00ac22f32af87a752669a46d9d06ae1561, which broke
the build.
|
|
|
|
|
|
|
| |
Like it has been everywhere else for ages and ages. Also make
command-line selection of -UDEBUGGING and -DDEBUGGING work in
configure.com; before the only way to turn it off was by saying
no in answer to the interactive question.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Thanks to Carl Friedberg for the suggestion.
|
| |
|
|
|
|
| |
Needs checking
|
|
|
|
| |
accordingly.
|
| |
|
|
|
|
| |
But thanks for 7 1/2 years of faithful service.
|
|
|
|
|
|
|
| |
Revised slightly and the effects of dash versus slash changed in the
list of exclusions.
Message-ID: <20090206211641.GA39741@plum.flirble.org>
|
| |
|
| |
|
|
|
|
| |
Partially based on suggestions from John Malmberg at <495C279C.7020106@gmail.com>.
|
|
|
|
|
|
| |
From: "Rafael Garcia-Suarez" <rgarciasuarez@gmail.com>
Message-ID: <b77c1dce0812030351j33d7b75ci3e2640b33f36acd9@mail.gmail.com>
p4raw-id: //depot/perl@34994
|
|
|
| |
p4raw-id: //depot/perl@34952
|
|
|
|
|
|
|
|
|
|
|
|
| |
From: Nicholas Clark <nick@ccl4.org>
Date: Thu, 27 Nov 2008 20:28:08 +0000
Message-ID: <20081127202807.GG49335@plum.flirble.org>
Subject: Avoid duplicate vendorlib [PATCH]
From: Gisle Aas <gisle@activestate.com>
Date: Wed, 12 Nov 2008 13:50:34 +0100
Message-Id: <71B06786-4C55-4A76-BE24-C01F89015D45@activestate.com>
p4raw-id: //depot/perl@34950
|