This is the first major release of FreePascal in nearly four years.
There are a ton of new features, way more to list here. see:
http://wiki.freepascal.org/FPC_New_Features_3.0
Several new unit ports were added, some were contracted. Most of
those were absorbed into the main FPC packages, but two units are
no longer supported: sndfile and matroshka.
All 99 remaining ports (including Lazarus ports) were build tested
on FreeBSD i386 and amd64 Release 10.2
Similar to lang/gnatdroid-armv7, lang/gnatdroid-x86 is a cross-compiler
targetting Android. The former targets ARMv7 processors while the latter
targets Android on x86 (32-bit). The latter also runs on Virtualbox as
a bonus. The new ports are implemented as slaves to the ARMv7 versions.
The GNAT ACATS were run, and it passed every test except CXG2024,
"accuracy of multiplication and division of mixed decimal and binary
fixed point numbers".
subtest 13: expected -51.00 got 50.0
subtest 14: expected 51.0 got 50.0
This is probably a rounding error unique to 32-bit x86. Overall this
version passed better than gnatdroid-armv7 because unwind is supported,
enabling check check support.
Also added:
lang/gnatdroid-sysroot-x86 (KitKat and Lollipop API)
lang/gnatdroid-binutils-x86
Despite the desciption, C++, Fortran and Objective-C should also work
well (in addition to advertised C and Ada frontends).
===
The gnatdroid-x86 port builds a C/Ada cross-compiler based on GCC 4.9
that targets the Android operating system (up to version 5.0, API level
21) running on x86 or x86_64 architecture (version 7). This produces
binaries that run natively on x86-based Android devices.
to the versioned executable (gfortran48, gcc48, and g++48).
These standard names are going to remain in place in case of version
upgrades and constitute the default, and expected by users, names.
Suggested by: db
Reviewed by: db
This change is the same as r400632, which updated gcc[56]-devel, but now
for gcc{,48,49,5}. This change is the second attempt at doing this: the
first attempt went in r401072 and was reverted in r401074 because the diff
was bogus and enabled the new MULTILIB option under all platforms instead
of just powerpc64.
This fixes the build of gcc{,48,49,5} under powerpc64 when the system
is built without the lib32 libraries.
More in detail:
If the system is built with lib32 support (WITH_LIB32, which is the default),
building gcc from ports results in a compiler that can target both 64-bit and
32-bit binaries on powerpc64. However, when lib32 support is disabled
(WITHOUT_LIB32), gcc should only be built with 64-bit support or otherwise
the build fails.
To fix this, explicitly disable 32-bit support when /usr/lib32 is not present
and add a MULTILIB option (which is only defined for powerpc64 when 32-bit
support is possible and defaults to yes to preserve the current behavior) to
allow the user to explicitly control this feature.
Approved by: gerald (maintainer), bdrewery (mentor), andreast
Differential Revision: https://reviews.freebsd.org/D3952
- update to 2.7.0
- change MASTER_SITES to use https and modern mirror as suggested by [1]
- Jython uses two licenses, indicate that in the port. Extract the licenses from
the jar earlier so ports framework can find them
- the port complains when trying to build with openjdk6, so set JAVA_VERSION
to 1.7+
- mark NO_ARCH
- null the PATH for installer invocation. If installer finds python2.7 in PATH
it installs python wrapper script instead of bash one. [2]
- exclude "ensurepip" module from the installation as it doesn't build on FreeBSD
- change kinda dirty and not obvious replacement of "-cl"(asspath) to addition
to JAVA_OPTS. This hack is needed to place jython cachedir into user's home
directory, as it needs to be writable by the user invoking jython
- write comments to not obvious parts of the installation
- wrapper script is now placed in bin/ directory in JYTHON_PREFIX rather then
in root, fix that
- Jython uses *$py.class files as an analog for *.pyc ones in plain Python,
installer puts pre-compiled *$py.class files into the STAGEDIR. We need to
recompile that because, after installation:
1) If we invoke Jython as user - it can't use the *$py.class files as they
have different source path inside, slowing down the startup;
2) If we invoke jython as root - it will recompile the *$py.class files
breaking the de-installation process of the package. Compilation phase
always have non-portrelated errors, so we need to ignore it's exit code
- Don't ignore the exit code of symlink installation as we don't expect that to fail
[1] https://central.maven.org/
[2] https://hg.python.org/jython/file/tip/installer/src/java/org/python/util/install/StartScriptGenerator.java#l22
PR: 204231
Submitted by: Sergey Kozlov <kozlov.sergey.404@gmail.com>
non-default Python versions:
- Add pyXY-{sqlite3,gdbm,tkinter} ports for generating binary packages
- Improve/add pkg-message to point users to install respective packages of
separated Python standard modules
- Add COMMENT to explicitly show the Python version that package should be
used with
- Simplify version-related PYTHON_* for lang/python35
Reviewed by: koobs
Differential Revision: https://reviews.freebsd.org/D4170
The upstream distfile was changed. Most of the changes were regenerated
documentation, but a build file (gpr) was also updated. The changes are
legitimate (but should have been provided r4)
Introduce DIST_SUBDIR now that adacontrol joined the reroll club.
