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.
This port was establishing WRKDIR over bpm. The reason why wasn't good;
There is a home-grown pattern replacement in the port. I replaced the
custom sed command with REINPLACE_CMD as minimally as I could, and then
removed the WRKDIR redefinition.
Approved by: just fix it
During the conversion to use option handlers, I found a couple of
typos and obsolete code which caused errors. I also switched to
USES+= readline libedit when their options were selected.
The previous depends declaration for libedit was incorrect. It had a
".so" prefix instead of ".so.0" prefix meaning that the requirement
would have been satisfied by system libedit. For this reason, converting
to USES=libedit requires a bump.
Approved by: infrastructure modernization
I'm not sure what happened exactly but I think I committed the change from
the wrong client. The applied change enabled the MULTILIB option for all
architectures and not only powerpc64. Let's just revert the commit and do
it properly from scratch; other things might be wrong so I wanna take a
closer look, and it's best to just revert quickly.
This change is the same as r400632, which updated gcc[56]-devel, but now
for gcc{,48,49,5}. Waited a week to ensure the change caused nothing to go
horribly wrong but this change is very low risk because it only affects
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
- Provide target for 'make test': Use bundled rust regression test suite
- Use bundled LLVM for now: Built with it, rust passes more regression tests
- Bump PORTREVISION
Fix readline & libedit configure options after a slight error slipped in
with the patches done in r400142.
PR: 203988
Submitted by: John Hein <z7dr6ut7gs@snkmail.com>
This fixes the build of gcc[56]-devel 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
When I added the first copy of the CloudABI toolchain to the Ports tree,
I assumed that it would be easily possible to have a single Binutils
port that would support all of the architectures of interest. It seems
that this is not really supported, or simply awkward to use.
Let's just rename the cloudabi-binutils port to cloudabi-binutils-x86_64
and add an additional cloudabi-binutils-aarch64.
Reviewed by: emaste
Approved by: bapt
Differential Revision: https://reviews.freebsd.org/D3919
The code lacks support for PowerPC and PowerPC64 and it does not seem
trivial to add such missing pieces. In particular, the MacroAssembler
is not implemented.
Approved by: koobs (maintainer), bdrewery (mentor)
Differential Revision: https://reviews.freebsd.org/D3957
The latest Android Native Development Kit (NDK) has API Level 21
in it (but not 20, nor 22 or the latest Level 23). Add this option
to gnatdroid's sysroot port, and change the default API from Jelly Bean 1
(Level 16) to Kitkat (Level 19).
Bump gnatdroid's binutils and gnatdroid itself as a consequence of this
default change. A new patch had to be added to lang/gcc-aux to handle
the CTYPE changes which haven't made to GCC yet.
Gnatdroid has been testing for building on all API's but not for
functionality beyond Level 16 due to lack of hardware. I may soon
install an Android emulator to see if that will suffice.
- Support multiple values in *_OLD_CMD, i.e. we can now fix both "/usr/bin/python" and "/usr/bin/env python" at the same time
- Default *_OLD_CMD values are now always appended, so you don't need to specify them in individual ports
- Add lua support (depends on USES=lua)
- Add more default values, such as "/usr/bin/env foo" for python, perl, bash, ruby and lua
- Shebangfix now matches whole words, e.g. we will no longer (erroneously) replace "/usr/bin/perl5.005" with "${perl_CMD}5.005" (but "/usr/bin/perl -tt" is still (correctly) replaced with "${perl_CMD} -tt")
Note that *_OLD_CMD items containing spaces must now be quoted (e.g. perl_OLD_CMD=/bin/perl /usr/bin/perl "/usr/bin/env perl")
Update shebangfix usage according to new rules in many ports:
- Remove *_OLD_CMD for patterns now replaced by default
- Quote custom *_OLD_CMD which contain spaces
Fix shebangfix usage in many ports (irrelevant to infrastructure change):
- Remove redundant SHEBANG_LANG (no need to duplicate default langs)
- Remove redundant *_CMD (such as python_CMD=${LOCALBASE}/bin/python${PYTHON_VER} when USES=python is present)
- Never use *_OLD_CMD in REINPLACE_CMD matchers, these should always look for exact string
Approved by: portmgr (bapt)
Differential Revision: D3756
In Python 3.4+, upstream added and switched to using a shell
implementation of the python-config script [1]. The Python
implementation (python-config.py) remained used by all versions < 3.4.
While the shell implementation returns the path to the Python
shared library when using the --ldflags script argument, the Python
implementation of the script does not. The bug has been reported, but
has not yet been merged [2].
The Python ports currently default to including ${LOCALBASE}/lib
in LIBS when the NLS option is enabled (which it is by default).
When built *with* NLS (gettext) support, the flags added to LIBS
are returned in `pythonX.Y-config --ldflags` output, which happens
to match the path to the Python shared library.
If the NLS option is disabled, ${LOCALBASE}/lib is not added to LIBS,
and are therefore not returned in --ldflags output.
This results in potential linking errors for software that uses
python-config to obtain the correct library path, when the NLS option is
disabled:
$ make WITH=PYTHON -C audio/alsa-lib
[...]
--- smixer-python.la ---
CCLD smixer-python.la
/usr/bin/ld: cannot find -lpython2.7
This change modifies the python-config.in script to match the shell
implementation, outputting the library path in --ldflags output.
While I'm here:
for Python 3.2 and Python 3.3 ports, backport a library order
change [3]. This could affect linking with static libraries.
Use standard length lines and reduce diffs in pkg-message
[1] https://bugs.python.org/issue16235
[2] https://bugs.python.org/issue7352
[2] https://bugs.python.org/issue18096
PR: 197757
Submitted by: jbeich
MFH: 2015Q4
- New EXECLINE_BLOCK_END_STRING and EXECLINE_BLOCK_QUOTE_STRING macros
- New command: withstdinas. It's a simplification of backtick, which
is now implemented as a combination of pipeline and withstdinas.
- Other new command: getcwd.
PR: 203789
Submitted by: Colin Booth <colin@heliocat.net> (maintainer)
Now that CloudABI has been ported over to aarch64, let's extend the
FreeBSD ports to install a functioning toolchain for it.
This change extend the llvm37 port to backport a tiny change that is
needed to make Clang support the CloudABI for aarch64 target (r250416).
This change makes Clang use the right ELFOSABI number, but also makes it
set the right #defines (e.g., __CloudABI__).
It also extends the cloudabi-clang port to set up symlinks against Clang
for aarch64.
Submitted by: ed
Differential Revision: https://reviews.freebsd.org/D3906
On FreeBSD9, libEGL is built by GCC which requires binutils as a run
depends. fpc-cairo requires libEGL. fpc-libbfd and binutils conflict
with each other due to both installing the same header. Thus, on
FreeBSD 9, the BFD and CAIRO options cannot coexist. Since both were
set on by default, no binary package for fpc-units has built for months.
Since there is no mechanism to set options by release, I use bmake's
exist() function to check for /usr/include/lwres which only exists on
FreeBSD 9. If it's present, the BFD option is disabled by default. This
should restore the building of the fpc-units package on FreeBSD 9.
Reported by: pkg-fallout (for months)
* Unbreak build on powerpc and other !x86 archs by moving the
--with-dri-drivers logic from dri/Makefile to the
libGL/Makefile.common file. So the settings are applied to all mesa ports,
this was missed in the 10.6.6 update. [1]
* Don't try to enable OpenCL support on anything other then i386 and amd64. [1]
* Move the texture-float and vdpau logic to Makefile.common even if the latter
isn't supported yet. Keep OPTIONS_DEFINE/DEFAULT in dri/Makefile since they
need to defined before bsd.port.options.mk is included, and they only affect
the dri modules.
* Sed on 11 and 10 supports \< and \> however sed on 9.x and dragonfly do not,
replace the sed keywords with some magic to get the intended results. [2]
Submitted by: marino@ [2]
Reported and tested by: arved@ (on ppc32)[1]
because that ends up lowering optimization for most people (from -O2).
Approved by: maintainer
(The upgrade is too minor to justify revision bumping of depending ports.)
- Switch to using pkg-plist rather than automatically generate it
(it is easy enough to maintain).
- Switch to modern option helpers.
- Set DIST_SUBDIR due to version-less Docs.zip file.
libc++ on 10.1-R is too old for beignet to build, however beignet builds
fine on 10.2-R. Since 10.1-R is use for building packages, this doesn't
change the fact that there is no freebsd supplied package sadly.
With the deprecation of Google Code and Apache Extras, the code has moved to
github.
- use Github
- use a newer snapshot that sets the target to Java 1.5 (should be more
compatible with newer Java). Bump port revision accordingly
- add the "Beanshell" name to COMMENT, since PORTNAME is not clear
- pass maintainership to submitter
PR: 203354
Submitted by: pfg
on PowerPC (verified for all of them) and some also on SPARC (whenever I
was able to test those on flame.freebsd.org) and even IA64 (which should
be OK to remove anyways, because it was never really supported system in
ports land and was officially killed in -CURRENT a while ago.
Some ports were already installing in the System domain, for these just remove the Makefile lines explicitly specifying the install domain.
The rest are installed in the Local domain, remove any overrides, update their pkg-plists and any explicit paths in the Makefiles and then bump port revision.
Approved by: bapt (mentor)
Differential Revision: https://reviews.freebsd.org/D2977
Add beignet 1.1.0.
Add clinfo, clblas, clfft and clrng.
The major change is that all Mesa ports are now configured the same way.
This fixes several problems and enables new features. The details
are described in this blog post:
http://blogs.freebsdish.org/graphics/2015/03/18/unifying-mesa-ports-configure/
The second important change is the OpenCL support. Mesa's
implementation, Clover, is enabled as well as Beignet. Clover
targets all Gallium drivers, only Radeon GPUs in our case. Beignet
is for Intel GPUs starting with Ivy Bridge. Thanks to Johannes
Dieterich, O. Hartman, and Koop Mast for their work on OpenCL! As a
bonus, there are several OpenCL-based math ports added (clblas,
clfft and clrng). For more information and known issues, please see
https://wiki.freebsd.org/Graphics/OpenCL
The third change is the removal of Mesa 9.1.7 which was installed on
FreeBSD 9.3-RELEASE. There is now only one version of Mesa in the Ports
tree (10.6.6) for all supported versions of FreeBSD.
Other, smaller changes:
* Include libosmesa into the Mesa framework; this changes libOSMesa
shlib version.
* bsd.mesalib.mk was renamed and split up in two files namely
Makefile.common and Makefile.targets. So ports can overwrite variables
set by Makefile.common and are used by Makefile.targets.
* Some text in the pkg-descr files was wrong, clean it up. While here,
update the WWW to the main mesa3d.org upstream page.
* devel/clinfo was added, a glxinfo like program but for OpenCL.
Non-x86 hardware reports are very welcome since we changed the framework
quite a bit.
Obtained from: Graphics team development repo.
All applications in the ports tree works correctly with unicode version of wxGTK
Newer version of wxGTK are unicode only (3.0+)
Note that now WX_UNICODE macro is noop
Patches must not be changed by the vcs, this includes the
svn:keyword expansion. Set fbsd:nokeywords to a couple of patches.
With hat: portmgr
Sponsored by: Absolight
Patches aren't supposed to have $FreeBSD$ tags anymore. The
fbsd:nokeywords property was properly set, so the $FreeBSD$ tag was not
even expanded, so these tags were removed. Note that the mini-exceptions
patch is no longer needed. According to the comments, it's is for
FreeBSD 8 support only.
Approved by: portmgr (mat)
- Move Perl's man1 files along with its man3 files.
- Move where Perl installs its modules man1 pages.
- Convert the ports installing man1 pages.
- Make different Perl versions installable at the same time.
Though you should note that only the default version can be used to
install Perl modules, and the non default Perl versions cannot use the
modules installed via ports if they contain .so as they are installed
in a version specific directory.
Reviewed by: bapt (the Mk bits)
Exp-run by: antoine
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D3542
A newer version of Rust fails to build if an older version is installed
because the build process picks libraries in %%LOCALBASE%%/lib before
those from the build directory.
In the pkg-plist of both ports, `x86_64-unknown-freebsd` is now a
variable automatically set in the Makefile. This avoids the need for a
separate port for DragonFlyBSD. [1]
Still in the pkg-plist, RUST_VSN_HASH is automatically computed in the
lang/rust's Makefile, like it was already done for lang/rust-nightly.
lang/rust-nightly USES libedit. patch-mk_main.mk was copied from
lang/rust so the correct library is picked (ie. the one from Ports, not
the one from the base). This was already fixed in lang/rust.
lang/rust includes bsd.port.options.mk and bsd.port.mk, instead of
bsd.port.pre.mk and bsd.port.post.mk. This was already fixed in
lang/rust-nightly.
Both ports are now closer to each other.
PR: 202869 [1]
Submitted by: Michael Neumann <mneumann@ntecs.de> [1]
Reviewed by: kwm
Approved by: kwm
Differential Revision: https://reviews.freebsd.org/D3234
correct: REGINA_BITS macro is set by configure script (for known systems,
but passed to the compiler unconditionally even if empty) and checked and
set in `rexx.h' as well if defined(__APPLE__) && defined(__MACH__).
Better approach would be either making configure script logic exhaustive,
or move REGINA_BITS setting entirely into `rexx.h', leaving the ability
to override it via --enable-{32,64}bit configure arguments.
The use of OSVERSION to define EXTRA_PATCHES requires an OPSYS check.
The extra patch in question is not valid for DragonFly.
Approved by: portmgr (bapt, after technical discussion)
- Define LICENSE and move PROJECTHOST where it logically belongs
- Propagate available SIMD support down to the compiler (x86 only)
- Do not enforce -O3; update/improve `x-generate-plist' target
- Provide a better port description text while I am here
Tested on: local Mac mini G4 (powerpc), flame (sparc64)
FreeBSD welcomes Python 3.5 (early, pre-release) to the Ports tree,
with 3.5.0 release candidate 3!
Please test this port and Python 3.5 profusely. If you notice issues,
please report them upstream at: https://bugs.python.org to ensure a
robust upcoming 3.5.0 release.
Whats New in Python 3.5:
* https://docs.python.org/3.5/whatsnew/3.5.html
Python 3.5 Release Schedule (PEP 478)
* http://www.python.org/dev/peps/pep-0478
Note: This port retires an old fcntlmodule.c patch, possibly
temporarily. User impact *should* be zero. For more information
see: https://bugs.python.org/issue25026
Requested by: Webair Inc :)
- Add GMP option: libgmp.so is linked if present
- Sort CONFIGURE_ARGS
- Remove duplicate WRKSRC
- Sort USES
- Use pre-install: instead of pre-su-install:
- Convert to new options helper
- Convert to new options target helper
- Change options helper: (copied from ruby22)
- Use CAPIDOCS_CONFIGURE_ENABLE instead of CAPIDOCS_CONFIGURE_OFF
- Use RDOC_CONFIGURE_ENABLE instead of RDOC_CONFIGURE_OFF
- Add regression-test:
- Fix typo
- Cosmetic change
- Pet portlint: fix diff header of patch files
- Bump PORTREVISION for dependency and package change
Changes:
- Add external cffi ports (a la python):
- databases/pypy-gdbm
- databases/pypy-sqlite3
- x11-toolkits/pypy-tkinter
- Add bsd.pypy.mk for consistency between pypy ports.
- Add bsd.pypy.cffi.mk for consistency with external cffi ports.
- Switch back to using $PREFIX/pypy-X.Y (the '-' separator is required to
differentiate between lang/pypy and lang/pypy3)
- Remove all patches (upstreamed, see announcement below)
ChangeLog:
- Bug Fixes
- Revive non-SSE2 support
- Fixes for detaching _io.Buffer*
- Clear up contention in the garbage collector between trace-me-later and
pinning
- Issues reported with our previous release were resolved after reports from
users on our issue tracker at https://bitbucket.org/pypy/pypy/issues or on
IRC at #pypy.
- New features:
- cffi was updated to version 1.3
- The python stdlib was updated to 2.7.10 from 2.7.9
- vmprof now supports multiple threads
- The translation process builds cffi import libraries for some stdlib
packages, which should prevent confusion when package.py is not used
- better support for gdb debugging
- FreeBSD should be able to translate PyPy "out of the box" with no patches
- Numpy:
- Better support for record dtypes, including the align keyword
- Implement casting and create output arrays accordingly (still missing some
corner cases)
- Support creation of unicode ndarrays
- Better support ndarray.flags
- Support axis argument in more functions
- Refactor array indexing to support ellipses
- Allow the docstrings of built-in numpy objects to be set at run-time
- Support the buffered nditer creation keyword
- Performance improvements:
- Delay recursive calls to make them non-recursive
- Skip loop unrolling if it compiles too much code
- Tweak the heapcache
- Add a list strategy for lists that store both floats and 32-bit integers.
The latter are encoded as nonstandard NaNs. Benchmarks show that the speed
of such lists is now very close to the speed of purely-int or purely-float
lists.
- Simplify implementation of ffi.gc() to avoid most weakrefs
- Massively improve the performance of map() with more than one sequence
argument
Differential Revision: https://reviews.freebsd.org/D3285
LFE, Lisp Flavoured Erlang, is a lisp syntax front-end to the Erlang
compiler. Code produced with it is compatible with "normal" Erlang
code. An LFE evaluator and shell is also included.
