version calls "gcc" in two places. Replace that with $CC.
- r346193 added -B${LOCALBASE}/bin in Uses/fortran.mk, just like
compiler.mk, but libtool doesn't recognise this flag and discards it.
Patch ltmain.sh so it passes the flag to the linker unmodified.
This only works on libtool 2.x for now, but that's good enough to fix
the PRs below and a linker error in math/octave on FreeBSD/i386 8.x.
(When those ports set USES=libtool.)
PR: ports/186946, ports/187000
Approved by: bapt
linking problems when base system cc/c++ is used to link object files
generated by gfortran. This affects FreeBSD/i386 8.x and all versions of
FreeBSD/ia64.
PR: ports/186946
definition of the former from Mk/bsd.gcc.mk and add the latter --
still set to 4.6 -- to Mk/bsd.default-versions.mk.
Include Mk/bsd.default-versions.mk from Mk/bsd.gcc.mk to tie the
two together.
of some ports using this unexpectedly. There are no further instances
in the tree any more.
If there is an absolute need to refer to the GCC runtime directory that
cannot be covered by CFLAGS, LDFLAGS or the like, use _GCC_RUNTIME.
This hardly ever should be necessary, though. Avoid whenever possible!
This change is no-op for FreeBSD but is needed for DragonFly support.
It has been run in dports for a year. Also unneeded trailing slashes were
removed from bsd.efl.mk (also tested for a year).
Approved by: portmgr (bapt)
Among changes:
- Switch KDE4_PREFIX to ${LOCALBASE}
- Remove now needless misc/kde4-shared-mime-info port
- Add stage support
- Remove ancient CONFLICTS (KDE 4.9 and less) and LATEST_LINK
- Squeeze MASTER_SITES/MASTER_SITE_SUBDIR
- Convert LIB_DEPENDS to new style
- Use options helpers
- Drop support for FreeBSD 7.x
- Remove Qt/KDE 3 related workarounds
- Remove local patches and use upstream version scheme for libraries
- sysutils/kdeadmin4, net/kdenetwork4, devel/kdesdk4,
and x11-clocks/kdetoys4 ports have been split.
- devel/kcachegrind is now a part of KDE SC [1]
- more logs in area51 repo...
New ports:
devel/kde-dev-scripts: KDE development scripts
devel/kde-dev-utils: KDE development utilities
games/klickety: Tetris themed solitaire
games/picmi: Single player logic-based puzzle game
textproc/libkomparediff2: Library to compare files and strings
The area51 repository features commits by Schaich Alonso, avilla, rakuco
and myself.
PR: ports/186491
Exp-run: by bdrewery
Approved by: beat (former maintainer) [1]
By default, /usr/bin/tclsh and /usr/bin/wish will be substituted with ${TCLSH}
and ${WISH}, respectively. This only works when USES contains 'tcl' or 'tk'.
Approved by: portmgr (bapt)
USE_GCC=yes has been omitted though.
Remove USE_FORTRAN handling from bsd.port.mk and bsd.gcc.mk.
Minor cleanups in some ports like USE_GMAKE, NOPORTDOCS,...
Exp-run: bdrewery
Approved by: portmgr (bdrewery)
pkg_resources module from setuptools at run time. This generally means
anything that installs a CLI utility.
Package-only users do not get setuptools installed when they install
the packages of these ports currently, because USE_PYDISTUTILS=yes doesnt set
a RUN_DEPENDS on it.
This breaks console script invocation, with the following error:
Traceback (most recent call last):
File "/usr/local/bin/<script-name>", line 5, in <module>
from pkg_resources import load_entry_point
ImportError: No module named pkg_resources
The FreeBSD Python team has recently standardised on a consistent
installation pattern for all python software, whether pure-distutils or
setuptools based, and this run-time requirement is currently not being
satisfied, breaking ports that use that functionality.
This commit moves RUN_DEPENDS+=setuptools from the =easy_install *only*
case, to the default case. This does mean that py27-setuptools and
py33-setuptools cannot be installed concurrently, precluding dual stack
Python installations.
The FreeBSD Python team is working hard towards a future where multiple
python and packages versions *can* be installed concurrently, but it is
not explicitly supported in the current state. Improvements to FreeBSD's
ports and package frameworks will help achieve that goal.
[1] http://lists.freebsd.org/pipermail/freebsd-python/2014-February/006592.html
[2] http://lists.freebsd.org/pipermail/freebsd-python/2014-February/006609.html
PR: ports/186706
Reported by: Scott Sturdivant <scott dot sturdivant at gmail.com>
Reviewed by: antoine, rm, mva
MFH: 2014Q1
The GNAT Modified General Public Licence is an older license that is
commonly used with Ada programs, specifically to address legal quirks
with the Ada generics feature.
It is meant to be used as "multi" licence in combination with GPL or
GPLv2. It is not typically seen combined with GPLv3 to my knowledge.
Approved by: portmgr (bapt)
- In libtool 1.3 set deplibs_check_method=pass_all like it is in later
versions. This avoids checking every library with file(1) to see if
it's really a library and avoids some incorrect uses of expr(1)
("expr $var" instead of "expr -- $var" where $var can start with -l).
The parsing of file(1) output is also tested during configure on
/usr/lib/libc.so.* which doesn't exist so configure printed a big (but
harmless) warning.
Approved by: bapt
The GCC ports either do not have any license defined, or they are defined
as GPLv3 which is not completely correct. The runtime libraries in the
FSF-issued GCC releases have a standard exception to the GPLv3 license.
In order to properly reflect this, the GCC ports can define a "multi"
license, GPLv3 and GPLv3RLE, which are both in effect.
Concerns PR: ports/185970
Approved by: portmgr (bapt)
