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
