qbittorrent buildl borken on 12-current?
The log is attached, I'm using poudriere. Any ideas?
--
DE>> Building net-p2p/qbittorrent
build started at Wed Sep 7 05:33:18 EDT 2016
port directory: /usr/ports/net-p2p/qbittorrent
building for: FreeBSD 12amd64-default-job-01 12.0-CURRENT FreeBSD 12.0-CURRENT
amd64
maintained by: y...@rawbw.com
Makefile ident: $FreeBSD: head/net-p2p/qbittorrent/Makefile 412348
2016-04-01 14:16:16Z mat $
Poudriere version: 3.1.10
Host OSVERSION: 123
Jail OSVERSION: 123
---Begin Environment---
SHELL=/bin/csh
OSVERSION=123
UNAME_v=FreeBSD 12.0-CURRENT
UNAME_r=12.0-CURRENT
BLOCKSIZE=K
MAIL=/var/mail/root
STATUS=1
SAVED_TERM=xterm
MASTERMNT=/usr/local/poudriere/data/.m/12amd64-default/ref
FORCE_PACKAGE=yes
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
POUDRIERE_BUILD_TYPE=bulk
PKGNAME=qbittorrent-3.3.3
OLDPWD=/
PWD=/usr/local/poudriere/data/.m/12amd64-default/ref/.p/pool
MASTERNAME=12amd64-default
SCRIPTPREFIX=/usr/local/share/poudriere
USER=root
HOME=/root
POUDRIERE_VERSION=3.1.10
SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
LIBEXECPREFIX=/usr/local/libexec/poudriere
LOCALBASE=/usr/local
PACKAGE_BUILDING=yes
---End Environment---
---Begin OPTIONS List---
===> The following configuration options are available for qbittorrent-3.3.3:
DBUS=off: D-Bus IPC system support
DEBUG=off: Build with debugging support
DOCS=on: Build and/or install documentation
> Options available for the radio QT: you can only select none or one of
them
QT4=on: Qt 4 toolkit support
QT5=off: Qt 5 toolkit support
===> Use 'make config' to modify these settings
---End OPTIONS List---
--CONFIGURE_ARGS--
--disable-qt-dbus --disable-debug CXXFLAGS="-O2 -pipe -fstack-protector
-fno-strict-aliasing -DQ_COMPILER_INITIALIZER_LISTS -DBOOST_ASIO_DYN_LINK"
--with-qt4 --prefix=/usr/local ${_LATE_CONFIGURE_ARGS}
--End CONFIGURE_ARGS--
--CONFIGURE_ENV--
zlib_CFLAGS=-I/usr/include zlib_LIBS=-lz PKG_CONFIG=pkgconf
XDG_DATA_HOME=/wrkdirs/usr/ports/net-p2p/qbittorrent/work
XDG_CONFIG_HOME=/wrkdirs/usr/ports/net-p2p/qbittorrent/work
HOME=/wrkdirs/usr/ports/net-p2p/qbittorrent/work TMPDIR="/tmp" SHELL=/bin/sh
CONFIG_SHELL=/bin/sh CONFIG_SITE=/usr/ports/Templates/config.site
lt_cv_sys_max_cmd_len=262144
--End CONFIGURE_ENV--
--MAKE_ENV--
OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include
OPENSSLLIB=/usr/lib XDG_DATA_HOME=/wrkdirs/usr/ports/net-p2p/qbittorrent/work
XDG_CONFIG_HOME=/wrkdirs/usr/ports/net-p2p/qbittorrent/work
HOME=/wrkdirs/usr/ports/net-p2p/qbittorrent/work TMPDIR="/tmp" NO_PIE=yes
MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES
PREFIX=/usr/local LOCALBASE=/usr/local LIBDIR="/usr/lib" CC="cc" CFLAGS="-O2
-pipe -fstack-protector -fno-strict-aliasing" CPP="cpp" CPPFLAGS=""
LDFLAGS=" -fstack-protector" LIBS="" CXX="c++" CXXFLAGS="-O2 -pipe
-fstack-protector -fno-strict-aliasing -DQ_COMPILER_INITIALIZER_LISTS
-DBOOST_ASIO_DYN_LINK" MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s
-m 555" BSD_INSTALL_LIB="install -s -m 444" BSD_INSTALL_SCRIPT="install -m
555" BSD_INSTALL_DATA="install -m 0644" BSD_INSTALL_MAN="install -m 444"
--End MAKE_ENV--
--PLIST_SUB--
QT_PREFIX="/usr/local"
QT_BINDIR="bin"
QT_INCDIR="include/qt4"
QT_LIBDIR="lib/qt4"
QT_ARCHDIR="lib/qt4/qt4"
QT_PLUGINDIR="lib/qt4/plugins"
QT_LIBEXECDIR="libexec/qt4"
QT_IMPORTDIR="lib/qt4/imports"
QT_QMLDIR="lib/qt4/qt4/qml"
QT_DATADIR="share/qt4"
QT_DOCDIR="share/doc/qt4"
QT_L10NDIR="share/qt4/translations"
QT_ETCDIR="etc/xdg"
QT_EXAMPLEDIR="share/examples/qt4"
QT_TESTDIR="share/qt4/tests"
QT_MKSPECDIR="share/qt4/mkspecs"
GTK2_VERSION="2.10.0"
GTK3_VERSION="3.0.0"
OSREL=12.0
PREFIX=%D
LOCALBASE=/usr/local
RESETPREFIX=/usr/local
PORTDOCS=""
PORTEXAMPLES=""
LIB32DIR=lib
DOCSDIR="share/doc/qbittorrent"
EXAMPLESDIR="share/examples/qbittorrent"
DATADIR="share/qbittorrent"
WWWDIR="www/qbittorrent"
ETCDIR="etc/qbittorrent"
--End PLIST_SUB--
--SUB_LIST--
PREFIX=/usr/local
LOCALBASE=/usr/local
DATADIR=/usr/local/share/qbittorrent
DOCSDIR=/usr/local/share/doc/qbittorrent
EXAMPLESDIR=/usr/local/share/examples/qbittorrent
WWWDIR=/usr/local/www/qbittorrent
ETCDIR=/usr/local/etc/qbittorrent
--End SUB_LIST--
---Begin make.conf---
USE_PACKAGE_DEPENDS=yes
BATCH=yes
WRKDIRPREFIX=/wrkdirs
PORTSDIR=/usr/ports
PACKAGES=/packages
DISTDIR=/distfiles
DISABLE_MAKE_JOBS=poudriere
---End make.conf---
===
===> License GPLv2 accepted by the user
===
===
===> qbittorrent-3.3.3 depends on file: /usr/local/sbin/pkg - not found
===> Installing existing package /packages/All/pkg-1.8.7_1.txz
[12amd64-default-job-01] Installing pkg-1.8.7_1...
[12amd64-default-job-01] Extracting pkg-1.8.7_1: .. done
===> qbittorrent-3.3.3 depends on file: /usr/local/sbin/pkg - found
===> Returning to build of
pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?
I'm trying to upgrade my ports with a set that I built using poudriere.
I'm running FreeBSD-current r295354, pkg 1.6.3.
The packages are here on my local (localhost, vega) box:
/usr/local/poudriere/data/packages/11amd64-default
My repo pkg.conf (vega.conf) looks like this:
vega: {
url: "file://localhost/usr/local/poudriere/data/packages/11amd64-default",
mirror_type: "srv",
signature_type: "none"
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}
'pkg upgrade -r vega' yields this:
# pkg upgrade -r vega
Updating vega repository catalogue...
vega repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (360 candidates): 100%
Processing candidates (360 candidates): 100%
The following 139 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
cblas: 1.0_4 [vega]
...
Installed packages to be UPGRADED:
xterm: 320 -> 322 [vega]
...
Installed packages to be REINSTALLED:
yajl-2.1.0 [vega] (provided shared library changed)
...
The operation will free 20 MiB.
323 MiB to be downloaded.
Proceed with this action? [y/N]: y
Checking integrity... done (0 conflicting)
pkg:
archive_read_open_filename(localhost/usr/local/poudriere/data/packages/11amd64-default/All/pciids-20160116.txz):
Failed to open
'localhost/usr/local/poudriere/data/packages/11amd64-default/All/pciids-20160116.txz'
Fetch however seems to work fine:
$ fetch
file://localhost/usr/local/poudriere/data/packages/11amd64-default/All/pciids-20160116.txz
pciids-20160116.txz 100% of 191 kB 332 MBps 00m00s
Fetch also works fine using my hostname (vega) instead of localhost,
while 'pkg upgrade' still fails in the same way. I am not using DNS
for local hosts, just /etc/hosts.
--
DE
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?
On Wed, 10 Feb 2016, Daniel Eischen wrote:
I'm trying to upgrade my ports with a set that I built using poudriere.
I'm running FreeBSD-current r295354, pkg 1.6.3.
The packages are here on my local (localhost, vega) box:
/usr/local/poudriere/data/packages/11amd64-default
My repo pkg.conf (vega.conf) looks like this:
vega: {
url:
"file://localhost/usr/local/poudriere/data/packages/11amd64-default",
mirror_type: "srv",
BTW, I changed mirror_type to "none", but it doesn't make a difference,
still fails in the same way.
--
DE
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?
On Wed, 10 Feb 2016, Dimitry Andric wrote:
On 10 Feb 2016, at 20:10, Daniel Eischen <deisc...@freebsd.org> wrote:
I'm trying to upgrade my ports with a set that I built using poudriere.
I'm running FreeBSD-current r295354, pkg 1.6.3.
The packages are here on my local (localhost, vega) box:
/usr/local/poudriere/data/packages/11amd64-default
My repo pkg.conf (vega.conf) looks like this:
vega: {
url: "file://localhost/usr/local/poudriere/data/packages/11amd64-default",
Try using file:/// (e.g three slashes). Yes, this is ugly, and Tim
Berners-Lee has even apologized for it... :-) [1]
Nope, that doesn't work either. Previously, I used:
url: "file:/usr/local/poudriere/data/packages/11amd64-default
and that worked until upgrading to a more recent -current and pkg
at the same time. fetch(1,3) do not work with that syntax any more
and pkg complains with "pkg: invalid url: file:/usr/local/..."
--
DE
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?
On Wed, 10 Feb 2016, Warren Block wrote:
On Wed, 10 Feb 2016, Daniel Eischen wrote:
On Wed, 10 Feb 2016, Dimitry Andric wrote:
On 10 Feb 2016, at 20:10, Daniel Eischen <deisc...@freebsd.org> wrote:
I'm trying to upgrade my ports with a set that I built using poudriere.
I'm running FreeBSD-current r295354, pkg 1.6.3.
The packages are here on my local (localhost, vega) box:
/usr/local/poudriere/data/packages/11amd64-default
My repo pkg.conf (vega.conf) looks like this:
vega: {
url:
"file://localhost/usr/local/poudriere/data/packages/11amd64-default",
Try using file:/// (e.g three slashes). Yes, this is ugly, and Tim
Berners-Lee has even apologized for it... :-) [1]
Nope, that doesn't work either. Previously, I used:
url: "file:/usr/local/poudriere/data/packages/11amd64-default
and that worked until upgrading to a more recent -current and pkg
at the same time. fetch(1,3) do not work with that syntax any more
and pkg complains with "pkg: invalid url: file:/usr/local/..."
Not with localhost, no. It's file:// and then the path, which begins with a
slash, so
file:///usr/local/poudriere/data/packages/11amd64-default
Thanks! That did the trick.
--
DE
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg 1.6.3 unable to upgrade, URL in pkg.conf problem?
On Wed, 10 Feb 2016, Baptiste Daroussin wrote:
On Wed, Feb 10, 2016 at 10:16:44PM +0100, Dimitry Andric wrote:
On 10 Feb 2016, at 20:10, Daniel Eischen <deisc...@freebsd.org> wrote:
I'm trying to upgrade my ports with a set that I built using poudriere.
I'm running FreeBSD-current r295354, pkg 1.6.3.
The packages are here on my local (localhost, vega) box:
/usr/local/poudriere/data/packages/11amd64-default
My repo pkg.conf (vega.conf) looks like this:
vega: {
url: "file://localhost/usr/local/poudriere/data/packages/11amd64-default",
Try using file:/// (e.g three slashes). Yes, this is ugly, and Tim
Berners-Lee has even apologized for it... :-) [1]
-Dimitry
[1] http://news.bbc.co.uk/2/hi/technology/8306631.stm
Yes that is it.
Note that I will relax it in pkg 1.6.4 to be released very soon, I have been too
strict by accident in pkg 1.6.3 (I have never thought anyone would use file://
or file:/.
pkg respects RFC2396 but there are not reason not to relax it a bit given some
users seems to use the previous syntax
No worries, now that I have the correct syntax. Thanks!
--
DE
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Using pkg to fetch packages for different ABI
I want to use pkg to maintain a set of packages for nanobsd
systems that are a different OS version and ABI than the
host system. Basically, I want to be able to do:
# pkg fetch -d -r FreeBSD_10x_32 -o ./
and have it fetch all the required packages for .
The host system is 10.2-RELEASE-p9 amd64, the target system
in this case is similar, but just x86, not amd64. pkg is
version 1.6.2.
Trying to initially update the repo catalog gives this:
# cat /usr/local/etc/pkg/repos/FreeBSD_10x_32.conf
FreeBSD_10x_32: {
ABI: "FreeBSD:x86:32"
url: "pkg+http://pkg.FreeBSD.org/freebsd:10:x86:32/latest;,
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}
# pkg update -r FreeBSD_10x_32
Updating FreeBSD_10x_32 repository catalogue...
Fetching meta.txz: 100%944 B 0.9kB/s00:01
Fetching packagesite.txz: 100%5 MiB 2.8MB/s00:02
Processing entries: 0%
pkg: wrong architecture: freebsd:10:x86:32 instead of FreeBSD:10:amd64
pkg: repository FreeBSD_10x_32 contains packages with wrong ABI:
freebsd:10:x86:32
Processing entries: 100%
Unable to update repository FreeBSD_10x_32
Why does 'pkg' care what the ABI is unless we try to actually
install the packages?
--
DE
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Using pkg to fetch packages for different ABI
On Tue, 2 Feb 2016, Jason Unovitch wrote:
On Tue, Feb 2, 2016 at 8:21 PM, Daniel Eischen <deisc...@freebsd.org> wrote:
I want to use pkg to maintain a set of packages for nanobsd
systems that are a different OS version and ABI than the
host system. Basically, I want to be able to do:
# pkg fetch -d -r FreeBSD_10x_32 -o ./
and have it fetch all the required packages for .
The host system is 10.2-RELEASE-p9 amd64, the target system
in this case is similar, but just x86, not amd64. pkg is
version 1.6.2.
Trying to initially update the repo catalog gives this:
# cat /usr/local/etc/pkg/repos/FreeBSD_10x_32.conf
FreeBSD_10x_32: {
ABI: "FreeBSD:x86:32"
url: "pkg+http://pkg.FreeBSD.org/freebsd:10:x86:32/latest;,
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}
# pkg update -r FreeBSD_10x_32
Updating FreeBSD_10x_32 repository catalogue...
Fetching meta.txz: 100%944 B 0.9kB/s00:01
Fetching packagesite.txz: 100%5 MiB 2.8MB/s00:02
Processing entries: 0%
pkg: wrong architecture: freebsd:10:x86:32 instead of FreeBSD:10:amd64
pkg: repository FreeBSD_10x_32 contains packages with wrong ABI:
freebsd:10:x86:32
Processing entries: 100%
Unable to update repository FreeBSD_10x_32
Why does 'pkg' care what the ABI is unless we try to actually
install the packages?
--
DE
Set it via an environmental variable:
setenv ABI freebsd:10:x86:32
ABI can be overridden with environmental variables or via `-o
ABI=freebsd:10:x86:32'. I'm actually using environmental variables on
a CentOS box with a locally compiled pkg to do a pkg fetch and pkg
repo to store a couple packages for internal use.
Interesting, that works. I would have thought setting it in
the repo.conf would have worked too, though.
So, can I have one (1) repo.conf and use it for multiple ABIs,
like so?:
$ cat /usr/local/etc/pkg/repos/FreeBSD_10x.conf
FreeBSD_10x: {
url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}
$ mkdir /tmp/10x_amd64
$ mkdir /tmp/10x_x86
$ pkg fetch -Ud -r FreeBSD_10x -o /tmp/10x_amd64 \
security/sudo shells/bash
$ pkg -o ABI=freebsd:10:x86:32 fetch -Ud -r FreeBSD_10x \
-o /tmp/10x_x86 security/sudo shells/bash
I suppose this assumes that the package dependencies are exactly
the same for all the ABIs that one would need.
--
DE
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: USES vs BUILD_DEPENDS
On Sun, 29 Mar 2015, Daniel Eischen wrote: On Sun, 29 Mar 2015, Baptiste Daroussin wrote: On Sun, Mar 29, 2015 at 12:41:21PM -0400, Daniel Eischen wrote: I have a port which needs pod2man just to build the man file during installation. Why do I need USES= pod2man:perl5 just to build the port? It doesn't seem feasible to use BUILD_DEPENDS because there is no generic perl5 port. Have you tried using pod2mdoc ? No, I didn't know about it, I will check it out. I searched other ports (grep) and found pod2man used. My port's (internal) doc/Makefile uses pod2man. pod2mdoc doesn't seem compatible with the way pod2man is used: pod2man --release=`cat .version` --center=Foo $*.pod in particular, the -r or --release option. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: USES vs BUILD_DEPENDS
On Mon, 30 Mar 2015, Mathieu Arnold wrote: +--On 29 mars 2015 12:41:21 -0400 Daniel Eischen deisc...@freebsd.org wrote: | I have a port which needs pod2man just to build the man file | during installation. Why do I need USES= pod2man:perl5 just to | build the port? It doesn't seem feasible to use BUILD_DEPENDS | because there is no generic perl5 port. You need: USES=perl5 USE_PERL5=build Because that's the right way to say you need Perl to build your port. Ok, thanks! I'll try that. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
USES vs BUILD_DEPENDS
I have a port which needs pod2man just to build the man file during installation. Why do I need USES= pod2man:perl5 just to build the port? It doesn't seem feasible to use BUILD_DEPENDS because there is no generic perl5 port. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: USES vs BUILD_DEPENDS
On Sun, 29 Mar 2015, Baptiste Daroussin wrote: On Sun, Mar 29, 2015 at 12:41:21PM -0400, Daniel Eischen wrote: I have a port which needs pod2man just to build the man file during installation. Why do I need USES= pod2man:perl5 just to build the port? It doesn't seem feasible to use BUILD_DEPENDS because there is no generic perl5 port. Have you tried using pod2mdoc ? No, I didn't know about it, I will check it out. I searched other ports (grep) and found pod2man used. My port's (internal) doc/Makefile uses pod2man. Btw USES=pod2man:perl5 does not exists :) Sorry, I meant USES= perl5. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: CFLAGS only for clang in mixed-compiler project?
On Thu, 1 Jan 2015, Lev Serebryakov wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I'm trying to update arm-eabi (microcontroller) cross-gcc port to
latest version 4.9 and have one weird problem.
Some part of gcc for arm (neon coprocessor machine description, to be
precise) requires more than 256 nested parenthesis in version 4.9 (4.8
doesn't have this problem). Due to this parenthesis madness clang
needs -fbracket-depth=1024 option. If I add this option to CFLAGS in
environment variable, I have other problem. Later in build process gcc
uses newly-built gcc (xgcc) to build library. And this gcc picks up
-fbracket-depth=1024 from environment and fails due to unknown option!
How could I provide options only for clang but not for gcc?
Hmm, I found CFLAGS.clang (or rather CFLAGS.${COMPILER_TYPE})
in /usr/share/mk/, so you might try setting that instead of
just CFLAGS. Just a guess...
--
DE
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
RE: shells/bash port, add a knob which symlinks to /bin/bash ?
On Fri, 12 Sep 2014, Rang, Anton wrote: If you want interoperability just use /usr/bin/env bash as a shebang. That doesn't work for this use case -- the user shell coming from LDAP -- but I agree that the port shouldn't be modifying /usr/bin. It's easy enough to add the symlink manually after installing the port if you're in this situation, or there may be a way to configure the LDAP module to map /bin/bash to /usr/local/bin/bash (I haven't looked to see what is supported here). We have used LDAP on Solaris for years, and have mixed environments of Solaris, Linux, and FreeBSD. We use /usr/local/bin/bash in LDAP for shells, then either link that to the system /bin/bash or install more up-to-date bash in /usr/local/bin. This way you can always install a more up-to-date shell in /usr/local/bin without changing the base OS - you don't want base OS shell scripts to break by updating to a newer shell. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
net/libexosip2-legacy build is failing on -current
I'm well into my 2 week quest to update my ports from a Feb 2014
build to now (June). One of the last issues is libexosip2-legacy
failing to build with this:
eXconf.c:1103:6: warning: implicit declaration of function 'timercmp' is
invalid in C99 [-Wimplicit-function-declaration]
if (osip_timercmp(now, mtimer, )) {
^
...
eXconf.c:1103:35: error: expected expression
if (osip_timercmp(now, mtimer, )) {
^
...
/usr/local/include/osip2/osip_time.h:59:61: note: expanded from macro
'osip_timercmp'
#define osip_timercmp(tvp, uvp, cmp)timercmp(tvp,uvp,cmp)
This is stopping my upgrade of kde4, since that needs net/kdenetwork4,
which needs net/linphone-base, which needs libexosip2-legacy.
See attached log for more. I'm on -current from Jun 17 svn updated
sources.
FreeBSD 11.0-CURRENT #1 r267580M: Fri Jun 20 11:11:10 EDT 2014 (amd64)
--
DElibtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include
-I/usr/local/include -Wall -Wcast-align -Wchar-subscripts -Wformat -Winline
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith
-DSRV_RECORD -DOSIP_MT -O2 -pipe -I/usr/local/include -L/usr/local/lib
-fno-strict-aliasing -D_THREAD_SAFE -pthread -O2 -pipe -I/usr/local/include
-L/usr/local/lib -fno-strict-aliasing -MT eXosip.lo -MD -MP -MF
.deps/eXosip.Tpo -c eXosip.c -o eXosip.o /dev/null 21
mv -f .deps/eXosip.Tpo .deps/eXosip.Plo
/bin/sh ../libtool --tag=CC--mode=compile cc -DHAVE_CONFIG_H -I. -I.. -I..
-I../include -I/usr/local/include -Wall -Wcast-align -Wchar-subscripts
-Wformat -Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wpointer-arith -DSRV_RECORD -DOSIP_MT -O2 -pipe -I/usr/local/include
-L/usr/local/lib -fno-strict-aliasing -D_THREAD_SAFE -pthread -O2 -pipe
-I/usr/local/include -L/usr/local/lib -fno-strict-aliasing -MT eXconf.lo -MD
-MP -MF .deps/eXconf.Tpo -c -o eXconf.lo eXconf.c
libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include
-I/usr/local/include -Wall -Wcast-align -Wchar-subscripts -Wformat -Winline
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith
-DSRV_RECORD -DOSIP_MT -O2 -pipe -I/usr/local/include -L/usr/local/lib
-fno-strict-aliasing -D_THREAD_SAFE -pthread -O2 -pipe -I/usr/local/include
-L/usr/local/lib -fno-strict-aliasing -MT eXconf.lo -MD -MP -MF
.deps/eXconf.Tpo -c eXconf.c -fPIC -DPIC -o .libs/eXconf.o
cc: warning: argument unused during compilation: '-L/usr/local/lib'
cc: warning: argument unused during compilation: '-L/usr/local/lib'
eXconf.c:85:15: warning: implicitly declaring library function 'strncmp' with
type 'int (const char *, const char *, unsigned long)'
return (0 != strncmp(c_address, 192.168, 7)
^
eXconf.c:85:15: note: please include the header string.h or explicitly
provide a declaration for 'strncmp'
eXconf.c:108:2: warning: implicit declaration of function 'free' is invalid in
C99 [-Wimplicit-function-declaration]
osip_free(eXosip.user_agent);
^
/usr/local/include/osipparser2/osip_port.h:105:83: note: expanded from macro
'osip_free'
#define osip_free(P) { if (P!=NULL) { if (osip_free_func) osip_free_func(P);
else free(P);} }
^
eXconf.c:265:4: warning: implicitly declaring library function 'memset' with
type 'void *(void *, int, unsigned long)'
memset(http_auth, 0, sizeof(struct eXosip_http_auth));
^
eXconf.c:265:4: note: please include the header string.h or explicitly
provide a declaration for 'memset'
eXconf.c:371:6: warning: implicit declaration of function 'close' is invalid in
C99 [-Wimplicit-function-declaration]
close(sock);
^
eXconf.c:710:36: warning: implicitly declaring library function 'malloc' with
type 'void *(unsigned long)'
eXosip.j_events = (osip_fifo_t *) osip_malloc(sizeof(osip_fifo_t));
^
/usr/local/include/osipparser2/osip_port.h:99:62: note: expanded from macro
'osip_malloc'
#define osip_malloc(S) (osip_malloc_func?osip_malloc_func(S):malloc(S))
^
eXconf.c:710:36: note: please include the header stdlib.h or explicitly
provide a declaration for 'malloc'
/usr/local/include/osipparser2/osip_port.h:99:62: note: expanded from macro
'osip_malloc'
#define osip_malloc(S) (osip_malloc_func?osip_malloc_func(S):malloc(S))
^
eXconf.c:924:5: warning: implicitly declaring library function 'memcpy' with
type 'void *(void *, const void *, unsigned long)'
memcpy(addr, addrinfo-ai_addr,
addrinfo-ai_addrlen);
^
eXconf.c:924:5: note: please include the header string.h or
Re: net/libexosip2-legacy build is failing on -current
On Sat, 28 Jun 2014, Daniel Eischen wrote:
I'm well into my 2 week quest to update my ports from a Feb 2014
build to now (June). One of the last issues is libexosip2-legacy
failing to build with this:
I fixed this by removing package net/libosip2 and instead
installing net/libosip.
--
DElibtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include
-I/usr/local/include -Wall -Wcast-align -Wchar-subscripts -Wformat -Winline
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith
-DSRV_RECORD -DOSIP_MT -O2 -pipe -I/usr/local/include -L/usr/local/lib
-fno-strict-aliasing -D_THREAD_SAFE -pthread -O2 -pipe -I/usr/local/include
-L/usr/local/lib -fno-strict-aliasing -MT eXosip.lo -MD -MP -MF
.deps/eXosip.Tpo -c eXosip.c -o eXosip.o /dev/null 21
mv -f .deps/eXosip.Tpo .deps/eXosip.Plo
/bin/sh ../libtool --tag=CC--mode=compile cc -DHAVE_CONFIG_H -I. -I.. -I..
-I../include -I/usr/local/include -Wall -Wcast-align -Wchar-subscripts
-Wformat -Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wpointer-arith -DSRV_RECORD -DOSIP_MT -O2 -pipe -I/usr/local/include
-L/usr/local/lib -fno-strict-aliasing -D_THREAD_SAFE -pthread -O2 -pipe
-I/usr/local/include -L/usr/local/lib -fno-strict-aliasing -MT eXconf.lo -MD
-MP -MF .deps/eXconf.Tpo -c -o eXconf.lo eXconf.c
libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include
-I/usr/local/include -Wall -Wcast-align -Wchar-subscripts -Wformat -Winline
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith
-DSRV_RECORD -DOSIP_MT -O2 -pipe -I/usr/local/include -L/usr/local/lib
-fno-strict-aliasing -D_THREAD_SAFE -pthread -O2 -pipe -I/usr/local/include
-L/usr/local/lib -fno-strict-aliasing -MT eXconf.lo -MD -MP -MF
.deps/eXconf.Tpo -c eXconf.c -fPIC -DPIC -o .libs/eXconf.o
cc: warning: argument unused during compilation: '-L/usr/local/lib'
cc: warning: argument unused during compilation: '-L/usr/local/lib'
eXconf.c:85:15: warning: implicitly declaring library function 'strncmp' with
type 'int (const char *, const char *, unsigned long)'
return (0 != strncmp(c_address, 192.168, 7)
^
eXconf.c:85:15: note: please include the header string.h or explicitly
provide a declaration for 'strncmp'
eXconf.c:108:2: warning: implicit declaration of function 'free' is invalid in
C99 [-Wimplicit-function-declaration]
osip_free(eXosip.user_agent);
^
/usr/local/include/osipparser2/osip_port.h:105:83: note: expanded from macro
'osip_free'
#define osip_free(P) { if (P!=NULL) { if (osip_free_func) osip_free_func(P);
else free(P);} }
^
eXconf.c:265:4: warning: implicitly declaring library function 'memset' with
type 'void *(void *, int, unsigned long)'
memset(http_auth, 0, sizeof(struct eXosip_http_auth));
^
eXconf.c:265:4: note: please include the header string.h or explicitly
provide a declaration for 'memset'
eXconf.c:371:6: warning: implicit declaration of function 'close' is invalid in
C99 [-Wimplicit-function-declaration]
close(sock);
^
eXconf.c:710:36: warning: implicitly declaring library function 'malloc' with
type 'void *(unsigned long)'
eXosip.j_events = (osip_fifo_t *) osip_malloc(sizeof(osip_fifo_t));
^
/usr/local/include/osipparser2/osip_port.h:99:62: note: expanded from macro
'osip_malloc'
#define osip_malloc(S) (osip_malloc_func?osip_malloc_func(S):malloc(S))
^
eXconf.c:710:36: note: please include the header stdlib.h or explicitly
provide a declaration for 'malloc'
/usr/local/include/osipparser2/osip_port.h:99:62: note: expanded from macro
'osip_malloc'
#define osip_malloc(S) (osip_malloc_func?osip_malloc_func(S):malloc(S))
^
eXconf.c:924:5: warning: implicitly declaring library function 'memcpy' with
type 'void *(void *, const void *, unsigned long)'
memcpy(addr, addrinfo-ai_addr,
addrinfo-ai_addrlen);
^
eXconf.c:924:5: note: please include the header string.h or explicitly
provide a declaration for 'memcpy'
eXconf.c:1103:6: warning: implicit declaration of function 'timercmp' is
invalid in C99 [-Wimplicit-function-declaration]
if (osip_timercmp(now, mtimer, )) {
^
/usr/local/include/osip2/osip_time.h:59:41: note: expanded from macro
'osip_timercmp'
#define osip_timercmp(tvp, uvp, cmp)timercmp(tvp,uvp,cmp)
^
eXconf.c:1103:35: error: expected expression
if (osip_timercmp(now, mtimer, )) {
^
/usr/local/include/osip2/osip_time.h:59:58: note: expanded from macro
'osip_timercmp
net-im/kopete-kde4 broken on -current, stops kdenetwork build
I'm trying to upgrade my ports on -current: FreeBSD rigel 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r247154: Fri Feb 22 14:59:28 EST 2013 deischen@rigel:/usr/obj/opt/FreeBSD/current/src/sys/rigel amd64 And hitting this error in building net-im/kopete-kde4: cd /opt/FreeBSD/current/ports/net-im/kopete-kde4/work/.build/kopete/identity /usr/bin/c++ -DMAKE_KOPETEIDENTITY_LIB -O2 -pipe -DHAVE_LINUX_INTEGER_TYPES=1 -fno-strict-aliasing -O2 -pipe -DHAVE_LINUX_INTEGER_TYPES=1 -fno-strict-aliasing -DQT_NO_DEBUG -fPIC -I/opt/FreeBSD/current/ports/net-im/kopete-kde4/work/.build/kopete/identity -I/opt/FreeBSD/current/ports/net-im/kopete-kde4/work/kdenetwork-4.9.5/kopete/kopete/identity -I/opt/FreeBSD/current/ports/net-im/kopete-kde4/work/.build -I/opt/FreeBSD/current/ports/net-im/kopete-kde4/work/kdenetwork-4.9.5/kopete/libkopete -I/opt/FreeBSD/current/ports/net-im/kopete-kde4/work/.build/libkopete -I/opt/FreeBSD/current/ports/net-im/kopete-kde4/work/kdenetwork-4.9.5/kopete/libkopete/ui -I/opt/FreeBSD/current/ports/net-im/kopete-kde4/work/.build/libkopete/ui -I/opt/FreeBSD/current/ports/net-im/kopete-kde4/work/kdenetwork-4.9.5/kopete/libkopete/private -I/opt/FreeBSD/current/ports/net-im/kopete-kde4/work/kdenetwork-4.9.5/kopete/libkopete/contactlist -I/opt/FreeBSD/current/ports/net-im/kopete-kde4/work/kdenetwork-4.9.5/kopete/libkopete/tasks -I/opt/FreeBSD/current/ports/net-im/kopete-kde4/work/kdenetwork-4.9.5/kopete/kopete/statusmenu -I/opt/FreeBSD/current/ports/net-im/kopete-kde4/work/.build/kopete/statusmenu -I/opt/FreeBSD/current/ports/net-im/kopete-kde4/work/kdenetwork-4.9.5/kopete/kopete/addaccountwizard -I/opt/FreeBSD/current/ports/net-im/kopete-kde4/work/.build/kopete/addaccountwizard -I/usr/local/kde4/include -I/usr/local/kde4/include/KDE -I/usr/local/include/qt4/phonon -I/usr/local/include/qt4/QtXmlPatterns -I/usr/local/include/qt4/QtXml -I/usr/local/include/qt4/QtWebKit -I/usr/local/include/qt4/QtUiTools -I/usr/local/include/qt4/QtTest -I/usr/local/include/qt4/QtSvg -I/usr/local/include/qt4/QtSql -I/usr/local/include/qt4/QtScriptTools -I/usr/local/include/qt4/QtScript -I/usr/local/include/qt4/QtOpenGL -I/usr/local/include/qt4/QtNetwork -I/usr/local/include/qt4/QtHelp -I/usr/local/include/qt4/QtDesigner -I/usr/local/include/qt4/QtDeclarative -I/usr/local/include/qt4/QtDBus -I/usr/local/include/qt4/Qt3Support -I/usr/local/include/qt4/QtGui -I/usr/local/include/qt4/QtCore -I/usr/local/include/qt4/Qt -I/usr/local/share/qt4/mkspecs/default -I/usr/local/include/qt4 -I/usr/local/include -o CMakeFiles/kopeteidentity.dir/kopeteidentity_automoc.o -c /opt/FreeBSD/current/ports/net-im/kopete-kde4/work/.build/kopete/identity/kopeteidentity_automoc.cpp In file included from /opt/FreeBSD/current/ports/net-im/kopete-kde4/work/kdenetwork-4.9.5/kopete/plugins/otr/otrlchatinterface.cpp:25: In file included from /opt/FreeBSD/current/ports/net-im/kopete-kde4/work/kdenetwork-4.9.5/kopete/plugins/otr/otrlchatinterface.h:33: In file included from /opt/FreeBSD/current/ports/net-im/kopete-kde4/work/kdenetwork-4.9.5/kopete/libkopete/kopetechatsession.h:27: In file included from /usr/local/include/qt4/QtCore/QObject:1: In file included from /usr/local/include/qt4/QtCore/qobject.h:47: In file included from /usr/local/include/qt4/QtCore/qobjectdefs.h:45: /usr/local/include/qt4/QtCore/qnamespace.h:47:1: error: unknown type name 'QT_BEGIN_HEADER' QT_BEGIN_HEADER ^ /usr/local/include/qt4/QtCore/qnamespace.h:49:19: error: expected ';' after top level declarator QT_BEGIN_NAMESPACE ^ ; And it goes on with more errors for Q_CORE_EXPORT, QT_END_NAMESPACE, QT_END_HEADER. Full log here: http://people.freebsd.org/~deischen/ports/kdenetwork.log My qt4 is up to date at 4.8.4. qnamespace.h includes qglobal.h, which defines these macros, so I'm not sure how they are not being defined. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: net-im/kopete-kde4 broken on -current, stops kdenetwork build
On Thu, 28 Feb 2013, Daniel Eischen wrote: I'm trying to upgrade my ports on -current: FreeBSD rigel 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r247154: Fri Feb 22 14:59:28 EST 2013 deischen@rigel:/usr/obj/opt/FreeBSD/current/src/sys/rigel amd64 And hitting this error in building net-im/kopete-kde4: [ ... ] And it goes on with more errors for Q_CORE_EXPORT, QT_END_NAMESPACE, QT_END_HEADER. Full log here: http://people.freebsd.org/~deischen/ports/kdenetwork.log My qt4 is up to date at 4.8.4. qnamespace.h includes qglobal.h, which defines these macros, so I'm not sure how they are not being defined. I'm not sure why, but there were stale include files for qt-3.3.8_14 which were not deinstalled, and these were being picked up over the qt4 includes. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
graphics/graphviz broken on -current, hangs indefinitely on install
I have to mark graphics/graphviz BROKEN on -current in order to get portupgrade to bypass the upgrade of graphviz because it hangs forever on install: Making install in dot gmake[3]: Entering directory `/opt/FreeBSD/current/ports/graphics/graphviz/work/graphviz-2.30.1/cmd/dot' gmake[4]: Entering directory `/opt/FreeBSD/current/ports/graphics/graphviz/work/graphviz-2.30.1/cmd/dot' ../../config/install-sh -c -d '/usr/local/bin' /bin/sh /usr/local/bin/libtool --mode=install install -s -o root -g wheel -m 555 dot dot_builtins '/usr/local/bin' libtool: install: install -o root -g wheel -m 555 -s .libs/dot /usr/local/bin/dot libtool: install: install -o root -g wheel -m 555 -s .libs/dot_builtins /usr/local/bin/dot_builtins gmake install-exec-hook gmake[5]: Entering directory `/opt/FreeBSD/current/ports/graphics/graphviz/work/graphviz-2.30.1/cmd/dot' (cd /usr/local/bin; if test -x dot; then for i in neato twopi fdp circo osage patchwork sfdp; do rm -f $i; ln -s dot $i; done; fi;) if test x = x; then if test -x /usr/local/bin/dot; then if test -x /sbin/ldconfig; then /sbin/ldconfig 2/dev/null; fi; /usr/local/bin/dot -c; else /usr/local/bin/dot_static -c; fi; fi And there it hangs. # ls -l /usr/local/bin/dot -r-xr-xr-x 1 root wheel 8480 Feb 27 12:33 /usr/local/bin/dot # dot -v Error: /usr/local/lib/graphviz/config6 is zero sized, or other read error. dot - graphviz version 2.30.1 (20130227.1730) libdir = /usr/local/lib/graphviz Error: /usr/local/lib/graphviz/config6 is zero sized, or other read error. There is no layout engine support for dot Perhaps dot -c needs to be run (with installer's privileges) to register the plugins? # rm /usr/local/lib/graphviz/config6 # /usr/local/bin/dot -c [ hangs ] # uname -a FreeBSD rigel 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r247154: Fri Feb 22 14:59:28 EST 2013 deischen@rigel:/usr/obj/opt/FreeBSD/current/src/sys/rigel amd64 # cat /etc/make.conf BATCH=yes WITH_NEW_XORG=true WITH_KMS=true WITH_PKGNG=yes # added by use.perl 2012-11-10 23:33:24 PERL_VERSION=5.14.2 -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/graphviz broken on -current, hangs indefinitely on install
On Wed, 27 Feb 2013, Chris Rees wrote: On 27 Feb 2013 17:48, Daniel Eischen deisc...@freebsd.org wrote: I have to mark graphics/graphviz BROKEN on -current in order to get portupgrade to bypass the upgrade of graphviz because it hangs forever on install: Making install in dot gmake[3]: Entering directory `/opt/FreeBSD/current/ports/graphics/graphviz/work/graphviz-2.30.1/cmd/dot' gmake[4]: Entering directory `/opt/FreeBSD/current/ports/graphics/graphviz/work/graphviz-2.30.1/cmd/dot' ../../config/install-sh -c -d '/usr/local/bin' /bin/sh /usr/local/bin/libtool --mode=install install -s -o root -g wheel -m 555 dot dot_builtins '/usr/local/bin' libtool: install: install -o root -g wheel -m 555 -s .libs/dot /usr/local/bin/dot libtool: install: install -o root -g wheel -m 555 -s .libs/dot_builtins /usr/local/bin/dot_builtins gmake install-exec-hook gmake[5]: Entering directory `/opt/FreeBSD/current/ports/graphics/graphviz/work/graphviz-2.30.1/cmd/dot' (cd /usr/local/bin; if test -x dot; then for i in neato twopi fdp circo osage patchwork sfdp; do rm -f $i; ln -s dot $i; done; fi;) if test x = x; then if test -x /usr/local/bin/dot; then if test -x /sbin/ldconfig; then /sbin/ldconfig 2/dev/null; fi; /usr/local/bin/dot -c; else /usr/local/bin/dot_static -c; fi; fi And there it hangs. # ls -l /usr/local/bin/dot -r-xr-xr-x 1 root wheel 8480 Feb 27 12:33 /usr/local/bin/dot # dot -v Error: /usr/local/lib/graphviz/config6 is zero sized, or other read error. dot - graphviz version 2.30.1 (20130227.1730) libdir = /usr/local/lib/graphviz Error: /usr/local/lib/graphviz/config6 is zero sized, or other read error. There is no layout engine support for dot Perhaps dot -c needs to be run (with installer's privileges) to register the plugins? # rm /usr/local/lib/graphviz/config6 # /usr/local/bin/dot -c [ hangs ] # uname -a FreeBSD rigel 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r247154: Fri Feb 22 14:59:28 EST 2013 deischen@rigel:/usr/obj/opt/FreeBSD/current/src/sys/rigel amd64 # cat /etc/make.conf BATCH=yes WITH_NEW_XORG=true WITH_KMS=true WITH_PKGNG=yes # added by use.perl 2012-11-10 23:33:24 PERL_VERSION=5.14.2 Did you try deinstalling first? Are your world and kernel exactly in sync? Yes, yes, and yes :-) I did make deinstall, make clean, make, and make install as root in that order. Here's a ktrace of 'sudo ktrace dot -c': http://freefall.freebsd.org/~deischen/graphviz/dot.ktrace It seems to hang on a _umtx_op() right after getting the kern.usrstack sysctl. I'm using the default CC (Clang) but it also seems to be looking for libgcc_s.so.1. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012, Steve Kargl wrote:
On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote:
On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote:
On 2012-02-21 20:42, Steve Kargl wrote:
...
Yes, /lib comes before /usr/local/lib/gcc46. I suppose
that this is a heads up for gerald@. lang/gcc is used by
the ports collections to build a large number of other
ports, so others are likely to hit this issue.
Does -rpath not help ?
I already mentioned that I can add '-rpath /usr/local/lib/gcc46'
to my various projects. I can also build with -static to avoid
rtld. One can also use LD_LIBRARY_PATH.
The issue seems to be that lang/gcc will be installed after
system start, and 'ldconfig -m' appends new shared libraries
to the hints file. This means that libraries with the same
name but different locations will be found via the order of the
search path in the hints file, and one gets the wrong library.
That is, with the following
troutmask:root[256] ldconfig -r | grep libgcc_s
29:-lgcc_s.1 = /lib/libgcc_s.so.1
723:-lgcc_s.1 = /usr/local/lib/gcc46/libgcc_s.so.1
29 will be found before 723. While I can work around the
issue, lang/gcc is used by a rather large boatload of ports
during the building process and I suspect that a large
number of FreeBSD users use lang/gcc for their everyday
compiler. The question is how do we, the FreeBSD project,
deal with this issue, so that the general user base does not
get hit with it.
There are a few solutions:
1) Set ldconfig_paths in /etc/rc.conf to cause ${PORTSDIR}/lib to
be scanned before /lib and /usr/lib.
2) Use /etc/ld.so.conf to cause ${PORTSDIR}/lib to be scanned
for /lib and /usr/lib.
s/for/before/ ??
3) Add a new option to ldconfig to prepend new libraries to
the hints files and fix the ports to use this option instead
of -m.
You don't want system binaries that want /lib/libgcc_s.so.1
to use /usr/local/lib/gccXX/libgcc_s.so.1, though. Wouldn't
your option 3 do that?
4) Suggestions from people that are brighter than I.
[Not brighter than you, but]
o For our system libgcc, use libcc_s.so.1 (or some other
name) instead of libgcc_s.so.1?
o Change affected ports to use -rpath when building?
--
DE
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/devel/ppl Makefile distinfo pkg-plist ports/devel/ppl/files patch-configure
On Wed, 19 Oct 2011, Chris Rees wrote:
On 19 Oct 2011 02:00, Daniel Eischen deisc...@freebsd.org wrote:
On Wed, 19 Oct 2011, Daniel Eischen wrote:
deischen2011-10-19 00:20:16 UTC
FreeBSD ports repository
Modified files:
devel/pplMakefile distinfo pkg-plist
Removed files:
devel/ppl/files patch-configure
Log:
Upgrade to 0.11.2.
Submitted by: Mark Murray markm_at_fbsd_dot_org
Revision Changes Path
1.27 +5 -6ports/devel/ppl/Makefile
1.11 +2 -2ports/devel/ppl/distinfo
1.2 +0 -21 ports/devel/ppl/files/patch-configure (dead)
1.11 +1141 -1036 ports/devel/ppl/pkg-plist
I just updated the above port and I noticed that the
pkg-plist (both before and after the update) had some
files of the form:
%%PORTDOCSDOCSDIR%%/../pwl
%%PORTDOCSDOCSDIR%%/../pwl/bar/
%%PORTDOCSDOCSDIR%%/../pwl/bar/a
%%PORTDOCSDOCSDIR%%/../pwl/bar/b
When I tried 'make package; make deinstall; pkg_add ...'
I got errors:
share/doc/ppl/../pwl/BUGS: Path contains '..'
share/doc/ppl/../pwl/COPYING: Path contains '..'
share/doc/ppl/../pwl/CREDITS: Path contains '..'
share/doc/ppl/../pwl/ChangeLog: Path contains '..'
...
tar: Error exit delayed from previous errors.
pkg_add: tar extract of /usr/ports/packages/All/ppl-0.10.2_1.tbz failed!
pkg_add: unable to extract '/usr/ports/packages/All/ppl-0.10.2_1.tbz'!
Is there anything wrong with having '..' in the pathname
of files in pkg-plist? Since %%DOCSDIR%% is 'ppl' for this
port, should files installed under pwl just be specified as
this:
%%PORTDOCS%%/pwl/bar
%%PORTDOCS%%/pwl/bar/a
%%PORTDOCS%%/pwl/bar/b
...
and omit %%DOCSDIR%% from their path?
Thanks for any insights.
Depends if there are (or could be) symlinks involved
Thanks for responding! No, there are no symlinks. I
think I have solved it, but not sure that this is the
acceptable way. Please see attached diffs. If they
get removed by the mailer, it is basically just using
PWL_DOC_PREFIX=share/doc/pwl
PLIST_SUB+=PWL_DOC_PREFIX=${PWL_DOC_PREFIX}
in the Makefile and using %%PORTDOCSPWL_DOC_PREFIX%%
in the pkg-plist.
--
DE? work
Index: Makefile
===
RCS file: /home/pcvs/ports/devel/ppl/Makefile,v
retrieving revision 1.27
diff -u -r1.27 Makefile
--- Makefile19 Oct 2011 00:20:16 - 1.27
+++ Makefile19 Oct 2011 03:41:34 -
@@ -19,6 +19,8 @@
BUILD_DEPENDS= gm4:${PORTSDIR}/devel/m4
LIB_DEPENDS= gmp.10:${PORTSDIR}/math/gmp
+PWL_DOC_PREFIX=share/doc/pwl
+
USE_GMAKE= yes
USE_PERL5_BUILD=yes
USE_AUTOTOOLS= libtool
@@ -48,4 +50,6 @@
${WRKSRC}/doc/Makefile.in ${WRKSRC}/Watchdog/doc/Makefile.in
.endif
+PLIST_SUB+=PWL_DOC_PREFIX=${PWL_DOC_PREFIX}
+
.include bsd.port.mk
Index: pkg-plist
===
RCS file: /home/pcvs/ports/devel/ppl/pkg-plist,v
retrieving revision 1.11
diff -u -r1.11 pkg-plist
--- pkg-plist 19 Oct 2011 00:20:16 - 1.11
+++ pkg-plist 19 Oct 2011 03:41:36 -
@@ -1109,79 +1109,79 @@
%%PORTDOCSDOCSDIR%%/ppl-user-c-interface-0.11.2-html/tree.html
%%PORTDOCSDOCSDIR%%/ppl-user-c-interface-0.11.2.pdf
%%PORTDOCSDOCSDIR%%/ppl-user-c-interface-0.11.2.ps.gz
-%%PORTDOCSDOCSDIR%%/../pwl/BUGS
-%%PORTDOCSDOCSDIR%%/../pwl/COPYING
-%%PORTDOCSDOCSDIR%%/../pwl/CREDITS
-%%PORTDOCSDOCSDIR%%/../pwl/ChangeLog
-%%PORTDOCSDOCSDIR%%/../pwl/NEWS
-%%PORTDOCSDOCSDIR%%/../pwl/README
-%%PORTDOCSDOCSDIR%%/../pwl/README.doc
-%%PORTDOCSDOCSDIR%%/../pwl/fdl.pdf
-%%PORTDOCSDOCSDIR%%/../pwl/fdl.ps.gz
-%%PORTDOCSDOCSDIR%%/../pwl/fdl.txt
-%%PORTDOCSDOCSDIR%%/../pwl/gpl.pdf
-%%PORTDOCSDOCSDIR%%/../pwl/gpl.ps.gz
-%%PORTDOCSDOCSDIR%%/../pwl/gpl.txt
-%%PORTDOCSDOCSDIR%%/../pwl/pwl-user-0.8-html/GFDL.html
-%%PORTDOCSDOCSDIR%%/../pwl/pwl-user-0.8-html/GPL.html
-%%PORTDOCSDOCSDIR%%/../pwl/pwl-user-0.8-html/annotated.html
-%%PORTDOCSDOCSDIR%%/../pwl/pwl-user-0.8-html/classParma__Watchdog__Library_1_1Doubly__Linked__Object-members.html
-%%PORTDOCSDOCSDIR%%/../pwl/pwl-user-0.8-html/classParma__Watchdog__Library_1_1Doubly__Linked__Object.html
-%%PORTDOCSDOCSDIR%%/../pwl/pwl-user-0.8-html/classParma__Watchdog__Library_1_1EList-members.html
-%%PORTDOCSDOCSDIR%%/../pwl/pwl-user-0.8-html/classParma__Watchdog__Library_1_1EList.html
-%%PORTDOCSDOCSDIR%%/../pwl/pwl-user-0.8-html/classParma__Watchdog__Library_1_1EList__Iterator-members.html
-%%PORTDOCSDOCSDIR%%/../pwl/pwl-user-0.8-html/classParma__Watchdog__Library_1_1EList__Iterator.html
-%%PORTDOCSDOCSDIR%%/../pwl/pwl-user-0.8-html/classParma__Watchdog__Library_1_1Handler-members.html
-%%PORTDOCSDOCSDIR%%/../pwl/pwl-user-0.8-html/classParma__Watchdog__Library_1_1Handler.html
-%%PORTDOCSDOCSDIR%%/../pwl/pwl-user-0.8-html/classParma__Watchdog__Library_1_1Handler__Flag
Re: cvs commit: ports/devel/ppl Makefile distinfo pkg-plist ports/devel/ppl/files patch-configure
On Wed, 19 Oct 2011, Daniel Eischen wrote: deischen2011-10-19 00:20:16 UTC FreeBSD ports repository Modified files: devel/pplMakefile distinfo pkg-plist Removed files: devel/ppl/files patch-configure Log: Upgrade to 0.11.2. Submitted by: Mark Murray markm_at_fbsd_dot_org Revision Changes Path 1.27 +5 -6ports/devel/ppl/Makefile 1.11 +2 -2ports/devel/ppl/distinfo 1.2 +0 -21 ports/devel/ppl/files/patch-configure (dead) 1.11 +1141 -1036 ports/devel/ppl/pkg-plist I just updated the above port and I noticed that the pkg-plist (both before and after the update) had some files of the form: %%PORTDOCSDOCSDIR%%/../pwl %%PORTDOCSDOCSDIR%%/../pwl/bar/ %%PORTDOCSDOCSDIR%%/../pwl/bar/a %%PORTDOCSDOCSDIR%%/../pwl/bar/b When I tried 'make package; make deinstall; pkg_add ...' I got errors: share/doc/ppl/../pwl/BUGS: Path contains '..' share/doc/ppl/../pwl/COPYING: Path contains '..' share/doc/ppl/../pwl/CREDITS: Path contains '..' share/doc/ppl/../pwl/ChangeLog: Path contains '..' ... tar: Error exit delayed from previous errors. pkg_add: tar extract of /usr/ports/packages/All/ppl-0.10.2_1.tbz failed! pkg_add: unable to extract '/usr/ports/packages/All/ppl-0.10.2_1.tbz'! Is there anything wrong with having '..' in the pathname of files in pkg-plist? Since %%DOCSDIR%% is 'ppl' for this port, should files installed under pwl just be specified as this: %%PORTDOCS%%/pwl/bar %%PORTDOCS%%/pwl/bar/a %%PORTDOCS%%/pwl/bar/b ... and omit %%DOCSDIR%% from their path? Thanks for any insights. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011, Alexey Shuvaev wrote: Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that nsNativeCharsetUtils.o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. Yes, I had this problem also on -current. Does seamonkey build on recent 8.x? libxpcomio_s.a is a static library that has unresolved references to libiconv. I guess I'd expect those references to be resolved with a later -L/usr/local/lib -liconv when building the shared library (libxpcom_core.so), but they are not. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011, Alexander Kabaev wrote: On Sat, 29 Jan 2011 13:21:44 -0500 Alexander Kabaev kab...@gmail.com wrote: On Sat, 29 Jan 2011 13:02:24 -0500 (EST) Daniel Eischen deisc...@freebsd.org wrote: On Sat, 29 Jan 2011, Alexey Shuvaev wrote: Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that nsNativeCharsetUtils.o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. Yes, I had this problem also on -current. Does seamonkey build on recent 8.x? libxpcomio_s.a is a static library that has unresolved references to libiconv. I guess I'd expect those references to be resolved with a later -L/usr/local/lib -liconv when building the shared library (libxpcom_core.so), but they are not. My wild guess: seamonkey tries to hide symbols that are coming from different .o file (this time one from libiconv.a) and that fails with our toolchain. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 -- Alexander Kabaev Follow-up to myself: Nope, the fix to said bug appears in our compiler. Can you make amd64 version of nsNativeCharsetUtils. My amd64 system is a little out of date, but I'll give it a try. If it builds, I'll update to a recent -current and try rebuilding it. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011, Alexey Shuvaev wrote:
And here is the winner:
On Sat, Jan 29, 2011 at 08:32:07AM +0300, Anonymous wrote:
Alexey Shuvaev shuv...@physik.uni-wuerzburg.de writes:
Hello!
It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1].
Examining build log and reproducing it locally, the problem is in the
usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to
produce libxpcom_core.so although -L/usr/local/lib and -liconv
are specified [2]. Examining this further I found that nsNativeCharsetUtils.o
produced with [3] fails to link with libiconv alone too [4] (note
still unresolved libiconv references).
I'm not a compiler/linker guru and do not understand what is happening
here. As a workaroud I use the attached patch which disables the usage
of libiconv in nsNativeCharsetUtils.cpp.
[...]
/usr/bin/ld: aaa: hidden symbol `libiconv_open' isn't defined
/head per r215840 has working -fvisibility=hidden, i.e. config/gcc_hidden.h.
Try following diff, it should enable patching iconv.h wrapper in bsd.gecko.mk
Is someone going to commit this?
@${ECHO_CMD} #pragma GCC system_header ${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} #pragma GCC visibility push(default)
${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} #include \${LOCALBASE}/include/iconv.h\
${MOZSRC}/${subdir}/iconv.h
@${ECHO_CMD} #pragma GCC visibility pop ${MOZSRC}/${subdir}/iconv.h
%%
Index: www/seamonkey2/Makefile
===
RCS file: /a/.cvsup/ports/www/seamonkey2/Makefile,v
retrieving revision 1.315
diff -u -p -r1.315 Makefile
--- www/seamonkey2/Makefile 10 Dec 2010 13:31:12 - 1.315
+++ www/seamonkey2/Makefile 29 Jan 2011 05:22:11 -
@@ -28,11 +28,10 @@ ALL_TARGET= default
MAKE_JOBS_SAFE=yes
MOZ_PIS_SCRIPTS= moz_pis_S50cleanhome
MAKE_ENV= LD_LIBRARY_PATH=${WRKSRC}/dist/bin
-CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include/cairo
+CONFIGURE_ENV= LOCALBASE=${LOCALBASE} CPPFLAGS=-I${LOCALBASE}/include/cairo \
+ ac_cv_func__Unwind_Backtrace=no
USE_GCC= 4.2+
-CONFIGURE_ENV= LOCALBASE=${LOCALBASE}
-
MOZ_EXTENSIONS=default
MOZ_OPTIONS+= --with-default-mozilla-five-home=${PREFIX}/lib/${MOZILLA} \
--enable-svg \
@@ -121,11 +120,6 @@ post-patch:
${WRKSRC}/mozilla/storage/build/Makefile.in
@${REINPLACE_CMD} -e
'/accessibility.typeaheadfind.enablesound/s/true/false/' \
${WRKSRC}/mozilla/modules/libpref/src/init/all.js
- @${REINPLACE_CMD} -e 's|iconv.h|\${LOCALBASE}/include/iconv.h\|g' \
- ${WRKSRC}/configure \
- ${WRKSRC}/mozilla/configure \
- ${WRKSRC}/mozilla/intl/uconv/native/nsNativeUConvService.cpp \
- ${WRKSRC}/mozilla/xpcom/io/nsNativeCharsetUtils.cpp
@${REINPLACE_CMD} -e 's|libgnome-2.so.0|libgnome-2.so|' \
${WRKSRC}/mozilla/toolkit/xre/nsNativeAppSupportUnix.cpp \
${WRKSRC}/mozilla/modules/libpr0n/decoders/icon/gtk/nsIconChannel.cpp
%%
This patch did it!
I have successfully rebuilt www/seamonkey2 with the above patch
applied to port's Makefile (and without my previous workaround).
Everything works!
As this hidden/visibility symbols are beyond my C/CPP foo,
I am leaving the final decision for the experts :)
Thanks,
Alexey.
___
freebsd-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
--
DE
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: The state of Ada (Re: FreeBSD unmaintained ports which are currently scheduled for deletion)
On Fri, 8 Jan 2010, John Merryweather Cooper wrote: Well, the compiler needs to be upgraded to the latest version. Linux gets a compiler out of the box, but we have to bend one to shape. Most things stay the same, but there are always subtle differences. I'd be happy to help do this (as I'm currently unemployed), but I'm also going through a divorce. You can contact me more directly at j.m.cooper at borgsdemons.com. All the ports that I saw that were broken, were broken *because* the compiler (lang/gnat) was updated. Those ports seemed to be vastly out of date and didn't build with the latest GPL gnat from ACT. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Improving Ada support on FreeBSD and in the ports system
On Wed, 11 Nov 2009, freebsd-po...@coreland.ath.cx wrote: On 2009-11-08 00:06:16, Daniel Eischen wrote: Patches for amd64 support are also welcome. I thought you were going to do a port for GNAT-gpl amd64? 'Lo. I just tried to compile the vanilla GNAT-GPL 2009 sources today and came across the following error: /gnat/gpl-2009/src/GNAT/obj/./gcc/xgcc -B/gnat/gpl-2009/src/GNAT/obj/./gcc/ -B/usr/local/x86_64-unknown-freebsd7.2/bin/ -B/usr/local/x86_64-unknown-freebsd7.2/lib/ -isystem /usr/local/x86_64-unknown-freebsd7.2/include -isystem /usr/local/x86_64-unknown-freebsd7.2/sys-include -g -fkeep-inline-functions -O2 -O2 -g -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/. -I../../../src/libgcc/../gcc -I../../../src/libgcc/../include -DHAVE_CC_TLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c ../../../src/libgcc/../gcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS In file included from ../../../src/libgcc/../gcc/unwind-dw2.c:338: ../../../src/libgcc/../gcc/config/i386/freebsd-unwind.h: In function ‘x86_freebsd_fallback_frame_state’: I guess I'm confused. Why is it using config/i386 if it is trying to build x86_64? Check the port to see if it forces target i386... -- DE___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Improving Ada support on FreeBSD and in the ports system
On Wed, 11 Nov 2009, freebsd-po...@coreland.ath.cx wrote: On 2009-11-11 14:48:35, Daniel Eischen wrote: /gnat/gpl-2009/src/GNAT/obj/./gcc/xgcc -B/gnat/gpl-2009/src/GNAT/obj/./gcc/ -B/usr/local/x86_64-unknown-freebsd7.2/bin/ -B/usr/local/x86_64-unknown-freebsd7.2/lib/ -isystem /usr/local/x86_64-unknown-freebsd7.2/include -isystem /usr/local/x86_64-unknown-freebsd7.2/sys-include -g -fkeep-inline-functions -O2 -O2 -g -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/. -I../../../src/libgcc/../gcc -I../../../src/libgcc/../include -DHAVE_CC_TLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c ../../../src/libgcc/../gcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS In file included from ../../../src/libgcc/../gcc/unwind-dw2.c:338: ../../../src/libgcc/../gcc/config/i386/freebsd-unwind.h: In function ‘x86_freebsd_fallback_frame_state’: I guess I'm confused. Why is it using config/i386 if it is trying to build x86_64? Check the port to see if it forces target i386... Oh, this wasn't your port, this was just the vanilla source package taken from libre.adacore.com. The port has some extra complexity (downloading bootstrap binaries, etc) that I wanted to avoid until I knew it actually built without (much) modification. Oh, I see. Did you configure it with host=i386-unknown-freebsd and target=amd64-unknown-freebsd (or is it x86_64?)? It looks like libgcc might not have support for x86_64 FreeBSD?? -- DE___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Improving Ada support on FreeBSD and in the ports system
On Wed, 11 Nov 2009, freebsd-po...@coreland.ath.cx wrote: On 2009-11-11 15:07:36, Daniel Eischen wrote: Oh, I see. Did you configure it with host=i386-unknown-freebsd and target=amd64-unknown-freebsd (or is it x86_64?)? It looks like libgcc might not have support for x86_64 FreeBSD?? Full configure line was: ../src/configure \ --enable-languages=c,ada \ --disable-libada \ --host=x86_64-unknown-freebsd7.2 \ --target=x86_64-unknown-freebsd7.2 \ --build=x86_64-unknown-freebsd7.2 ...which is more or less what I build GCC with. I would try it piecemeal. Try just building the target compiler (--host=i386-unknown-freebsd7.2 and --target=x86_64-unknown-freebsd7.2). It does seem as if support is missing - perhaps removed by AdaCore? The system compiler is at 4.2.1 on my AMD64 machine, so I'm guessing that support was there and was removed? I think Adacore takes a snapshot of gcc at the time, it might not be the actual release. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Improving Ada support on FreeBSD and in the ports system
On Sat, 7 Nov 2009, freebsd-po...@coreland.ath.cx wrote: [Apologies for the possible double-post, I mistyped the From: address] Hello. It's come to my attention that the FreeBSD ports system has very poor support for Ada and Ada software in general. A quick search on Freshports for 'Ada' shows the following packages: devel/adabooch- No dependencies registered! devel/adacurses - lang/gnat devel/adasdl - lang/gnat net/adasockets- lang/gnat (broken) textproc/xmlada - lang/gnat-gcc41 (broken) textproc/xmlada-gps - lang/gnat (broken) x11-toolkits/gtkada - lang/gnat (broken) x11-toolkits/gtkada-devel - lang/gnat (broken) x11-toolkits/gtkada-gcc - lang/gnat-gcc41 (broken) x11-toolkits/gtkada-gps - lang/gnat (broken) I'm aware there are more packages than this in the ports sytem. The situation doesn't get any better the more you read... The problems any user of Ada on FreeBSD faces are: PROBLEM 1. Lack of packages (as shown above) Of the 10 packages listed, only three of those (maybe two) actually work. The packages are way out of date and don't build with the newer GNAT's. Patches welcome. PROBLEM 2. No choice in the use of compiler The Ada world is essentially divided between the GCC version of GNAT that can produce executables not tainted by the GPL (GNAT-FSF) and the GPL version (GNAT-GPL) from AdaCore which can't. Debian, for example, only uses GNAT-FSF (but one can, of course, just download GNAT-GPL from AdaCore and use it without issue). PROBLEM 3. Compiler version chaos and lack of architecture support We have: lang/gnat (GPL 2009 version, i386 only) Patches for amd64 support are also welcome. I thought you were going to do a port for GNAT-gpl amd64? -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: -pthread propagation
On Thu, 2 Apr 2009, Dmitry Marakasov wrote:
Hi!
I have a question about -pthread. Imagine the situation where one port
installs shared library that uses threads, and other port links with
this library. A question: should the second port explicitely add
-pthread to linker flags?
Yes.
For example, graphics/ilmbase is built with pthread support by default,
but it's shared libraries are not linked with -pthread:
% ldd /usr/local/lib/libIlmThread.so
/usr/local/lib/libIlmThread.so:
libIex.so.6 = /usr/local/lib/libIex.so.6 (0x2819c000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x2830)
libm.so.5 = /lib/libm.so.5 (0x281ad000)
libc.so.7 = /lib/libc.so.7 (0x2808b000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x281c6000)
no libthr.so mention. Thus,
% gcc helloworld.cc -lIlmThread -L/usr/local/lib
/usr/local/lib/libIlmThread.so: undefined reference to `pthread_create'
I assume this should be fixed in ilmbase instead of all dependent ports
(for example, graphics/nvidia-texture-tools and graphics/devil, which
supports the former), am I right? Btw, libIlmThread.la _does_ have
-pthread in dependency_libs.
Yes, all ports that use libraries that create threads on
their behalf should use -pthread.
However, I've encountered situations where linking with library
linked with -pthread will succeed, but the resulting binary will not
be broken. Example is games/battletanks:
This is probably because libc contains some simple thread
wrappers (mostly lock related stuff). They go unused unless
a thread is created (and libthr is explicitly brought in),
in which case those wrappers are overridden by libthr.
When built as is (note that it has ${PTHREAD_LIBS} explicitely added to
LDFLAGS), it runs without problems. However, if you remove
${PTHREAD_LIBS}, it'll still build successfully, but won't run:
% bt
[03:04:45.449][src/main.cpp:44] [notice] starting up... version: 5800 beta
[03:04:45.449][src/main.cpp:46] [notice] mem avail: -1 mb
terminate called after throwing an instance of
'__gnu_cxx::__concurrence_lock_error'
what(): __gnu_cxx::__concurrence_lock_error
[1]58620 abort (core dumped) bt
I think that's linked with static variable initialization - it should
be protected with a mutex in threaded environment, but it doesn't happen
correctly when linking without -pthread, even if with -lthr.
It is possible for a library to be thread-aware and thread-safe.
In this case it can play pragma weak games with pthread_create
and only use locks if pthread_create resolves to a non-null
pointer.
I'll be really grateful if someone explains what really happens when
using -lpthread, and what happens in the above mentioned error case
(cc'ing hackers@).
So should -pthread be forced in ldflags
1) Only in ports that explicitely use threads
2) In all ports that link with -lthr implicitely, including through
other ports?
It depends, libraries can be made thread-safe/aware as
above, and both threaded and non-threaded applications
can link with them just fine. Assuming those libraries
are smart about how they use the locking mechanisms,
and never use them unless they know that pthread_create
is present (or some other symbol not present in libc,
but present in libthr).
But for libraries that create threads, applications must
also link with -pthread (or -lpthread).
If you can understand it, you can see
src/contrib/gcc/gthr-posix.h for how libgcc is
thread-aware. A comment from that file:
/* On Solaris 2.6 up to 9, the libc exposes a POSIX threads
interface even if -pthreads is not specified. The
functions are dummies and most return an error value.
However pthread_once returns 0 without invoking the routine
it is passed so we cannot pretend that the interface is
active if -pthreads is not specified. On Solaris 2.5.1,
the interface is not exposed at all so we need to play the
usual game with weak symbols. On Solaris 10 and up, a
working interface is always exposed. On FreeBSD 6 and
later, libc also exposes a dummy POSIX threads interface,
similar to what Solaris 2.6 up to 9 does. FreeBSD =
700014 even provides a pthread_cancel stub in libc, which
means the alternate __gthread_active_p below cannot be used
there. */
--
DE
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: editors/nedit font weirdness
On Fri, 20 Feb 2009, Stephen Hurd wrote: I recently updated my ports and rebuilt and now any time I try to run nedit, I get a handfull of Cannot load font. errors followed by a segfault. However, *if* I have xfontsel running, I only get a few warnings, then nedit runs normally. Maybe some fonts have been removed? I have performed a portupgrade -fRr editors/nedit to no avail. The warnings I get when xfontsel is running are: Cannot convert string -*-courier-medium-r-normal-*-*-120-*-*-*-iso8859-1 to type FontStruct Cannot convert string -*-courier-bold-r-normal-*-*-120-*-*-*-iso8859-1 to type FontStruct Cannot convert string -*-courier-medium-o-normal-*-*-120-*-*-*-iso8859-1 to type FontStruct And when xfontsel is *not* running, I get: Cannot convert string -*-courier-medium-r-normal-*-*-120-*-*-*-iso8859-1 to type FontStruct Unable to load any usable ISO8859 font Name: FONTLIST_DEFAULT_TAG_STRING Class: XmRendition Conversion failed. Cannot load font. [ ... ] I haven't upgraded yet to the new Xorg, and given all the problems I've seen recently, I don't have any plans to in the near future. I suspect this is probably somehow related to that, but I don't really know other than I don't see this problem on any of my systems with earlier Xorg ports. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: How to break the bootstrapping chain
On Fri, 8 Dec 2006, Karel Miklav wrote: I'm trying to maintain the gnat-gcc* Ada compiler ports, currently there are gnat-gcc34 and 41. I'd like to introduce newer versions, and retire experimental 34, which is built from an ancient binary which requires FreeBSD 4 compatibility. I'd like to know: 1. what do I have to do that gnat-gcc packages will appear on FreeBSD FTP sites? 2. can I use one of FreeBSD packages to bootstrap others or do I have to somehow provide my own binary? In case I was not clear enough: the GNAT compiler can only be bootstrapped with another GNAT. If I base the procedure on a FreeBSD package, I can no longer provide the port for that package ... or do I? Damn, who invented this chicken and egg thing :) You'll have to do the same thing as the lang/gnat port and provide your own bootstrapping compiler. No matter what you do (*), it will require FreeBSD-X compat. AFAIK, we are currently supporting FreeBSD 5, 6, and 7, so the bootstrap should be based on FreeBSD-5, so it can work for 6 and 7 as well. If it is based on 6 or 7, then it will not be able to work on the other two. (*) The only way you can avoid this, is to provide 3 different bootstrap compilers (one for 5, 6, and 7) and teach the port to depend on the appropriate bootstrapper. -- DE ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
