| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
usedtrace builds add references to libelf symbols, causing link
failures without it.
at hints time we don't know if the user will interactively select
dtrace and there's no CBU, so it's added unconditionally on 10.x
|
| | |
|
| | |
|
| |
|
|
|
| |
but instead require an extra option -Ddarwin_distribution to produce
the same results.
|
| |
|
|
| |
Linux has used ELF for over twenty years.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
(a) This enables the malloc wrap also on Hurd, as used on Linux
already; Perl's own test suite passed with it, and I see no reason to
diverge from the behaviour on Linux and kFreeBSD. I'm not sure whether
it affects the ABI though, so it might be safe only for the upcoming
perl 5.24 in experimental (since that breaks the ABI anyway)
(b) This improves the reporting of the GNU libc used, so it's shown in
`perl -V` (as libc value, instead of the currently empty string).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main failure appears to be a bug in freebsd. Jim Keenan and I have
created a stand-alone C program, not involving Perl, that reproduces it,
which I will attach to the ticket. I have searched their bug db and not
found this reported, so will create a ticket against them.
Several of the failures are bugs in some of the locale definitions for
freebsd, like not all lowercase letters also being alphas. I will
report these as well, and adjust the allowable failure percentage for
this platform, if necessary, to get these to not fail the test at large.
The bug is that newlocale() and/or uselocale() are not working properly.
These are from POSIX 2008, and perl has not used them previously.
I sort of expected some platforms to have not implemented them properly;
this is the first one we've encountered that does so.
This changes the hints file so that it appears that uselocale() is not
on the system.
|
| |
|
|
| |
(including regen/opcode.pl)
|
| | |
|
| |
|
|
|
|
| |
For: RT #128279
Patch written by Samuel Thibault, forwarded by Dominic Hargreaves.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This appears to be a typo that has been with us since 69625aa92a9
and the real name is MACOSX_DEPLOYMENT_TARGET.
So do the same thing the MacPorts folks have been doing, meaning
this is just the "fix-ld-modification.patch" from:
https://trac.macports.org/browser/trunk/dports/lang/perl5/files/5.24?rev=148407
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(preparing for the next change)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On threaded builds on OS X, libSystem registers atfork handlers that
call setenv(), which internally modifies members of environ[], setting
them to malloc()ed blocks.
In some cases Perl_my_setenv() reallocates environ[] using
safesysmalloc(), which under debugging builds adds a tracking header,
and if perl_destruct() sees that environ[] has been reallocated, frees
it with safesysfree().
When these combine, perl attempts to free the malloc()ed block with
safesysfree(), which attempts to access the tracking header, causing
an invalid access in tools like valgrind, or a "free from wrong pool"
error, since the header contains unrelated data.
Avoid this mess by letting libc manage environ[] if unsetenv() is
available.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Symptom of failure: in openindiana "make" fails:
...
./perl -Ilib -f pod/buildtoc -q
Can't load 'lib/auto/re/re.so' for module re: ld.so.1: perl: fatal:
relocation error: file lib/auto/re/re.so: symbol PL_localizing:
referenced symbol not found at lib/XSLoader.pm line 71.
at lib/re.pm line 88.
...
Running the above command with 'env LD_DEBUG=files ...' shows that
there are many other symbol lookup failures, the one above is just
the last one before bailing.
If configured explicitly with -Duseshrplib, openindiana build succeeds.
Curiously, while the hints/solaris_2.sh (which openindiana uses) does
not specify useshrplib, Oracle/Sun builds/has been building their perl
with useshrplib since Perl 5.6.1 or thereabouts (source: Alan Burlison).
Using shared libraries is strongly recommended in Solaris in general
(source: the same).
Tested in:
- Solaris 5.10/i386 with solstudio 12.2 and gcc 4.8.0
- Solaris 5.10/sparc with solarisstudio 12.3 and gcc 4.9.2
- OpenIndiana 5.11/i386 with solarisstudio 12.3 and gcc 4.5.0
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit 821805a244cacd9869331999cd53407f3323206a.
What's out, is out.
perl #107904 Filesys-Df
perl #108189 Filesys-DfPortable
perl #108191 Filesys-Statvfs
perl #126368 Filesys-DfPortable
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note the difference between the OS X version (10.X) and the kernel version,
it's the latter that Configure knows as $osvers. Adding a cross-reference
table for these versions rom the NetBSD project.
For OS X 10.6 or above, do not any more use the MACOSX_DEPLOYMENT_TARGET,
the toolchains should work fine without. Until now the deployment target
was hardwired to 10.3. This logic comes from
https://rt.perl.org/Public/Bug/Display.html?id=117433
For OS X releases from 10.3 until 10.5, no change, still using
the MACOSX_DEPLOYMENT_TARGET=10.3 for linking.
For OS X releases before 10.3, no change, still not using
the MACOSX_DEPLOYMENT_TARGET=10.3.
New: always add -mmacosx-version-min to ccflags and ldflags from
the env var $MACOSX_DEPLOYMENT_TARGET, if set. If the var is not set,
set the min from the OS X version, from sw_vers(1). Setting the var
should become handy for people building and packaging Perl for earlier
OS X versions.
We assume that the toolchain/SDK installed to system will be able to build
for the requested minimum versions and deployment targets, or if it is not,
it should properly warn or die.
Some related tickets, past and present:
https://rt.perl.org/Public/Bug/Display.html?id=126360
https://rt.perl.org/Public/Bug/Display.html?id=123985
https://rt.perl.org/Public/Bug/Display.html?id=123831
https://rt.perl.org/Public/Bug/Display.html?id=117433
|
| |
|
|
|
| |
It exists, but the API is something completely different,
so the compilation attempt ends up in a fireworks display.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
d_fs_data_s HAS_STRUCT_FS_DATA
d_fstatfs HAS_FSTATFS
d_fstatvfs HAS_FSTATVFS
d_getfsstat HAS_GETFSSTAT
d_getmnt HAS_GETMNT
d_getmntent HAS_GETMNTENT
d_hasmntopt HAS_HASMNTOPT
d_statfs_f_flags HAS_STRUCT_STATFS_F_FLAGS
d_statfs_s HAS_STRUCT_STATFS
d_ustat HAS_USTAT
i_mntent I_MNTENT
i_sysmount I_SYS_MOUNT
i_sysstatfs I_SYS_STATFS
i_sysstatvfs I_SYS_STATVFS
i_sysvfs I_SYS_VFS
i_ustat I_USTAT
Unused by the Perl core.
As far as I can remember I added these scans long ago, for some
purpose (df(1) kind of APIs?) but whatever it was, it obviously
hasn't exactly caught fire in the last 15 years.
Some rare uses of these APIs (not these defines, but e.g. statfs)
in CPAN (like the Quota module), but those seem to do their own
configuration.
|
| | |
|
| |
|
|
| |
Makes build process simpler.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
