mpich2 installation problem
See `config.log' for more details.
=== Script configure failed unexpectedly.
Please report the problem to po...@freebsd.org [maintainer] and attach the
/usr/ports/net/mpich2/work/mpich2-1.2.1p1/config.log including the output
of the failure of your make command. Also, it might be a good idea to
provide
an overview of all packages installed on your system (e.g. an `ls
/var/db/pkg`).
*** Error code 1
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
generated by GNU Autoconf 2.63. Invocation command line was
$ ./configure --enable-romio --enable-sharedlibs=gcc
--docdir=/usr/local/share/doc/mpich2 --x-includes=/usr/local/include
--x-libraries==/usr/local/lib --without-java --with-pmi=simple --with-pm=mpd
--x-libraries=/usr/local/lib --x-includes=/usr/local/include
--prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/
--build=i386-portbld-freebsd8.0
## - ##
## Platform. ##
## - ##
hostname = cl01.lan
uname -m = i386
uname -r = 8.0-RELEASE
uname -s = FreeBSD
uname -v = FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009
r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
/usr/bin/uname -p = i386
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /sbin
PATH: /bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /usr/games
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /root/bin
## --- ##
## Core tests. ##
## --- ##
configure:4145: checking for gcc
configure:4172: result: gcc44
configure:4404: checking for C compiler version
configure:4412: gcc44 --version 5
gcc44 (GCC) 4.4.5 20100518 (prerelease)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:4416: $? = 0
configure:4423: gcc44 -v 5
Using built-in specs.
Target: i386-portbld-freebsd8.0
Configured with: ./../gcc-4.4-20100518/configure --disable-nls
--libdir=/usr/local/lib/gcc44 --libexecdir=/usr/local/libexec/gcc44
--program-suffix=44 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc44/include/c++/
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local
--with-system-zlib --prefix=/usr/local --mandir=/usr/local/man
--infodir=/usr/local/info/gcc44 --build=i386-portbld-freebsd8.0
Thread model: posix
gcc version 4.4.5 20100518 (prerelease) (GCC)
configure:4427: $? = 0
configure:4434: gcc44 -V 5
gcc44: '-V' option must have argument
configure:4438: $? = 1
configure:4461: checking for C compiler default output file name
configure:4483: gcc44 -O2 -pipe -Wl,-rpath=/usr/local/lib/gcc44
-fno-strict-aliasing -I/usr/local/include
-I/usr/ports/net/mpich2/work/mpich2-1.2.1p1/src/openpa/src
-I/usr/ports/net/mpich2/work/mpich2-1.2.1p1/src/openpa/src -L/usr/local/lib
-lexecinfo -pthread conftest.c 5
/usr/local/bin/ld: cannot find -lexecinfo
collect2: ld returned 1 exit status
configure:4487: $? = 1
configure:4525: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| #define USE_SMP_COLLECTIVES 1
| #define HAVE_ERROR_CHECKING MPID_ERROR_LEVEL_ALL
| #define MPICH_ERROR_MSG_LEVEL MPICH_ERROR_MSG_ALL
| #define USE_LOGGING MPID_LOGGING_NONE
| #define HAVE_RUNTIME_THREADCHECK 1
| #define MPICH_THREAD_LEVEL MPI_THREAD_MULTIPLE
| #define USE_THREAD_IMPL MPICH_THREAD_IMPL_GLOBAL_MUTEX
| #define MPIU_THREAD_GRANULARITY MPIU_THREAD_GRANULARITY_GLOBAL
| #define MPIU_HANDLE_ALLOCATION_METHOD MPIU_HANDLE_ALLOCATION_MUTEX
| #define MPIU_THREAD_REFCOUNT MPIU_REFCOUNT_NONE
| #define HAVE_ROMIO 1
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:4531: error: in `/usr/ports/net/mpich2/work/mpich2-1.2.1p1':
configure:4533: error: C compiler cannot create executables
See `config.log' for more details.
## ##
## Cache variables. ##
## ##
ac_cv_env_CCC_set=''
ac_cv_env_CCC_value=''
ac_cv_env_CC_set=set
ac_cv_env_CC_value=gcc44
ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value='-O2 -pipe -Wl,-rpath=/usr/local/lib/gcc44
-fno-strict-aliasing'
ac_cv_env_CPPFLAGS_set=set
ac_cv_env_CPPFLAGS_value=-I/usr/local/include
ac_cv_env_CPP_set=''
ac_cv_env_CPP_value=''
ac_cv_env_CXXCPP_set=''
ac_cv_env_CXXCPP_value=''
ac_cv_env_CXXFLAGS_set=set
ac_cv_env_CXXFLAGS_value='-O2 -pipe -Wl,-rpath=/usr/local/lib/gcc44
-fno-strict-aliasing'
ac_cv_env_CXX_set=set
ac_cv_env_CXX_value=g++44
ac_cv_env_F77_set=set
ac_cv_env_F77_value=gfortran44
ac_cv_env_F90FLAGS_set=set
ac_cv_env_F90FLAGS_value=-O
[CFT]: pkg_add_it - new version
Hello, I'm working on a new version of a tool I started some time ago - pkg_add_it. Basically what this tool is doing is that it allows the user to interactively install packages, selecting the needed ones. It's not a package installer by any means, but gives a frontend to the existing pkg_* tools. Currently it is only working with pkg_add(1), in order to install new packages, but I'm planning to further develop it, so it is also able to work with all the other pkg_* tools. I was working on the new version of the tool for the past few days, and now I got it completely rewritten and added a lot of new features, so now the tool is able to: - install packages from a local directory, searching by package pattern - install packages from a remote server, searching by package pattern from INDEX - the remote package install can be very useful to people that prefer to install from packages, since you do not really need to have ports tree installed at all. All you need is a single INDEX file. - a configuration file is used, that configures most of the job the tool is doing. - the tool can also be used to browse the index, selecting only the information you need, so on systems without a browser installed, you can still view the package information - dependencies, www, maintainers, etc... - i suppose this tool would of help for the novice users, when they need to find a certain package What I want to do now is to get this version to some stable phase, and then I'm planning to start a fork of it with ncurses, that will not be limited only to installation of packages, but also deinstall and upgrade of packages. The way it is currently developed will also allow for easier integration with the existing package tools pkg_*, portmaster, portupgrade, etc.., since everything will be defined in just one single configuration file. What I would like to ask you, if you have some free time to spend on having a look at the program. Any feedback on how the program can be further improved, adding of new features on it or anything else, are greatly appreciated. To install the program: 1) git clone git://git.unix-heaven.org/public/pkg_add_it.git 2) cd pkg_add_it make 3) copy the configuration file pkg_add_it.conf to /usr/local/etc or just use the -f option from the command-line 4) the executable is placed in the pkg_add_it directory The changelog can be seen at: http://git.unix-heaven.org/gitweb.cgi?p=pkg_add_it.git;a=summary I've also uploaded a couple of screenshots of the program in case you want to see how it's working: http://www.unix-heaven.org/pkg_add_it-gfx/ Please note that the manual page pkg_add_it(1) is still not updated, I'm working on this. For example usage, please have a look at the help output of the program. The sample configuration file is also well documented, so it explains everything about a specific option. Thank you and regards, Marin -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ ___ 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
cannot build sysutils/kdelibs3
Apparently ASN1_METHOD has long been deprecated and now
removed. No idea what to do about it. I cannot switch back
to base system ssl, without breaking a lot of other ports.
/bin/sh /usr/local/bin/libtool --silent --tag=CXX --mode=compile c++
-DHAVE_CONFIG_H -I. -I../.. -I../../dcop -I../../kdecore -I../../kjs
-I../../kdecore/network -I../../kwallet/client -I../../dcop -I../../libltdl
-I../../kdefx -I../../kdecore -I../../kdecore -I../../kdecore/network
-I../../kdeui -I../../kio -I../../kio/kio -I../../kio/kfile -I../..
-I/usr/local/include -I/usr/local/include -I/usr/local/include -D_THREAD_SAFE
-pthread -DQT_THREAD_SUPPORT -I/usr/local/include -I/usr/local/include
-I/usr/local/include -D_GETOPT_H -D_THREAD_SAFE -Wno-long-long -Wundef -Wall
-W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O2 -pipe -march=nocona
-fno-strict-aliasing -Wno-non-virtual-dtor -fno-exceptions -fno-check-new
-fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT
-DQT_NO_TRANSLATION -MT kssl.lo -MD -MP -MF .deps/kssl.Tpo -c -o kssl.lo
kssl.cc
In file included from kssl.cc:47:
./kopenssl.h:453: error: ISO C++ forbids declaration of 'ASN1_METHOD' with no
type
./kopenssl.h:453: error: expected ';' before '*' token
./kopenssl.h:526: error: expected ';' before '(' token
./kopenssl.h:532: error: 'STACK' has not been declared
./kopenssl.h:538: error: 'STACK' has not been declared
./kopenssl.h:544: error: expected ';' before '(' token
./kopenssl.h:550: error: ISO C++ forbids declaration of 'STACK' with no type
./kopenssl.h:550: error: expected ';' before '*' token
./kopenssl.h:556: error: 'STACK' has not been declared
./kopenssl.h:562: error: ISO C++ forbids declaration of 'STACK' with no type
./kopenssl.h:562: error: expected ';' before '*' token
./kopenssl.h:828: error: ISO C++ forbids declaration of 'STACK' with no type
./kopenssl.h:828: error: expected ';' before '*' token
./kopenssl.h:829: error: 'STACK' has not been declared
kssl.cc: In member function 'void KSSL::setPeerInfo()':
kssl.cc:616: error: 'class KOpenSSLProxy' has no member named 'sk_dup'
gmake[5]: *** [kssl.lo] Error 1
gmake[5]: Leaving directory
`/usr/obj/mobileKamikaze.norad/amd64/usr/ports/x11/kdelibs3/work/kdelibs-3.5.10/kio/kssl'
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory
`/usr/obj/mobileKamikaze.norad/amd64/usr/ports/x11/kdelibs3/work/kdelibs-3.5.10/kio/kssl'
gmake[3]: *** [all] Error 2
gmake[3]: Leaving directory
`/usr/obj/mobileKamikaze.norad/amd64/usr/ports/x11/kdelibs3/work/kdelibs-3.5.10/kio/kssl'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory
`/usr/obj/mobileKamikaze.norad/amd64/usr/ports/x11/kdelibs3/work/kdelibs-3.5.10/kio'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/usr/obj/mobileKamikaze.norad/amd64/usr/ports/x11/kdelibs3/work/kdelibs-3.5.10'
gmake: *** [all] Error 2
*** Error code 1
Stop in /usr/ports/x11/kdelibs3.
=== make failed for x11/kdelibs3
=== Aborting update
___
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: mpich2 installation problem
PA Zolczynski wrote: ... configure:4483: gcc44 -O2 -pipe -Wl,-rpath=/usr/local/lib/gcc44 -fno-strict-aliasing -I/usr/local/include -I/usr/ports/net/mpich2/work/mpich2-1.2.1p1/src/openpa/src -I/usr/ports/net/mpich2/work/mpich2-1.2.1p1/src/openpa/src -L/usr/local/lib -lexecinfo -pthread conftest.c 5 /usr/local/bin/ld: cannot find -lexecinfo collect2: ld returned 1 exit status ... ac_cv_env_LDFLAGS_value='-L/usr/local/lib -lexecinfo -pthread' ... LDFLAGS='-L/usr/local/lib -lexecinfo -pthread' The configure script is breaking because you're passing a library from devel/libexecinfo in the LDFLAGS, and the linker can't find it. Is the library intact, and registered in the linker hints file (that is, is the output of 'ldconfig -vr | egrep execinfo' correct?)? On top of that, the dmesg output at the bottom of your message shows some disk- and swap-related problems that should concern you. Is your hard drive in good condition? How about your memory? Is your system properly configured? b. ___ 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
textproc/iso8879: tinderbox error
hello.
there was an error while trying to make package on my tinderbox:
WRKDIR The port is attempting to change something outside ${WRKDIR}.
See handbook
(http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-wrkdir.html)
for details.
here is the log:
building iso8879-1986_2 in directory /usr/local/tinderbox/8.0-RELEASE-p2
build started at Sat Jun 5 19:45:55 UTC 2010
port directory: /usr/ports/textproc/iso8879
building for: 8.0-RELEASE-p2 i386
maintained by: kuriy...@freebsd.org
ident warning: no id keywords in /usr/ports/textproc/iso8879/Makefile
Makefile ident:
prefixes: LOCALBASE=usr/local PREFIX=/usr/local
Begin Configuration:
---Begin Environment---
ARCH=i386
PACKAGE_BUILDING=1
USER=root
CCACHE_DIR=
BRANCH=RELEASE-p2
HOST_WORKDIR=
CCACHE_NOLINK=1
BATCH=1
OLDPWD=/
HOME=/root
LOG_DIRECTORY=
LOG_DOCOPY=0
JOBS_NUMBER=2
PKGZIPCMD=bzip2
HAVE_MOTIF=1
FTP_TIMEOUT=900
HTTP_TIMEOUT=900
pb=/usr/local/tinderbox
DISTFILE_CACHE=/usr/ports/distfiles
OSREL=8.0
TINDERD_LOGFILE=/dev/null
PORTOBJFORMAT=elf
WRKDIRPREFIX=/work
DISTDIR=/tmp/distfiles
DISTCACHE=/distcache
CCACHE_LOGFILE=
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
PACKAGES=/tmp/packages
TIMEOUT=7200
PKGSUFFIX=.tbz
OSVERSION=800107
__DSVERSION__=3.2.1
OPTIONS_ENABLED=0
TINDERD_SLEEPTIME=120
UNAME_n=tinderbox.ipigto.rimed.cu
__MKLVL__=1
CCACHE_JAIL=0
LOCALBASE=/usr/local
DISTFILE_URI=
CCACHE_MAX_SIZE=2G
X_WINDOW_SYSTEM=xorg
MASTER_SITE_OVERRIDE=file:///distcache/${DIST_SUBDIR}/
OPTIONS_DIR=
UNAME_r=8.0-RELEASE-p2
USA_RESIDENT=YES
UNAME_s=FreeBSD
PARALLEL_PACKAGE_BUILD=1
PWD=/usr/ports/textproc/iso8879
UNAME_v=FreeBSD 8.0-RELEASE-p2 #0: Sat Jun 5 14:25:46 CDT 2010
r...@tinderbox.ipigto.rimed.cu:/usr/src/sys/magic/kernel/path
FTP_PASSIVE_MODE=yes
CCACHE_ENABLED=0
INDEXFILE=INDEX-8
---End Environment---
---Begin OPTIONS List---
---End OPTIONS List---
End Configuration.
FETCH_DEPENDS=
PATCH_DEPENDS=
EXTRACT_DEPENDS=
BUILD_DEPENDS=unzip-6.0.tbz
RUN_DEPENDS=xmlcatmgr-2.2.tbz
add_pkg
phase 1: make checksum
=== License check disabled, port has not defined LICENSE
= isoENTS.zip doesn't seem to exist in /tmp/distfiles/.
= Attempting to fetch from file:///distcache//.
isoENTS.zip 20 kB 1198 kBps
= MD5 Checksum OK for isoENTS.zip.
= SHA256 Checksum OK for isoENTS.zip.
phase 2: make extract
add_pkg
=== License check disabled, port has not defined LICENSE
=== Extracting for iso8879-1986_2
= MD5 Checksum OK for isoENTS.zip.
= SHA256 Checksum OK for isoENTS.zip.
phase 3: make patch
add_pkg
=== Patching for iso8879-1986_2
phase 4: make build
add_pkg unzip-6.0.tbz
adding dependencies
pkg_add unzip-6.0.tbz
=== iso8879-1986_2 depends on executable: unzip - found
=== Configuring for iso8879-1986_2
phase 5: make test
make: don't know how to make regression-test(continuing)
phase 6: make install
add_pkg xmlcatmgr-2.2.tbz
adding dependencies
pkg_add xmlcatmgr-2.2.tbz
+ Creating /usr/local/share/sgml/catalog
+ Registering CATALOG catalog.ports (SGML)
+ Creating /usr/local/share/sgml/catalog.ports
+ Creating /usr/local/share/xml/catalog
+ Registering nextCatalog catalog.ports (XML)
+ Creating /usr/local/share/xml/catalog.ports
The following catalogs are installed:
1) ${PREFIX}/share/sgml/catalog
The top level catalog for SGML stuff. It is not changed
by any ports/packages except textproc/xmlcatmgr.
2) ${PREFIX}/share/sgml/catalog.ports
This catalog is for handling SGML stuff installed under
${PREFIX}/share/sgml. It is changed by ports/packages.
3) ${PREFIX}/share/xml/catalog
The top level catalog for XML stuff. It is not changed
by any ports/packages except textproc/xmlcatmgr.
4) ${PREFIX}/share/xml/catalog.ports
This catalog is for handling XML stuff installed under
${PREFIX}/share/xml. It is changed by ports/packages.
=== Installing for iso8879-1986_2
=== iso8879-1986_2 depends on file: /usr/local/bin/xmlcatmgr - found
=== Generating temporary packing list
=== Checking if textproc/iso8879 already installed
Archive: /tmp/distfiles/isoENTS.zip
checkdir: cannot create extraction directory: c
Read-only file system
*** Error code 2
Stop in /a/ports/textproc/iso8879.
build of /usr/ports/textproc/iso8879 ended at Sat Jun 5
Re: Ccache warning
On 06/04/10 22:24, Denny Lin wrote: Hi, I saw this warning about devel/ccache a while ago: Any time you change CC/CXX you need to reinstall devel/libtool15 or you will run in to problems. This was added a long time ago, so I'm wondering if this is still necessary (should be devel/libtool22 now). If that's true it should be added to http://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/index.html. Can anyone comment authoritatively? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ 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: Ccache warning
On 05/06/2010 22:49, Doug Barton wrote: On 06/04/10 22:24, Denny Lin wrote: Hi, I saw this warning about devel/ccache a while ago: Any time you change CC/CXX you need to reinstall devel/libtool15 or you will run in to problems. This was added a long time ago, so I'm wondering if this is still necessary (should be devel/libtool22 now). If that's true it should be added to http://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/index.html. Can anyone comment authoritatively? I've been using ccache for years without bothering about this. The only problems are caused by ports that cannot deal with spaces in CC/CXX (~2% of my installed ports). -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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
FreeBSD Port: squeezeboxserver-7.5.0_1
Hi, I've been using this port for some years to power my Squeezebox devices - thanks for keeping it up to date. However, the latest update has killed my installation totally - first it would not scan my music, and after upgrading perl perl module ports I can no longer start the squeezebox server at all: odin# /usr/local/etc/rc.d/squeezeboxserver start Starting squeezeboxserver. The following modules failed to load: YAML::Syck *** NOTE: Please use the buildme.sh script located here: http://svn.slimdevices.com/repos/slim/7.5/trunk/vendor/CPAN/ If 7.5 is outdated by the time you read this, Replace 7.5 with the major version of Squeezebox Server you are running. *** Exiting.. I'm running the latest 5.8 perl from the ports, and seem to be able to load modules from the command line: odin# perl use YAML::Syck Any idea how I should investigate this? I've tried downloading various versions of the server from slimdevices.com, but to no avail. It either won't run at all, or won't scan any music with DBI:: errors. I did notice the port is not downloading the FreeBSD-specific tarball from slimdevices (it uses the NOCPAN one). I appreciate you're not a helpdesk, but I'm not sure where else to go with this - none of the slimdevices forums seem to have much FreeBSD stuff on them. If there's a list that might help, I'd be grateful if you could point me to it. Regards, Mark ___ 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: devel/gettext further update
On Fri, 4 Jun 2010 09:20:48 + b. f. bf1...@googlemail.com wrote: Alexander Leidinger wrote: Quoting Doug Barton dougb at FreeBSD.org (from Thu, 03 Jun 2010 11:29:01 -0700): On 06/03/10 05:39, Matthias Andree wrote: Am 03.06.2010 13:30, schrieb Andrey Chernov: security/libksba security/libgcrypt (they use libgpg-error) So libgpg-error needs to be bumped, but why do things that don't like directly with gettext need it? One of the major benefits of shared libraries is to avoid pointless recompiling. The reason (for those interested) is explained here: http://www.leidinger.net/blog/2010/06/03/direct-indirect-and-explicit-dependencies-in-progamsports/ Just for the record, the useful ports/Tools/scripts/explicit_lib_depends.sh, described and used in your link above, may _not_ find libraries that: -- are needed, but were intended to be statically linked; Correct. If you are of a way how to detect it after the fact, feel free to share the info here. -- are needed, but loaded via dlopen(3) and friends (this is noted in a comment in ports/Tools/scripts/neededlibs.sh ); Correct. The goal for the scripts are to find entries for LIB_DEPENDS. A static lib is a BUILD_DEPEND, not a LIB_DEPEND, and something which is opened via dlopen() is typically not a LIB_DEPEND but a RUN_DEPEND (it is the other way around and the stuff which is dlopen()en depends upon what is dlopen()ing it). Additionally if a something is using dlopen(), it should give sensible error messages when it does not work, so instead of a cryptic error message which not everyone understands, there should be (yes, I know, this is an idealistic POV) an error message even your mother can understand. I have to tell that those scripts are far from finished, the heuristic of files to look at needs to be improved, and the translation into ports-framework variable (like GNOME and X11 ones) needs to be written. I didn't continue with this back when I was committing those scripts, as the 3rd party software was far away from a state which would made it really useful (indirect dependencies show up in runs of the scripts, but they are not really welcome in our ports). -- are needed, and dynamically linked in the usual way, but are not referenced in any ELF DT_NEEDED tags. These tags are optional, not mandatory, in the System V ABI, and they can be missing for a number of reasons. They may not be present in a pre-compiled binary. Or, for example. because some ports make shared libraries by converting static archives into shared libraries with the linker, the tags can sometimes be missing for those libraries. Also, some ports use a version of gcc4* wired to devel/binutils, but then directly invoke some portion of the older base system binutils. I've seen this lead to missing tags in the past. Apart from the fact that I did not know that, do you know which ports in the FreeBSD ports collection show this problem? Is there another way to find this info in then? Bye, Alexander. ___ 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: Direct or indirect libdependencies (using the libintl.so.8 case)
On Fri, 04 Jun 2010 15:35:06 +0200 Jan Henrik Sylvester m...@janh.de
wrote:
I have checked one of the missing dependencies with
explicit_lib_depends.sh, but it did not show up, because
explicit_lib_depends.sh makes some assumptions upon were binaries
reside that are not true in this case:
The heuristics are far from perfect. I just took the obvious ones. As
the scripts are intended to write out values for LIB_DEPENDS, and the
fact that indirect dependencies shall not be recorded there, the
scripts where not useful when I wrote them (I noticed this after
writting as much as you can see in the ports collection), and are still
not useful because indirect dependencies are still recorded in libs
and programs. For this reason I did not invest more time in improving
which parts of a pkg-plist to check or not.
Feel free to submit imrpovements to the scripts.
[recording indirect deps or not]
Considering the few responses my posting got, either not many see the
need to reach an agreement or the posing was not clear or not concise
enough. (It is not the first time I tried to raise this issue.)
The best solution would be to fix the ports to not link explicitely to
indirect deps (by improving libtool and by improving the .pc files
for pkg-config). Then we could even switch from recording indirect
dependencies in /var/db/pkg/port-version/+{CONTENTS,REQUIRED_BY} to
only record direct deps.
Bye,
Alexander.
___
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: Building ports with stack-protector
Janne Snabb wrote: AFAIR there was certain performance penalty with stack-protector, I think the penalty is small enough. I would assume that someone has already made an evaluation on this before turning it on in make buildworld. I was earlier trying to search for a discussion on it, but I did not find it on the public mailing lists. Maybe it is somewhere. ... I remember that some ports built fine but the resulting binaries would not work for various reasons when I did my CFLAGS+=-fstack-protector experiment a couple of months ago. Unfortunately at that time I did not keep a record of which ports were problematic (and I built tested only a small subset of ports which were the most relevant to myself, most of them being network facing server programs). This is not the first time that this issue has come up. Jeremie Le Hen pushed through the integration of stack protector support with the help of others. If I recall correctly, his original tests showed ~2-5% penalty for the time required for buildworld. (Unfortunately, his original website has disappeared.) This was thought to be acceptable, and the added security (the stack protector can be circumvented, but it is much better than nothing at all), and the fact that it makes finding buffer overflows a bit easier, were thought to be good reason to enable it by default in most of the base system. I thought that the ports committers would then clean up the ports so that it could be used for the majority of them, too, but this didn't happen -- even though there are outstanding problems arising from the fact that stack protection is enabled by default in the base system of some supported versions of FreeBSD, but not in ports. I've been building most of my ports with stack protection since 2008, and most of the failures (~15 of my ~450 installed ports needed to be patched on i386, and far fewer on amd64) arose from the fact that many ports don't respect LDFLAGS (the stack-protector flags need to be passed when linking as well as when compiling). This needs to be fixed, and not just for using the stack protector: there has been a lot of interest in the use of alternative compilers and tool-chains in ports, and this will require that most ports respect not only CC, CXX, and CFLAGS, but also CPP, CPPFLAGS, LDFLAGS, AS, AR, ARFLAGS, LD, OBJCOPY, etc. This may be needed to make ports available on other architectures, too. Right now these variables are often ignored (see how many ports don't pass CPPFLAGS or LDFLAGS during configure or build, or pass some value that is hard-coded in the port Makefile), or set to the wrong values in ports/Mk/bsd.commands.mk, ports/Mk/bsd.port.mk, /usr/share/mk/sys.mk, or the port itself. With reference to Dmitry's patch, I don't think that three different overlapping variables are really needed, and there is already a precedent for using SSP rather than STACK_PROTECTOR in the base system -- for example, WITHOUT_SSP in src.conf, MK_SSP in a number of places, and SSP_CFLAGS in /usr/share/mk. Also, note that support for the stack protector in the base system, which may affect support in ports, is not available on several architectures, and can also be disabled by users in src.conf (see, for example, /usr/share/mk/bsd.sys.mk). b. ___ 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: ports/14701: New port: misc/proxyper
Synopsis: New port: misc/proxyper State-Changed-From-To: closed-open State-Changed-By: pgollucci State-Changed-When: Sat Jun 5 22:02:35 UTC 2010 State-Changed-Why: Maintainer approved. http://www.freebsd.org/cgi/query-pr.cgi?pr=14701 ___ 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: ports/14701: New port: misc/proxyper
Synopsis: New port: misc/proxyper State-Changed-From-To: open-closed State-Changed-By: pgollucci State-Changed-When: Sat Jun 5 22:03:44 UTC 2010 State-Changed-Why: dyslexia agian http://www.freebsd.org/cgi/query-pr.cgi?pr=14701 ___ 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
can't compile textproc/flex
Trying to upgrade gettext, it seems I need to upgrade flex. This produces: checking whether to use NLS... yes checking where the gettext function comes from... external libintl checking how to link with libintl... /usr/local/lib/libintl.so -L/usr/local/lib /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib checking for bison... bison -y checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... configure: error: cannot find output from flex; giving up === Script configure failed unexpectedly. Please report the problem to joh...@freebsd.org [maintainer] and attach the /usr/ports/textproc/flex/work/flex-2.5.35/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). I have e-mailed the maintained, with no response. The config log file is appended. Can anyoneone tell me what's messed up? (And how to fix it?) Robert Huff This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by the fast lexical analyser generator configure 2.5.35, which was generated by GNU Autoconf 2.59. Invocation command line was $ ./configure --includedir=/usr/local/include/flex --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=amd64-portbld-freebsd9.0 ## - ## ## Platform. ## ## - ## hostname = jerusalem.litteratus.org uname -m = amd64 uname -r = 9.0-CURRENT uname -s = FreeBSD uname -v = FreeBSD 9.0-CURRENT #0: Fri Apr 23 11:34:17 EDT 2010 h...@jerusalem.litteratus.org:/usr/obj/usr/src/sys/JERUSALEM /usr/bin/uname -p = amd64 /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/bin PATH: /sbin PATH: /usr/sbin PATH: /bin PATH: /usr/bin PATH: /usr/local/sbin PATH: /root ## --- ## ## Core tests. ## ## --- ## configure:1378: checking for a BSD-compatible install configure:1433: result: /usr/bin/install -c -o root -g wheel configure:1444: checking whether build environment is sane configure:1487: result: yes configure:1552: checking for gawk configure:1581: result: no configure:1552: checking for mawk configure:1581: result: no configure:1552: checking for nawk configure:1568: found /usr/bin/nawk configure:1578: result: nawk configure:1588: checking whether gmake sets $(MAKE) configure:1612: result: no configure:1795: checking whether NLS is requested configure:1804: result: yes configure:1842: checking for msgfmt configure:1876: result: no configure:1882: checking for gmsgfmt configure:1913: result: : configure:1952: checking for xgettext configure:1986: result: no configure:2023: checking for msgmerge configure:2056: result: no configure:2116: checking for style of include used by gmake configure:2144: result: none configure:2215: checking for gcc configure:2241: result: cc configure:2485: checking for C compiler version configure:2488: cc --version /dev/null 5 cc (GCC) 4.2.1 20070719 [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2491: $? = 0 configure:2493: cc -v /dev/null 5 Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] configure:2496: $? = 0 configure:2498: cc -V /dev/null 5 cc: '-V' option must have argument configure:2501: $? = 1 configure:2524: checking for C compiler default output file name configure:2527: cc -O -pipe -g conftest.c 5 configure:2530: $? = 0 configure:2576: result: a.out configure:2581: checking whether the C compiler works configure:2587: ./a.out configure:2590: $? = 0 configure:2607: result: yes configure:2614: checking whether we are cross compiling configure:2616: result: no configure:2619: checking for suffix of executables configure:2621: cc -o conftest -O -pipe -g conftest.c 5 configure:2624: $? = 0 configure:2649: result: configure:2655: checking for suffix of object files configure:2676: cc -c -O -pipe -g conftest.c 5 configure:2679: $? = 0 configure:2701: result: o configure:2705: checking whether we are using the GNU C compiler configure:2729: cc -c -O -pipe -g conftest.c 5 configure:2735: $? = 0 configure:2738: test -z || test ! -s conftest.err configure:2741: $? = 0 configure:2744: test -s conftest.o configure:2747: $? = 0 configure:2760: result: yes configure:2766: checking whether cc accepts -g configure:2787: cc -c -g conftest.c 5
Re: devel/gettext further update
On 6/5/10, Alexander Leidinger alexan...@leidinger.net wrote: ... Just for the record, the useful ports/Tools/scripts/explicit_lib_depends.sh, described and used in your link above, may _not_ find libraries that: -- are needed, but were intended to be statically linked; Correct. If you are of a way how to detect it after the fact, feel free to share the info here. I don't think there is a good way to do this, but you could perhaps provide a warning about undefined symbols. -- are needed, but loaded via dlopen(3) and friends (this is noted in a comment in ports/Tools/scripts/neededlibs.sh ); Correct. The goal for the scripts are to find entries for LIB_DEPENDS. A static lib is a BUILD_DEPEND, not a LIB_DEPEND, and something which is opened I take your point. I was just mentioning possible problems with reference to the OP's use of your script to determine which ports to rebuild during an update. In that case, one may want to rebuild a dependent port after updating a static library, even if the dependent port may not be broken after the update. via dlopen() is typically not a LIB_DEPEND but a RUN_DEPEND (it is the other way around and the stuff which is dlopen()en depends upon what is dlopen()ing it). Additionally if a something is using dlopen(), it I don't agree with this. Dependent ports often need to test for the presence of the libraries they intend to dlopen() during configuration or regression testing, or use headers from the ports that the libraries belong to during compilation. should give sensible error messages when it does not work, so instead of a cryptic error message which not everyone understands, there should be (yes, I know, this is an idealistic POV) an error message even your mother can understand. Well, let us say the average user. You don't know my mother. :) I have to tell that those scripts are far from finished, the heuristic of files to look at needs to be improved, and the translation into ports-framework variable (like GNOME and X11 ones) needs to be written. I didn't continue with this back when I was committing those scripts, as the 3rd party software was far away from a state which would made it really useful (indirect dependencies show up in runs of the scripts, but they are not really welcome in our ports). Yes, I didn't expect them to be highly polished. But they are already more elaborate than the rough, ad hoc methods I often use, anyway. -- are needed, and dynamically linked in the usual way, but are not referenced in any ELF DT_NEEDED tags. These tags are optional, not mandatory, in the System V ABI, and they can be missing for a number of reasons. They may not be present in a pre-compiled binary. Or, for example. because some ports make shared libraries by converting static archives into shared libraries with the linker, the tags can sometimes be missing for those libraries. Also, some ports use a version of gcc4* wired to devel/binutils, but then directly invoke some portion of the older base system binutils. I've seen this lead to missing tags in the past. Apart from the fact that I did not know that, do you know which ports in the FreeBSD ports collection show this problem? Is there another way to find this info in then? Well, these are admittedly uncommon cases, but I just thought I'd mention them in case someone using your script to determine which ports to update encountered one of them. With respect to the conversion of static libraries into shared libraries, anything that is using the '--whole-archive' flag during linking bears further examination. (It doesn't necessarily mean that the DT_NEEDED tags are missing, just that they _may_ be missing.) Among the ports that do this are older ports (often Fortran-related), or ports that once used static libraries because they were slightly more efficient, or more secure, but have since been modified to also build shared libraries in a very simple way: graphics/f90gl, math/arpack, math/atlas, math/blas, math/lapack, math/lapack95, math/metis, math/scalapack, math/spooles, math/suitesparse, etc. You can see the methods they use in the respective port Makefiles. Where needed, they may be fixed to include the proper tags, and I submitted patches to do this for some of them, but they were never committed, making linking for some of these libraries a real pain. See, for example, the unnecessarily complex (and wrong) description of how to link with the math/atlas _shared_ libraries in math/atlas/pkg-descr. As for ports that mix tool-chains, this includes a great many of the ports that USE_GCC=4.4+ or USE_FORTRAN, because, even though the gcc maintainer (finally) fixed the problem with the auto-detection of devel/binutils that could produce unpredictable results with respect to which tool-chain was used by the compiler in recent gcc snapshots, he did not also instruct those ports (and their dependencies) to use devel/binutils when invoking the
net/vnc: save vncviewer on CURRENT
net/vnc is marked as broken on 9, but I had successfully build the viewer (I can't test it right now). So the check for OSVERSION should be moved inside the part to build the server component. Sample patch here: http://pastebin.com/Cu1jzswE Best Regards Barbara ___ 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: FreeBSD Port: squeezeboxserver-7.5.0_1
Mark writes: Hi, I've been using this port for some years to power my Squeezebox devices - thanks for keeping it up to date. However, the latest update has killed my installation totally - first it would not scan my music, and after upgrading perl perl module ports I can no longer start the squeezebox server at all: odin# /usr/local/etc/rc.d/squeezeboxserver start Starting squeezeboxserver. The following modules failed to load: YAML::Syck *** NOTE: Please use the buildme.sh script located here: http://svn.slimdevices.com/repos/slim/7.5/trunk/vendor/CPAN/ If 7.5 is outdated by the time you read this, Replace 7.5 with the major version of Squeezebox Server you are running. *** Exiting.. I'm running the latest 5.8 perl from the ports, and seem to be able to load modules from the command line: odin# perl use YAML::Syck Any idea how I should investigate this? I've tried downloading various versions of the server from slimdevices.com, but to no avail. It either won't run at all, or won't scan any music with DBI:: errors. I did notice the port is not downloading the FreeBSD-specific tarball from slimdevices (it uses the NOCPAN one). I appreciate you're not a helpdesk, but I'm not sure where else to go with this - none of the slimdevices forums seem to have much FreeBSD stuff on them. If there's a list that might help, I'd be grateful if you could point me to it. I don't know what's up with the YAML issues. When I upgraded I discovered that the latest greatest version of DBIx-Class didn't seem to make squeezeboxserver very happy. I downgraded to an earlier DBIx-Class release (manually, as described here: http://www.mail-archive.com/freebsd-questi...@freebsd.org/msg233242.html ) and things worked. I'd start by getting everything up to the current version (a current perl should be 5.10.1, I believe) and then step DBIx-class back one step and see if that works for you. g. ___ 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: Ccache warning
On 06/04/10 22:24, Denny Lin wrote: Hi, I saw this warning about devel/ccache a while ago: Any time you change CC/CXX you need to reinstall devel/libtool15 or you will run in to problems. This was added a long time ago, so I'm wondering if this is still necessary (should be devel/libtool22 now). If that's true it should be added to http://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/index.html. Can anyone comment authoritatively? If you look at the output of 'libtool --config', you will see that libtool sets default values for the compiler, toolchain, various flags, and library search directories, that can change depending upon what compiler and tool-chain are used to build libtool. Depending upon how libtool is called, it may fall back upon default values, or override some of them. Since not all ports call libtool in a clean and uniform way, it may be better to have a different copy of libtool for each compiler and tool-chain that you intend to use, that has been configured and built with that compiler and tool-chain, and then to use that version of libtool for ports built with that compiler and tool-chain, by altering the definition of some of the libtool-related variables in ports/Mk/bsd.autotools.mk to depend conditionally upon CC. This is one of the components of the port system that is ill-suited in it's current configuration for using different compilers and toolchains. There are others: qmake4, cmake, etc. -- unfortunately, a lot of ports depend upon these. b. ___ 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
mpich2 installation problem
On Sat, Jun 5, 2010 at 1:17 AM, PA Zolczynski zolczyn...@googlemail.com wrote: On 05/06/2010 08:42, Garrett Cooper wrote: 2010/6/4 PA Zolczynski zolczyn...@googlemail.com: See `config.log' for more details. === Script configure failed unexpectedly. Please report the problem to po...@freebsd.org [maintainer] and attach the /usr/ports/net/mpich2/work/mpich2-1.2.1p1/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Does execinfo.1 exist /usr/local ? Thanks, -Garrett thanks Garrett, cd /usr/ports/devel/libexecinfo ; make install helped, it ok now This was probably the result of an incomplete package or port install because the OP installed the port and magically the issue went away... If you look at the configure log nowhere does it actually state that -lexecinfo was added to the LDFLAGS or LDLIBS by the OP. Thanks, -Garrett ___ 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: mpich2 installation problem
On Sat, Jun 5, 2010 at 9:00 PM, Garrett Cooper yanef...@gmail.com wrote: On Sat, Jun 5, 2010 at 1:17 AM, PA Zolczynski zolczyn...@googlemail.com wrote: On 05/06/2010 08:42, Garrett Cooper wrote: 2010/6/4 PA Zolczynski zolczyn...@googlemail.com: See `config.log' for more details. === Script configure failed unexpectedly. Please report the problem to po...@freebsd.org [maintainer] and attach the /usr/ports/net/mpich2/work/mpich2-1.2.1p1/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Does execinfo.1 exist /usr/local ? Thanks, -Garrett thanks Garrett, cd /usr/ports/devel/libexecinfo ; make install helped, it ok now This was probably the result of an incomplete package or port install because the OP installed the port and magically the issue went away... If you look at the configure log nowhere does it actually state that -lexecinfo was added to the LDFLAGS or LDLIBS by the OP. nm, spoke too soon... it was set in LDFLAGS (sigh). Sorry for the noise... -Garrett ___ 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
Can't build devel/icu{,4} on 8-STABLE amd64
Hi,
I can build neither devel/icu nor devel/icu4 under
FreeBSD 8.1-PRELEASE amd64 with latest up to date ports.
$ uname -a
FreeBSD exxodus.fedaykin.here 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #6: Thu Jun
3 20:30:23 BRT 2010 li...@exxodus:/usr/obj/usr/src/sys/LIOUX amd64
I have not been able to build icu{,4} ever since I upgraded
from FreeBSD 7-STABLE to 8-STABLE.
Both ports fail during their test phase of the port build.
--
- devel/icu
/putiltst/
FAIL: t_timezone may be incorrect. It is not a multiple of 30min. ---[OK]
---/putiltst/TestPUtilAPI
[snip]
---OK: CalendarLimitTest
---OK: TestPRTOffset
---OK: TestVariousAPI518
---OK: TestGetAvailableIDs913
FAIL: t_timezone may be incorrect. It is not a multiple of 15min. It
is 10776
- devel/icu4
/putiltst/
---[OK] ---/putiltst/TestVersion
---[OK] ---/putiltst/TestCompareVersions
---[OK] ---/putiltst/TestErrorName
FAIL: t_timezone may be incorrect. It is not a multiple of 30min. ---[OK]
---/putiltst/TestPUtilAPI
---OK: CalendarLimitTest
---OK: TestPRTOffset
---OK: TestVariousAPI518
---OK: TestGetAvailableIDs913
FAIL: t_timezone may be incorrect. It is not a multiple of 15min. It
is 10776
--
Full build logs can be found at:
http://people.freebsd.org/~lioux/icu/devel__icu__build_log.txt
http://people.freebsd.org/~lioux/icu/devel__icu4__build_log.txt
The port work directory of the failed builds can be found at:
http://people.freebsd.org/~lioux/icu/devel__icu__work.tar.xz
http://people.freebsd.org/~lioux/icu/devel__icu4__work.tar.xz
Let me know if there is anything I can do to help.
Regards,
--
Mario S F Ferreira - DF - Brazil - I guess this is a signature.
feature, n: a documented bug | bug, n: an undocumented feature
___
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
