FreeBSD unmaintained ports which are currently marked broken
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/tclmidi broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=tclmidi portname: audio/teamspeak_client broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=teamspeak_client portname: audio/timidity++-xaw broken because: does not install properly after X11BASE removal build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.9.20120123043600/timidity++-xaw-2.13.2_9.log (_Feb_18_03:41:05_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=timidity%2B%2B-xaw portname: benchmarks/dbs broken because: does not compile on FreeBSD 9.X build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=benchmarksportname=dbs portname: chinese/big5con broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=big5con portname: chinese/hztty broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=hztty portname: chinese/kon2 broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=kon2 portname: databases/msql broken because: Broken on FreeBSD 9+ build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=msql portname: devel/dsss broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=dsss portname: devel/fastcrc broken because: Does not compile on recent FreeBSD-9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=fastcrc portname: devel/gauche-gaunit broken because: does not package build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.8.20120212090446/gauche-gaunit-0.1.6.log (_Dec_15_17:12:50_UTC_2011) overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=gauche-gaunit portname: devel/gcvs broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=gcvs portname: devel/kdevelop broken because: conflicting dependencies build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=kdevelop portname: devel/linux-js broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=linux-js portname: devel/linuxthreads broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=linuxthreads portname: devel/p5-Dialog broken because: Does not build
FreeBSD unmaintained ports which are currently scheduled for deletion
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: archivers/bsdar description:BSD-licensed replacement of the ar utility maintainer: po...@freebsd.org status: IGNORE deprecated because: part of the base system expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=bsdar portname: databases/py-MySQLdb-devel description:Access a MySQL database through Python maintainer: po...@freebsd.org deprecated because: use databases/py-MySQLdb instead expiration date:2012-05-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=py-MySQLdb-devel portname: devel/kdevelop description:IDE for a wide variety of programming tasks maintainer: po...@freebsd.org status: BROKEN deprecated because: expiration date:2011-11-30 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=kdevelop portname: devel/libgetline description:A small, portable, and easy to use command line library maintainer: po...@freebsd.org deprecated because: Upstream disapear and distfile is no more available expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=libgetline portname: graphics/gmt description:The Generic Mapping Tools data processing and display software package maintainer: po...@freebsd.org status: BROKEN deprecated because: Hasn't fetched since before 2006 expiration date:2012-04-17 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=gmt portname: graphics/vrml2pov description:Convert VRML files to POVRay source maintainer: po...@freebsd.org status: BROKEN deprecated because: unfetchable expiration date:2012-03-21 build errors: http://pointyhat.FreeBSD.org/errorlogs/powerpc-errorlogs/e.9.20111228135944/vrml2pov-0.7_1.log (_Dec_16_03:59:13_UTC_2011) overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=vrml2pov portname: mail/py-email description:Email package for Python 2.3 or upper maintainer: po...@freebsd.org deprecated because: Included into all supported python versions expiration date:2012-03-14 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=mailportname=py-email portname: misc/fortune-mod-the-godfather description:Compilation of excuses from the The Godfather maintainer: po...@freebsd.org deprecated because: No longer supported expiration date:2012-05-06 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=miscportname=fortune-mod-the-godfather portname: net-p2p/fidelio description:A GNOME client for Hotline maintainer: po...@freebsd.org deprecated because: Hotline services does not exists anymore expiration date:2012-03-20 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-p2pportname=fidelio ___ 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 ports which are currently scheduled for deletion
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: archivers/bsdar description:BSD-licensed replacement of the ar utility maintainer: po...@freebsd.org status: IGNORE deprecated because: part of the base system expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=bsdar portname: archivers/php52-bz2 description:The bz2 shared extension for php maintainer: ad...@lissyara.su deprecated because: PHP 5.2 series is not supported anymore, migrate now expiration date:2012-03-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=php52-bz2 portname: archivers/php52-zip description:The zip shared extension for php maintainer: ad...@lissyara.su deprecated because: PHP 5.2 series is not supported anymore, migrate now expiration date:2012-03-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=php52-zip portname: archivers/php52-zlib description:The zlib shared extension for php maintainer: ad...@lissyara.su deprecated because: PHP 5.2 series is not supported anymore, migrate now expiration date:2012-03-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=php52-zlib portname: converters/php52-iconv description:The iconv shared extension for php maintainer: ad...@lissyara.su deprecated because: PHP 5.2 series is not supported anymore, migrate now expiration date:2012-03-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=php52-iconv portname: converters/php52-mbstring description:The mbstring shared extension for php maintainer: ad...@lissyara.su deprecated because: PHP 5.2 series is not supported anymore, migrate now expiration date:2012-03-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=php52-mbstring portname: converters/php52-recode description:The recode shared extension for php maintainer: ad...@lissyara.su deprecated because: PHP 5.2 series is not supported anymore, migrate now expiration date:2012-03-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=php52-recode portname: databases/gbib description:Editor/browser for BibTeX bibliographic databases maintainer: g...@freebsd.org deprecated because: expiration date:2012-03-20 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=gbib portname: databases/php52-dba description:The dba shared extension for php maintainer: ad...@lissyara.su deprecated because: PHP 5.2 series is not supported anymore, migrate now expiration date:2012-03-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=php52-dba portname: databases/php52-dbase description:The dbase shared extension for php maintainer: ad...@lissyara.su deprecated because: PHP 5.2 series is not supported anymore, migrate now expiration date:2012-03-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=php52-dbase portname: databases/php52-interbase description:The interbase shared extension for php maintainer: ad...@lissyara.su deprecated because: PHP 5.2 series is not supported anymore, migrate now expiration date:2012-03-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=php52-interbase portname: databases/php52-mssql description:The mssql shared extension for php maintainer: ad...@lissyara.su deprecated because: PHP 5.2 series is not supported anymore, migrate now expiration date:2012-03-01 build errors: none.
FreeBSD ports which are currently marked forbidden
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users about ports that are marked as forbidden in their Makefiles. Often, these ports are so marked due to security concerns, such as known exploits. An overview of each port, including errors seen on the build farm, is included below. portname: graphics/linux-tiff forbidden because: Vulnerable since 2004-10-13, http://portaudit.freebsd.org/8816bf3a-7929-11df-bcce-0018f3e2eb82.html build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=linux-tiff portname: x11-toolkits/linux-pango forbidden because: Vulnerable since 2009-05-13, http://portaudit.freebsd.org/4b172278-3f46-11de-becb-001cc0377035.html build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkitsportname=linux-pango ___ 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: linux-f10-flashplugin11 not works for 9-stable (Linuxulator?)
Andrey Chernov wrote:
Just in case it may help somebody: the cause (but not the root) of the
problem is found and workaround too.
The cause of the problem is
::1 localhost localhost.my.domain
line from our _standard_ /usr/src/etc/hosts which comes first before
127.0.0.1 localhost localhost.my.domain
line.
Linux takes the first match on localhost, i.e. ::1, then tries
8605 npviewer.bin STRU struct sockaddr { AF_INET6, [::1]:6010 }
it was last command from npviewer.bin, then it immeditelly terminates:
8605 npviewer.bin RET linux_socketcall -1 errno 4 Interrupted system
call
8605 npviewer.bin PSIG SIGTERM SIG_DFL code=0x10001
The workaround is to switch lines order in /etc/hosts, i.e.
127.0.0.1 localhost
::1 localhost
to make IPv4 one comes first. Flash works afterwards.
The bug affects IPv6-enabled machines with IPv4 over IPv6 preferred or
maybe IPv4 too I don't know, but since we don't have such reports in mass,
I think IPv4-only setup is fine.
Can you clarify this a bit? I have at least one machine with vanilla
/etc/hosts connected to IPv4/IPv6 network (i.e. some internal hosts
resolve to IPv6) and flash works fine there.
The DEPEND list on www/nspluginwrapper lists ftp/curl as a dependence.
And this port can be built without IPv6. Can you check your ports
configuration about enabling IPv6 support?
--
Sphinx of black quartz judge my vow.
___
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: www/firefox and mail/thunderbird localization
2012/2/20 Oliver Heesakkers free...@heesakkers.info: Op ma 20 feb 2012 17:50:17 schreef Olivier Smedts: Hello, Since Firefox 10.0 I don't have localized menus anymore. (...) Any advice ? http://lists.freebsd.org/pipermail/freebsd-ports/2012-February/072850.html First, hello. Then, I already saw that, but what's the point of installing a global extension (the localization) if each user has to install the *distfile* xpi (read: not an xpi installed by the firefox-i18n port in /usr/local/lib/xpi/, but the xpi fetched by the port in /usr/ports/distfiles/) in his Firefox profile ? To resume, the www/firefox-i18n port does not work any more, at least for the fr-FR locale, at least on two different computers I own, and at least one some other computers owned by others individuals who seem to be using other locales. While it's broken, a workaround is to manually install the french localization from the mozilla website. But what can be done to repair the port or help debug this ? Cheers -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: linux-f10-flashplugin11 not works for 9-stable (Linuxulator?)
On Tue, Feb 21, 2012 at 12:07:46PM +0200, Volodymyr Kostyrko wrote:
Andrey Chernov wrote:
Just in case it may help somebody: the cause (but not the root) of the
problem is found and workaround too.
The cause of the problem is
::1 localhost localhost.my.domain
line from our _standard_ /usr/src/etc/hosts which comes first before
127.0.0.1 localhost localhost.my.domain
line.
Linux takes the first match on localhost, i.e. ::1, then tries
8605 npviewer.bin STRU struct sockaddr { AF_INET6, [::1]:6010 }
it was last command from npviewer.bin, then it immeditelly terminates:
8605 npviewer.bin RET linux_socketcall -1 errno 4 Interrupted
system call
8605 npviewer.bin PSIG SIGTERM SIG_DFL code=0x10001
The workaround is to switch lines order in /etc/hosts, i.e.
127.0.0.1 localhost
::1 localhost
to make IPv4 one comes first. Flash works afterwards.
The bug affects IPv6-enabled machines with IPv4 over IPv6 preferred or
maybe IPv4 too I don't know, but since we don't have such reports in mass,
I think IPv4-only setup is fine.
Can you clarify this a bit? I have at least one machine with vanilla
/etc/hosts connected to IPv4/IPv6 network (i.e. some internal hosts
resolve to IPv6) and flash works fine there.
I can't - I don't know why npviewer.bin is killed by SIGTERM immediatelly
when it socketcall to [::1]:6010 in Linuxulator and why it works
normally when it socketcall to 127.0.0.1:6010. I remember when I had
FF 7, Flash works with ::1 first, but Linuxulator not yet have any length
checks at those times as it have now (or perhaps other recent fixes).
The DEPEND list on www/nspluginwrapper lists ftp/curl as a dependence.
And this port can be built without IPv6. Can you check your ports
configuration about enabling IPv6 support?
This is not the case, all my ports which have IPv6 capability
are builded with IPv6 as the system too.
--
http://ache.vniz.net/
___
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: linux-f10-flashplugin11 not works for 9-stable (Linuxulator?)
On 02/21/2012 02:43, Andrey Chernov wrote: I can't - I don't know why npviewer.bin is killed by SIGTERM immediatelly when it socketcall to [::1]:6010 in Linuxulator and why it works normally when it socketcall to 127.0.0.1:6010. I remember when I had FF 7, Flash works with ::1 first, but Linuxulator not yet have any length checks at those times as it have now (or perhaps other recent fixes). I have an IPv6 connection and listing ::1 first works for me as well. Try closing down firefox, rm -r ~/.macromedia, rebuilding www/nspluginwrapper and www/linux-f10-flashplugin11, then rm ~/.mozilla/plugins/npwrapper.libflashplayer.so and reinstall. (I just use, nspluginwrapper -i /usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so personally) Then restart firefox and check out about:plugins Good luck, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: linux-f10-flashplugin11 not works for 9-stable (Linuxulator?)
On Tue, Feb 21, 2012 at 02:51:26AM -0800, Doug Barton wrote: On 02/21/2012 02:43, Andrey Chernov wrote: I can't - I don't know why npviewer.bin is killed by SIGTERM immediatelly when it socketcall to [::1]:6010 in Linuxulator and why it works normally when it socketcall to 127.0.0.1:6010. I remember when I had FF 7, Flash works with ::1 first, but Linuxulator not yet have any length checks at those times as it have now (or perhaps other recent fixes). I have an IPv6 connection and listing ::1 first works for me as well. Try closing down firefox, rm -r ~/.macromedia, rebuilding www/nspluginwrapper and www/linux-f10-flashplugin11, then rm ~/.mozilla/plugins/npwrapper.libflashplayer.so and reinstall. (I just use, nspluginwrapper -i /usr/local/lib/npapi/linux-f10-flashplugin/libflashplayer.so personally) Then restart firefox and check out about:plugins I already do all the above first, rebuild everything etc. Nothing helps excepting moving ::1 down (moving it down works even with FF is already running - on the next page reload). BTW, Flash is shown in about:plugins normally in either case, just not works due to misteriosly killed npviewer.bin in ::1 first case. -- http://ache.vniz.net/ ___ 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: pcre again
On Monday 20 February 2012 00:19:59 Kevin Oberman wrote: On Sun, Feb 19, 2012 at 2:04 PM, ajtiM lum...@gmail.com wrote: I did as I red on /usr/ports/UPDATING and when I checked pkg_libchk I have many misses pcre related. Do I need run portmaster -r devel/pcre, please? It is quite possible that you will re-install quite a few ports that don't need it with 'portmaster -r'. I'd just re-build the ports called out in by 'pkg_libchk -o'. But you don't really need to do any immediately. The backup copy of libpcre.so.0 in /usr/local/lib/compat/pkg is not seen as that path is not checked by pkg_libchk. (I assume that is deliberate.) Still, it is probably a good idea to get them re-built. If some things are linked against two libraries, one of which uses .0 and the other using .1 which will break the executable as rtld will refuse to load it. OTOH, those who only install or update from packages after upgrading to a new release should have nothing to worry about. Thank you very much. I did as you did and rebuilt all ports (it was not bad). And it looks okay. Mitja http://jpgmag.com/people/lumiwa ___ 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: www/firefox and mail/thunderbird localization
Hi To resume, the www/firefox-i18n port does not work any more, at least for the fr-FR locale, at least on two different computers I own, and at least one some other computers owned by others individuals who seem to be using other locales. While it's broken, a workaround is to manually install the french localization from the mozilla website. But what can be done to repair the port or help debug this ? For Linux, someone seems to have solved the problem. http://www.pclinuxos.com/forum/index.php/topic,102212.msg871107.html#msg871107 But I don't know what he actually did. -- Hiroto Kagotani hiroto.kagot...@gmail.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: giflib in graphics/gdal
On Tue, 21 Feb 2012 08:39:38 +0100
Rainer Hurling articulated:
Dear list,
after changing from graphics/ungif to graphics/giflib there is a
problem with building graphics/gdal. Because other ports depending on
it, this should be corrected as soon as possible, I think.
The patch could be something like this:
--- Makefile.orig 2012-02-08 07:52:24.0 +0100
+++ Makefile2012-02-21 08:34:04.0 +0100
@@ -104,7 +104,7 @@
.endif
.if !defined(WITHOUT_GIF)
-LIB_DEPENDS+= ungif.5:${PORTSDIR}/graphics/libungif
+LIB_DEPENDS+= gif.5:${PORTSDIR}/graphics/giflib
CONFIGURE_ARGS+= --with-gif=${LOCALBASE}
.endif
@@ -276,9 +276,6 @@
.endif
post-patch:
-.if !defined(WITHOUT_GIF)
- @${REINPLACE_CMD} -e 's|lgif|lungif|' ${WRKSRC}/configure
-.endif
.if defined(WITH_PYTHON)
@${REINPLACE_CMD} -e '\
s,%%MAKE_ENV%%,${MAKE_ENV},; \
Did you contact the port maintainer: sunp...@freebsd.org as well as
possibly submitting a PR against the port? If not, it might prove
useful.
--
Jerry ♔
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__
___
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: giflib in graphics/gdal
Am 21.02.2012 14:40 (UTC+1) schrieb Jerry:
On Tue, 21 Feb 2012 08:39:38 +0100
Rainer Hurling articulated:
Dear list,
after changing from graphics/ungif to graphics/giflib there is a
problem with building graphics/gdal. Because other ports depending on
it, this should be corrected as soon as possible, I think.
The patch could be something like this:
--- Makefile.orig 2012-02-08 07:52:24.0 +0100
+++ Makefile2012-02-21 08:34:04.0 +0100
@@ -104,7 +104,7 @@
.endif
.if !defined(WITHOUT_GIF)
-LIB_DEPENDS+= ungif.5:${PORTSDIR}/graphics/libungif
+LIB_DEPENDS+= gif.5:${PORTSDIR}/graphics/giflib
CONFIGURE_ARGS+= --with-gif=${LOCALBASE}
.endif
@@ -276,9 +276,6 @@
.endif
post-patch:
-.if !defined(WITHOUT_GIF)
- @${REINPLACE_CMD} -e 's|lgif|lungif|' ${WRKSRC}/configure
-.endif
.if defined(WITH_PYTHON)
@${REINPLACE_CMD} -e '\
s,%%MAKE_ENV%%,${MAKE_ENV},; \
Did you contact the port maintainer: sunp...@freebsd.org as well as
possibly submitting a PR against the port? If not, it might prove
useful.
As you can see in CC of the original posting he should get a copy.
I did not file a PR because I thought this should be corrected as soon
as possible. But perhaps this was not the best way ...
___
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: www/firefox and mail/thunderbird localization
On 21.02.2012 16:59, Olivier Smedts wrote: Some help from the gecko team ? :) It was not a success for me: http://lists.freebsd.org/pipermail/freebsd-gnome/2012-February/026907.html -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: www/firefox and mail/thunderbird localization
2012/2/21 Boris Samorodov b...@passap.ru: On 21.02.2012 16:59, Olivier Smedts wrote: Some help from the gecko team ? :) It was not a success for me: http://lists.freebsd.org/pipermail/freebsd-gnome/2012-February/026907.html Well gecko@ is not the same as gnome@ ;) Its's one of my open tasks but unfortunately I only have limited access to the internet at the moment and I'm still suffering from a concussion so it probalby take some days until I can take a look at it. But in the meantime patches are very welcome. Beat ___ 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: www/firefox and mail/thunderbird localization
On 21.02.2012 19:44, Beat Gaetzi wrote: 2012/2/21 Boris Samorodovb...@passap.ru: On 21.02.2012 16:59, Olivier Smedts wrote: Some help from the gecko team ? :) It was not a success for me: http://lists.freebsd.org/pipermail/freebsd-gnome/2012-February/026907.html Well gecko@ is not the same as gnome@ ;) My bad, sorry! Its's one of my open tasks but unfortunately I only have limited access to the internet at the moment and I'm still suffering from a concussion so Hope you'll recover soonish. it probalby take some days until I can take a look at it. But in the meantime patches are very welcome. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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
rtld or lang/gcc cannot find libgcc_s.so.1
Sorry about the cross post, but I can't tell if this a -current issue of a -ports issue. Unfortunately, I updated my freebsd 10.0 systems and the lang/gcc port during the same timeframe. I have compiled my math library and several programs with gfortran, which is installed by lang/gcc (pkg_info shows gcc-4.6.2_1). When I try running the program I get troutmask:kargl[210] halfspace /lib/libgcc_s.so.1: version GCC_4.6.0 required by /home/kargl/bin/halfspace not foundtroutmask:kargl[211] (Note, the annoying absense of a newline character after the error message, which is a completely different issue.) I see this problem on both freebsd-i386 and freebsd-amd64. troutmask:kargl[212] ldd ~/bin/halfspace /home/kargl/bin/halfspace: liblapack.so.4 = /usr/local/lib/liblapack.so.4 (0x2008c3000) libblas.so.2 = /usr/local/lib/libblas.so.2 (0x201463000) libgfortran.so.3 = /usr/local/lib/gcc46/libgfortran.so.3 (0x20175d000) libm.so.5 = /lib/libm.so.5 (0x201a7) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x201c95000) libquadmath.so.0 = /usr/local/lib/gcc46/libquadmath.so.0 (0x201ea2000) libc.so.7 = /lib/libc.so.7 (0x2020d6000) troutmask:kargl[212] 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 So, it appears that rtld is finding the wrong libgcc_s.so.1 or the lang/gcc port is no longer providing sufficient information for rtld to choose the correct library. I have reverted revisions 230784, 299768, and 229508 (and various combinitions of these revisions) from rtld-elf. The result does not change the above error. I can work around the problem by specifying -static during the building of my programs. Or, I can work around the problem by *explicitly* adding '-rpath /usr/local/lib' to the command line, which I have never had to do. -- Steve ___ 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: giflib in graphics/gdal
I saw new gdal in ports...
My question is: in the /usr/ports/UPDATING is first uninstall libungif and
than install giflib and reinstall all ports.
Is it correct to use portmaster -o graphics/giflib graphics/libungif
And thew next question is I have in /var/db/pgs bot giflib and libingif.
How can I find whic one is installed, please? Or are both?
Thanks in advance.
On Tue, Feb 21, 2012 at 7:40 AM, Jerry je...@seibercom.net wrote:
On Tue, 21 Feb 2012 08:39:38 +0100
Rainer Hurling articulated:
Dear list,
after changing from graphics/ungif to graphics/giflib there is a
problem with building graphics/gdal. Because other ports depending on
it, this should be corrected as soon as possible, I think.
The patch could be something like this:
--- Makefile.orig 2012-02-08 07:52:24.0 +0100
+++ Makefile2012-02-21 08:34:04.0 +0100
@@ -104,7 +104,7 @@
.endif
.if !defined(WITHOUT_GIF)
-LIB_DEPENDS+= ungif.5:${PORTSDIR}/graphics/libungif
+LIB_DEPENDS+= gif.5:${PORTSDIR}/graphics/giflib
CONFIGURE_ARGS+= --with-gif=${LOCALBASE}
.endif
@@ -276,9 +276,6 @@
.endif
post-patch:
-.if !defined(WITHOUT_GIF)
- @${REINPLACE_CMD} -e 's|lgif|lungif|' ${WRKSRC}/configure
-.endif
.if defined(WITH_PYTHON)
@${REINPLACE_CMD} -e '\
s,%%MAKE_ENV%%,${MAKE_ENV},; \
Did you contact the port maintainer: sunp...@freebsd.org as well as
possibly submitting a PR against the port? If not, it might prove
useful.
--
Jerry ♔
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__
___
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-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, Feb 21, 2012 at 08:57:54PM +0200, Konstantin Belousov wrote: On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote: troutmask:kargl[210] halfspace /lib/libgcc_s.so.1: version GCC_4.6.0 required by /home/kargl/bin/halfspace not foundtroutmask:kargl[211] (Note, the annoying absense of a newline character after the error message, which is a completely different issue.) I see this problem on both freebsd-i386 and freebsd-amd64. troutmask:kargl[212] ldd ~/bin/halfspace /home/kargl/bin/halfspace: liblapack.so.4 = /usr/local/lib/liblapack.so.4 (0x2008c3000) libblas.so.2 = /usr/local/lib/libblas.so.2 (0x201463000) libgfortran.so.3 = /usr/local/lib/gcc46/libgfortran.so.3 (0x20175d000) libm.so.5 = /lib/libm.so.5 (0x201a7) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x201c95000) libquadmath.so.0 = /usr/local/lib/gcc46/libquadmath.so.0 (0x201ea2000) libc.so.7 = /lib/libc.so.7 (0x2020d6000) troutmask:kargl[212] 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 So, it appears that rtld is finding the wrong libgcc_s.so.1 or the lang/gcc port is no longer providing sufficient information for rtld to choose the correct library. I have reverted revisions 230784, 299768, and 229508 (and various combinitions of these revisions) from rtld-elf. The result does not change the above error. I can work around the problem by specifying -static during the building of my programs. Or, I can work around the problem by *explicitly* adding '-rpath /usr/local/lib' to the command line, which I have never had to do. I highly suspect that you just happen to not need a symbol from the newest namespace before. The thing to look first is the library search path in the ld.so hints, which is output at the second line of ldconfig -r. I think that you have /lib before /usr/local/lib/gcc46 in your setup. This guess is confirmed by the numeration of the two instances of gcc_s above. Either change the config, or use -rpath. AFAIR, ldconfig -m adds the directory at the end of the search list. 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. I tried reading rtld.c to see where the issue lies. One possibility seems to be a change in rtld.c (lines 4012-13) to remember the version mismatch, then continuing the search to see if another library with the same name but different location matches. After exhausting the list of directories in the search path, either an error is reported or a match has been found. Note, I'm still trying to parse and understand the rtld.c code, so may be what I'm suggesting is not feasible. -- Steve ___ 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: giflib in graphics/gdal
I saw new gdal in ports... Yes, the graphics/gdal port was updated to use giflib. My question is: in the /usr/ports/UPDATING is first uninstall libungif and than install giflib and reinstall all ports. Is it correct to use portmaster -o graphics/giflib graphics/libungif Looks OK to me. And thew next question is I have in /var/db/pgs bot giflib and libingif. How can I find whic one is installed, please? Or are both? They install files to the same place, overwriting each other. So whichever one was installed last would be the one that's really installed. This is the reason for the addition of the conflict between the two. The good news is they're very similar, so it didn't cause problems. Nevertheless, it's still a bad idea for them both to be installed, hence the addition of the conflict between them. Steve ___ 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, Feb 21, 2012 at 11:42:59AM -0800, Steve Kargl wrote: On Tue, Feb 21, 2012 at 08:57:54PM +0200, Konstantin Belousov wrote: On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote: troutmask:kargl[210] halfspace /lib/libgcc_s.so.1: version GCC_4.6.0 required by /home/kargl/bin/halfspace not foundtroutmask:kargl[211] (Note, the annoying absense of a newline character after the error message, which is a completely different issue.) I see this problem on both freebsd-i386 and freebsd-amd64. troutmask:kargl[212] ldd ~/bin/halfspace /home/kargl/bin/halfspace: liblapack.so.4 = /usr/local/lib/liblapack.so.4 (0x2008c3000) libblas.so.2 = /usr/local/lib/libblas.so.2 (0x201463000) libgfortran.so.3 = /usr/local/lib/gcc46/libgfortran.so.3 (0x20175d000) libm.so.5 = /lib/libm.so.5 (0x201a7) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x201c95000) libquadmath.so.0 = /usr/local/lib/gcc46/libquadmath.so.0 (0x201ea2000) libc.so.7 = /lib/libc.so.7 (0x2020d6000) troutmask:kargl[212] 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 So, it appears that rtld is finding the wrong libgcc_s.so.1 or the lang/gcc port is no longer providing sufficient information for rtld to choose the correct library. I have reverted revisions 230784, 299768, and 229508 (and various combinitions of these revisions) from rtld-elf. The result does not change the above error. I can work around the problem by specifying -static during the building of my programs. Or, I can work around the problem by *explicitly* adding '-rpath /usr/local/lib' to the command line, which I have never had to do. I highly suspect that you just happen to not need a symbol from the newest namespace before. The thing to look first is the library search path in the ld.so hints, which is output at the second line of ldconfig -r. I think that you have /lib before /usr/local/lib/gcc46 in your setup. This guess is confirmed by the numeration of the two instances of gcc_s above. Either change the config, or use -rpath. AFAIR, ldconfig -m adds the directory at the end of the search list. 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. I tried reading rtld.c to see where the issue lies. One possibility seems to be a change in rtld.c (lines 4012-13) to remember the version mismatch, then continuing the search to see if another library with the same name but different location matches. After exhausting the list of directories in the search path, either an error is reported or a match has been found. Note, I'm still trying to parse and understand the rtld.c code, so may be what I'm suggesting is not feasible. No, it is not feasible. The version check that tripped is there to check consistency, and not to start loading. In fact, it is too late to load other library (with the same name). The configuration needs to be fixed, and not the rtld. pgpQf8VpXvI63.pgp Description: PGP signature
Re: CFT: pkgng support for tinderbox
On 16.02.2012 1:07, Beat Gätzi wrote:
Hi,
pkgng support for tinderbox (written by bapt@) is ready and is looking for
some review and testers. The patch is against tinderbox HEAD:
http://tmp.chruetertee.ch/tinderbox-pkgng.patch
One more fix:
--- lib/buildscript.prev2012-02-22 00:16:17.0 +0400
+++ lib/buildscript 2012-02-22 00:17:24.0 +0400
@@ -146,7 +146,7 @@
RD=$7
TD=$8
PKGD=$9
-PLISTCHECK=$10
+PLISTCHECK=${10}
use_pkgng=no
Thanks to vim. It's highlighted me 0 as separated character.
--
Andrey Zonov
___
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: CFT: pkgng support for tinderbox
On 22.02.2012 0:24, Andrey Zonov wrote:
On 16.02.2012 1:07, Beat Gätzi wrote:
Hi,
pkgng support for tinderbox (written by bapt@) is ready and is looking
for
some review and testers. The patch is against tinderbox HEAD:
http://tmp.chruetertee.ch/tinderbox-pkgng.patch
One more fix:
And more:
--- lib/buildscript.prev2012-02-22 00:44:58.0 +0400
+++ lib/buildscript 2012-02-22 00:45:18.0 +0400
@@ -323,7 +323,7 @@
fi
add_pkg ${TD}
if [ $use_pkgng = yes ]; then
- pkg info -qa | sort /tmp/pkgs_pre_test
+ pkg info -qa | sort /tmp/pkgs_post_test
else
pkg_info | awk '{print $1}' | sort /tmp/pkgs_post_test
fi
--
Andrey Zonov
___
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 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. The same applies to libstdc++.so.6, if you compile any C++ program with e.g. g++46. During the link stage, g++ sets the library path so that /usr/local/lib/gcc46/libstdc++.so is linked against the program: ... COMPILER_PATH=/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../../../i386-portbld-freebsd10.0/bin/ LIBRARY_PATH=/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../../../i386-portbld-freebsd10.0/lib/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-o' 'cpptest' '-v' '-shared-libgcc' '-mtune=generic' '-march=i486' /usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/collect2 --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o cpptest /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/crtbegin.o -L/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3 -L/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../../../i386-portbld-freebsd10.0/lib -L/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../.. cpptest.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/crtend.o /usr/lib/crtn.o However, at runtime, it links against the system libstdc++: $ ldd ./cpptest ./cpptest: libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x28098000) libm.so.5 = /lib/libm.so.5 (0x28171000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2818d000) libc.so.7 = /lib/libc.so.7 (0x28198000) Some (simple) C++ programs handle this just fine, others die horribly... ___ 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
Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
Howdy, I had the previous version of virtualbox working just fine on my up-to-date 8-stable i386 system, and upgraded to 4.1.8 today. When I attempt to load vboxdrv it instantly panics my system: panic: vm_object_deallocate: object deallocated too many times: 4 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper(c08f2883,1,c118de58,1,c7c08e58,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0918c49,1,c091164e,eacfb8ac,1,...) at kdb_backtrace+0x2a panic(c091164e,4,c09112d7,1e9,0,...) at panic+0x117 vm_object_deallocate(c7c08e58,e8ba3000,e8ba5000,0,eacfb918,...) at vm_object_deallocate+0x347 FreeBSDAllocHelper(1,3,0,2000,0,...) at FreeBSDAllocHelper+0x11e rtR0MemObjNativeAllocCont(c6731b20,2000,0,c672a5b2,1,...) at rtR0MemObjNativeAllocCont+0x56 supdrvInitDevExt(c6731ae0,33c,7a,c740b380,c67315e8,...) at supdrvInitDevExt+0xdd VBoxDrvFreeBSDModuleEvent(c740b380,0,0,75,0,...) at VBoxDrvFreeBSDModuleEvent+0x46 module_register_init(c67315e8,0,c08ebecc,e7,0,...) at module_register_init+0xa7 linker_load_module(0,eacfbc34,c08ebecc,3fa,0,...) at linker_load_module+0xa05 kern_kldload(c7bd3580,c62e4800,eacfbc5c,0,c7befac0,...) at kern_kldload+0xca kldload(c7bd3580,eacfbcec,0,c,246,...) at kldload+0x74 syscall(eacfbd28) at syscall+0x270 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (304, FreeBSD ELF32, kldload), eip = 0x280d69fb, esp = 0xbfbfe70c, ebp = 0xbfbfebf8 --- KDB: enter: panic Full core.text.2 is at freefall:~dougb/ -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: rtld or lang/gcc cannot find libgcc_s.so.1
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 ? man ld -rpath dir Add a directory to the runtime library search path. This is used when linking an ELF executable with shared objects. All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime. The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link; see the description of the -rpath-link option. If -rpath is not used when linking an ELF executable, the contents of the environment variable LD_RUN_PATH will be used if it is defined. Or is this another problem? -rpath is added in /usr/ports/Mk However, at runtime, it links against the system libstdc++: I ran into this with two of my own ports. -rpath needed to be passed to ld. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ 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, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote: Sorry about the cross post, but I can't tell if this a -current issue of a -ports issue. Unfortunately, I updated my freebsd 10.0 systems and the lang/gcc port during the same timeframe. I have compiled my math library and several programs with gfortran, which is installed by lang/gcc (pkg_info shows gcc-4.6.2_1). When I try running the program I get troutmask:kargl[210] halfspace /lib/libgcc_s.so.1: version GCC_4.6.0 required by /home/kargl/bin/halfspace not foundtroutmask:kargl[211] (Note, the annoying absense of a newline character after the error message, which is a completely different issue.) I see this problem on both freebsd-i386 and freebsd-amd64. troutmask:kargl[212] ldd ~/bin/halfspace /home/kargl/bin/halfspace: liblapack.so.4 = /usr/local/lib/liblapack.so.4 (0x2008c3000) libblas.so.2 = /usr/local/lib/libblas.so.2 (0x201463000) libgfortran.so.3 = /usr/local/lib/gcc46/libgfortran.so.3 (0x20175d000) libm.so.5 = /lib/libm.so.5 (0x201a7) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x201c95000) libquadmath.so.0 = /usr/local/lib/gcc46/libquadmath.so.0 (0x201ea2000) libc.so.7 = /lib/libc.so.7 (0x2020d6000) troutmask:kargl[212] 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 So, it appears that rtld is finding the wrong libgcc_s.so.1 or the lang/gcc port is no longer providing sufficient information for rtld to choose the correct library. I have reverted revisions 230784, 299768, and 229508 (and various combinitions of these revisions) from rtld-elf. The result does not change the above error. I can work around the problem by specifying -static during the building of my programs. Or, I can work around the problem by *explicitly* adding '-rpath /usr/local/lib' to the command line, which I have never had to do. I highly suspect that you just happen to not need a symbol from the newest namespace before. The thing to look first is the library search path in the ld.so hints, which is output at the second line of ldconfig -r. I think that you have /lib before /usr/local/lib/gcc46 in your setup. This guess is confirmed by the numeration of the two instances of gcc_s above. Either change the config, or use -rpath. AFAIR, ldconfig -m adds the directory at the end of the search list. pgpCP0Lz8ObQK.pgp Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
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.
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.
4) Suggestions from people that are brighter than I.
--
Steve
___
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
INDEX build failed for 7.x
INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. make_index: rubygem-statsd-0.5.4: no entry for /usr/ports/databases/rubygem-mongo Committers on the hook: dinoex jgh pgollucci Most recent CVS update was: U devel/Makefile U devel/gnustep-make/Makefile U devel/gnustep-make/distinfo U devel/rubygem-mongo/Makefile U devel/rubygem-mongo/distinfo U devel/rubygem-mongo/pkg-descr U devel/rubygem-ruby-statsd/Makefile U devel/rubygem-ruby-statsd/distinfo U devel/rubygem-ruby-statsd/pkg-descr U mail/p5-FuzzyOcr/Makefile U security/py-keyring/Makefile U security/py-keyring/distinfo U security/py-keyring/pkg-plist ___ 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: kdelibs3
Committed, thanks! Oliver Pinter píše v út 21. 02. 2012 v 01:41 +0100: Hi all! Please apply the attached patch to x11/kdelibs3/Makefile. -- -- Pav Lucistnik p...@oook.cz p...@freebsd.org With sufficient thrust, pigs fly just fine. -- RFC 1925 signature.asc Description: This is a digitally signed message part
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Wed, Feb 22, 2012 at 12:22:50AM +0100, Mel Flynn wrote: On 2/21/2012 23:32, 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. Make sure it's your binary pulling in libgcc_s. I just went through a few iterations of recompiling mplayer with different *FLAGS and each time base gcc_s was pulled in. I then did an ldd -a `which mplayer` and saw libschroedinger was the one actually pulling it in. I already did the ldd song and dance. -- Steve ___ 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 2/21/2012 23:32, 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. Make sure it's your binary pulling in libgcc_s. I just went through a few iterations of recompiling mplayer with different *FLAGS and each time base gcc_s was pulled in. I then did an ldd -a `which mplayer` and saw libschroedinger was the one actually pulling it in. Recompiled libschroedinger with gcc46 by putting USE_GCC=46 in the Makefile and sure enough: % ldd `which mplayer`|grep gcc libgcc_s.so.1 = /usr/local/lib/gcc46/libgcc_s.so.1 (0x29625000) In short, bsd.gcc.mk is doing the right thing, but dependencies may screw things up. -- Mel ___ 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, Feb 21, 2012 at 06:39:36PM -0500, Daniel Eischen wrote:
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/ ??
yes. sorry about the typo.
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?
Well, yes, I suppose that could be a problem. :)
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?
Interesting idea. Perhaps, the port should install libgcc46_s.so.1,
and binaries installed by lang/gcc updated to use this library.
o Change affected ports to use -rpath when building?
I started to look into this option, but it quickly becomes
apparent that some (evil) configure hackery may be needed.
--
Steve
___
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: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
on 22/02/2012 00:02 Doug Barton said the following:
Howdy,
I had the previous version of virtualbox working just fine on my
up-to-date 8-stable i386 system, and upgraded to 4.1.8 today. When I
attempt to load vboxdrv it instantly panics my system:
panic: vm_object_deallocate: object deallocated too many times: 4
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper(c08f2883,1,c118de58,1,c7c08e58,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(c0918c49,1,c091164e,eacfb8ac,1,...) at kdb_backtrace+0x2a
panic(c091164e,4,c09112d7,1e9,0,...) at panic+0x117
vm_object_deallocate(c7c08e58,e8ba3000,e8ba5000,0,eacfb918,...) at
vm_object_deallocate+0x347
FreeBSDAllocHelper(1,3,0,2000,0,...) at FreeBSDAllocHelper+0x11e
rtR0MemObjNativeAllocCont(c6731b20,2000,0,c672a5b2,1,...) at
rtR0MemObjNativeAllocCont+0x56
Ah, embarrassing.
Could you please substitute the attached patch file for the corresponding file
in the port and re-test the port?
supdrvInitDevExt(c6731ae0,33c,7a,c740b380,c67315e8,...) at
supdrvInitDevExt+0xdd
VBoxDrvFreeBSDModuleEvent(c740b380,0,0,75,0,...) at
VBoxDrvFreeBSDModuleEvent+0x46
module_register_init(c67315e8,0,c08ebecc,e7,0,...) at
module_register_init+0xa7
linker_load_module(0,eacfbc34,c08ebecc,3fa,0,...) at
linker_load_module+0xa05
kern_kldload(c7bd3580,c62e4800,eacfbc5c,0,c7befac0,...) at kern_kldload+0xca
kldload(c7bd3580,eacfbcec,0,c,246,...) at kldload+0x74
syscall(eacfbd28) at syscall+0x270
Xint0x80_syscall() at Xint0x80_syscall+0x21
--- syscall (304, FreeBSD ELF32, kldload), eip = 0x280d69fb, esp =
0xbfbfe70c, ebp = 0xbfbfebf8 ---
KDB: enter: panic
Full core.text.2 is at freefall:~dougb/
--
Andriy Gapon
--- src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c.orig 2011-12-19
15:01:31.0 +0200
+++ src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c 2012-02-22
01:48:41.528856970 +0200
@@ -5,6 +5,7 @@
/*
* Copyright (c) 2007 knut st. osmundsen bird-src-s...@anduin.net
+ * Copyright (c) 2011 Andriy Gapon a...@freebsd.org
*
* Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
@@ -54,23 +55,8 @@
/** The core structure. */
RTR0MEMOBJINTERNAL Core;
/** Type dependent data */
-union
-{
-/** Non physical memory allocations */
-struct
-{
-/** The VM object associated with the allocation. */
-vm_object_t pObject;
-} NonPhys;
-/** Physical memory allocations */
-struct
-{
-/** Number of pages */
-uint32_tcPages;
-/** Array of pages - variable */
-vm_page_t apPages[1];
-} Phys;
-} u;
+/** The VM object associated with the allocation. */
+vm_object_t pObject;
} RTR0MEMOBJFREEBSD, *PRTR0MEMOBJFREEBSD;
@@ -125,25 +111,14 @@
switch (pMemFreeBSD-Core.enmType)
{
-case RTR0MEMOBJTYPE_CONT:
-contigfree(pMemFreeBSD-Core.pv, pMemFreeBSD-Core.cb, M_IPRTMOBJ);
-break;
-
case RTR0MEMOBJTYPE_PAGE:
+case RTR0MEMOBJTYPE_LOW:
+case RTR0MEMOBJTYPE_CONT:
{
rc = vm_map_remove(kernel_map,
(vm_offset_t)pMemFreeBSD-Core.pv,
(vm_offset_t)pMemFreeBSD-Core.pv +
pMemFreeBSD-Core.cb);
AssertMsg(rc == KERN_SUCCESS, (%#x, rc));
-
-vm_page_lock_queues();
-for (uint32_t iPage = 0; iPage pMemFreeBSD-u.Phys.cPages;
iPage++)
-{
-vm_page_t pPage = pMemFreeBSD-u.Phys.apPages[iPage];
-vm_page_unwire(pPage, 0);
-vm_page_free(pPage);
-}
-vm_page_unlock_queues();
break;
}
@@ -165,8 +140,8 @@
case RTR0MEMOBJTYPE_RES_VIRT:
{
vm_map_t pMap = kernel_map;
-if (pMemFreeBSD-Core.u.Lock.R0Process != NIL_RTR0PROCESS)
-pMap = ((struct proc
*)pMemFreeBSD-Core.u.Lock.R0Process)-p_vmspace-vm_map;
+if (pMemFreeBSD-Core.u.ResVirt.R0Process != NIL_RTR0PROCESS)
+pMap = ((struct proc
*)pMemFreeBSD-Core.u.ResVirt.R0Process)-p_vmspace-vm_map;
rc = vm_map_remove(pMap,
(vm_offset_t)pMemFreeBSD-Core.pv,
(vm_offset_t)pMemFreeBSD-Core.pv +
pMemFreeBSD-Core.cb);
@@ -180,7 +155,6 @@
if (pMemFreeBSD-Core.u.Mapping.R0Process != NIL_RTR0PROCESS)
pMap = ((struct proc
*)pMemFreeBSD-Core.u.Mapping.R0Process)-p_vmspace-vm_map;
-
rc = vm_map_remove(pMap,
(vm_offset_t)pMemFreeBSD-Core.pv,
(vm_offset_t)pMemFreeBSD-Core.pv +
pMemFreeBSD-Core.cb);
@@ -191,26 +165,21 @@
case RTR0MEMOBJTYPE_PHYS:
case RTR0MEMOBJTYPE_PHYS_NC:
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
INDEX build failed for 7.x
INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. make_index: rubygem-statsd-0.5.4: no entry for /usr/ports/databases/rubygem-mongo Committers on the hook: dinoex jgh pav pgollucci Most recent CVS update was: U converters/py-unidecode/Makefile U converters/py-unidecode/distinfo U converters/py-unidecode/pkg-descr U x11/kdelibs3/Makefile ___ 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 11:42:59 -0800 Steve Kargl s...@troutmask.apl.washington.edu wrote: On Tue, Feb 21, 2012 at 08:57:54PM +0200, Konstantin Belousov wrote: On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote: troutmask:kargl[210] halfspace /lib/libgcc_s.so.1: version GCC_4.6.0 required by /home/kargl/bin/halfspace not foundtroutmask:kargl[211] (Note, the annoying absense of a newline character after the error message, which is a completely different issue.) I see this problem on both freebsd-i386 and freebsd-amd64. troutmask:kargl[212] ldd ~/bin/halfspace /home/kargl/bin/halfspace: liblapack.so.4 = /usr/local/lib/liblapack.so.4 (0x2008c3000) libblas.so.2 = /usr/local/lib/libblas.so.2 (0x201463000) libgfortran.so.3 = /usr/local/lib/gcc46/libgfortran.so.3 (0x20175d000) libm.so.5 = /lib/libm.so.5 (0x201a7) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x201c95000) libquadmath.so.0 = /usr/local/lib/gcc46/libquadmath.so.0 (0x201ea2000) libc.so.7 = /lib/libc.so.7 (0x2020d6000) troutmask:kargl[212] 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 So, it appears that rtld is finding the wrong libgcc_s.so.1 or the lang/gcc port is no longer providing sufficient information for rtld to choose the correct library. I have reverted revisions 230784, 299768, and 229508 (and various combinitions of these revisions) from rtld-elf. The result does not change the above error. I can work around the problem by specifying -static during the building of my programs. Or, I can work around the problem by *explicitly* adding '-rpath /usr/local/lib' to the command line, which I have never had to do. I highly suspect that you just happen to not need a symbol from the newest namespace before. The thing to look first is the library search path in the ld.so hints, which is output at the second line of ldconfig -r. I think that you have /lib before /usr/local/lib/gcc46 in your setup. This guess is confirmed by the numeration of the two instances of gcc_s above. Either change the config, or use -rpath. AFAIR, ldconfig -m adds the directory at the end of the search list. 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. I tried reading rtld.c to see where the issue lies. One possibility seems to be a change in rtld.c (lines 4012-13) to remember the version mismatch, then continuing the search to see if another library with the same name but different location matches. After exhausting the list of directories in the search path, either an error is reported or a match has been found. Note, I'm still trying to parse and understand the rtld.c code, so may be what I'm suggesting is not feasible. This was suggested before in a slightly different context and at the time I was not big fan of the idea. With more ports starting to use out of tree GCC, maybe we need to revisit the idea. There are corner cases that I do not know how to handle in this approach: what happens if we have mapped system libgcc_s.so.1 already which did satisfy all the requirements and later a new library gets mapped in dynamically and requires symbol versions from newer GCC? Going with this suggestion will likely involve substantial changes into rtld dependency walking code - we'll need to make a graph traversal and collect all the version information from all the libraries that might satisfy the search before doing the final pass of loading the winning candidates, which implies at least two dependency tree passes. And, given the above, it won't even give us what we want anyway as long as there's dlopen in the picture, so I'd say it is not worth the trouble. Just changing the compiler to supply rpath on binaries it builds might be safer approach. Various GCC builds on Solaris (OpenCSW, Sunfreeware, etc) are doing this for ages and mostly manage to pull things off. Third option is of course purging _all_ toolchain components out of the tree, which is such a fine bikeshed material that I am a bit scared to bring that up. -- Alexander Kabaev signature.asc Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012 15:52:08 -0800
Steve Kargl s...@troutmask.apl.washington.edu wrote:
On Tue, Feb 21, 2012 at 06:39:36PM -0500, Daniel Eischen wrote:
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/ ??
yes. sorry about the typo.
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?
Well, yes, I suppose that could be a problem. :)
4) Suggestions from people that are brighter than I.
Well, newer libgcc_s.so.1 should be backward compatible with older
ones, so that should not be the problem and if there are any, we need
to find and fix them.
[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?
Interesting idea. Perhaps, the port should install libgcc46_s.so.1,
and binaries installed by lang/gcc updated to use this library.
'shared' portion of libgcc was meant to _be_ shared specifically and in
general having two copies of unwind code and two copied of unwind
frames handling logic is probably not what GCC is expecting.
o Change affected ports to use -rpath when building?
I started to look into this option, but it quickly becomes
apparent that some (evil) configure hackery may be needed.
It can be done in GCC specs for all the programs that use CC driver to
to the linking. Of course, all direct LD invocations will need to be
found and fixed as well, but those were always fragile anyway.
--
Steve
___
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
--
Alexander Kabaev
signature.asc
Description: PGP signature
devel/p5-B-Hooks-OP-Check-EntersubForCV
The port is currently tagged: BROKEN= does not configure and I don't see any PRs for it. Do you have plans to look at it? Do you need any help? Thanks, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
On 02/21/2012 15:51, Andriy Gapon wrote: Could you please substitute the attached patch file for the corresponding file in the port and re-test the port? Good news, the kernel didn't panic. Bad news: supdrvGipCreate: failed to allocate the GIP page. rc=-8 vboxdrv: supdrvInitDevExt failed, rc=-8 module_register_init: MOD_LOAD (vboxdrv, 0xc66f33e0, 0) error 12 and although kldstat shows the module as loaded, and the control panel starts, when I try to launch a vm I get this: Kernel driver not installed (rc=-1908) Make sure the kernel module has been loaded successfully. hth, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: graphics/png does not build with lang/gcc
Hi, Reminder - any pointers on this one? Including Doug who had posted similar problem in 2010. On Sat, Feb 18, 2012 at 4:17 PM, Gautam l...@execve.net wrote: Hi, I am running GENERIC on FreeBSD 9.0-STABLE FreeBSD 9.0-STABLE #2: Mon Jan 30 04:18:20 IST 2012 with the tree csupped just before the build. I setup lang/gcc as per http://www.freebsd.org/doc/en/articles/custom-gcc/article.html added following to /etc/make.conf CC=gcc46 CXX=g++46 CPP=cpp46 and the following to /etc/libmap.config libgcc_s.so.1 gcc46/libgcc_s.so.1 libgomp.so.1gcc46/libgomp.so.1 libobjc.so.3gcc46/libobjc.so.2 libssp.so.0 gcc46/libssp.so.0 libstdc++.so.6 gcc46/libstdc++.so.6 When I tried to rebuild some ports, I found a problem with linking graphics/png. I found a similar problem mentioned in http://lists.freebsd.org/pipermail/freebsd-ports/2010-June/062166.html* *but no conclusion to the same. # idprio 31 make === License check disabled, port has not defined LICENSE === Found saved configuration for png-1.4.8 === Extracting for png-1.4.8 = SHA256 Checksum OK for libpng-1.4.8.tar.xz. = SHA256 Checksum OK for libpng-1.4.8-apng.patch.gz. . gcc46 -fpic -DPIC -O2 -pipe -march=pentium4 -fno-strict-aliasing -march=pentium4 -I. -std=gnu99 -fstack-protector -c pngpread.c -o pngpread.So gzip -cn libpng.3 libpng.3.gz gzip -cn libpngpf.3 libpngpf.3.gz gzip -cn png.5 png.5.gz gcc46 -O2 -pipe -march=pentium4 -fno-strict-aliasing -march=pentium4 -I. -std=gnu99 -fstack-protector -c pngtest.c building static png library building shared library libpng.so.6 ranlib libpng.a pngread.So: In function `png_create_read_struct_2': pngread.c:(.text+0x4e7): undefined reference to `__stack_chk_fail_local' pngrutil.So: In function `png_inflate': pngrutil.c:(.text+0x166): undefined reference to `__stack_chk_fail_local' pngrutil.So: In function `png_decompress_chunk': pngrutil.c:(.text+0x6e6): undefined reference to `__stack_chk_fail_local' pngrutil.So: In function `.L69': pngrutil.c:(.text+0x90f): undefined reference to `__stack_chk_fail_local' pngrutil.So: In function `png_handle_cHRM': pngrutil.c:(.text+0x1431): undefined reference to `__stack_chk_fail_local' pngrutil.So:pngrutil.c:(.text+0x19d9): more undefined references to `__stack_chk_fail_local' follow collect2: ld returned 1 exit status *** Error code 1 gcc46 -O2 -pipe -march=pentium4 -fno-strict-aliasing -march=pentium4 -I. -std=gnu99 -fstack-protector -L. -static -o pngtest pngtest.o -lpng -lz -lm 1 error *** Error code 1 Stop in /usr/ports/graphics/png. *** Error code 1 Stop in /usr/ports/graphics/png. --- I have seen different workarounds for this online for e.g, SSP_CFLAGS= in /etc/make.conf or patching /etc/rc.d/ldconfig to pick up /usr/local/lib/gcc46 first but somehow these do not seem clean enough. Or is it a straightforward port specific problem -- that needs to be fixed in graphics/png. I suspect that I am not alone in wanting to build ports with lang/gcc, so how are others avoiding this situation? Thanks in advance! Gautam ___ 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.
I think there is perhaps a little more to this issue of multiple
(incompatible) copies of a library with the same name being installed,
e.g. libcom_err in /usr/lib/libcom_err.so and
/usr/local/lib/libcom_err.so. An application using the library must
#include com_err.h to get the library prototypes, but the preprocessor
puts the standard include search path /usr/include at the end of the
search list, even if it is specified explicitly on the command line,
unless -nostdinc is passed. So this will prefer the header from ports in
the absence of evil trickery.
I was pounding my head against this a couple years ago, so my memory is
not quite fresh, but I think that I could convince the compile-time link
step to use either version of the library with the appropriate ordering of
-L arguments (but I am in trouble if I want libkrb5.so from ports and
libcom_err.so from base!).
In any case, the dynamic linker will search the default search path
*first*, preferring the copy of the library from the base system. After
pounding my head against the issue for a while I concluded that I had no
option other than to use -rpath (but alas I ran out of time for that
particular project and never finished).
It is definitely an ugly situation and I have no good answers. It would
be nice to not have to specify every detail of what should be happening,
though.
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.
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.
4) Suggestions from people that are brighter than I.
How would things break if we made everything in the base system specify
-rpath of /lib and /usr/lib as appropriate, and then put the ports
versions first in the default search path?
-Ben Kaduk
___
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
INDEX build failed for 7.x
INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. make_index: py27-graphite-web-0.9.9: no entry for /usr/ports/databases/py-carbon make_index: py27-graphite-web-0.9.9: no entry for /usr/ports/databases/py-carbon Committers on the hook: dinoex jgh pav pgollucci swills wen Most recent CVS update was: U devel/rubygem-ruby-statsd/Makefile U www/Makefile U www/py-graphite-web/Makefile U www/py-graphite-web/distinfo U www/py-graphite-web/pkg-descr U www/py-graphite-web/pkg-plist U www/py-graphite-web/files/patch-setup.cfg U www/py-graphite-web/files/patch-setup.py U x11-toolkits/p5-Prima/Makefile ___ 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 Feb 21, 2012, at 3:39 PM, Daniel Eischen wrote: On Tue, 21 Feb 2012, Steve Kargl wrote: 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? Why not? Would it cause problems? Is libgcc from GCC 4.6 incompatible with /lib/libgcc? If I understand correctly, the libgcc in base is pretty stripped down compared to regular libgcc, because most of that stuff is in our libc instead. So if there were compatibility problems, I'd expect those to show up when GCC 4.6 linked programs against /usr/local/.../libgcc and /lib/libc. Tim ___ 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: INDEX build failed for 7.x
Looks like an ordering issue to me.
http://www.freebsd.org/cgi/cvsweb.cgi/ports/databases/py-carbon/
#!/bin/sh
tree=$1
if [ $tree = ports ]; then
export PORTSDIR=/usr/ports
else
export PORTSDIR=/space/portstrees/$tree/ports
fi
export LOCALBASE=/nonexistent
export ARCH=i386
export __MAKE_CONF=/dev/null
export PORT_DBDIR=/nonexistent
export PKG_DBDIR=/nonexistent
export INDEX_PRISTINE=1
export INDEX_JOBS=24
export INDEX_QUIET=1
now=$(date +%Y%m%d%H%M%S)
cd ${PORTSDIR}
make -j9 index ~/make_index-${now}
cat ~/make_index-${now}
05:43 @pgollucci Generating INDEX-9 - please wait.. Done.
On 02/22/12 05:15, Erwin Lansing wrote:
INDEX build failed with errors:
Generating INDEX-7 - please wait.. Done.
make_index: py27-graphite-web-0.9.9: no entry for
/usr/ports/databases/py-carbon
make_index: py27-graphite-web-0.9.9: no entry for
/usr/ports/databases/py-carbon
Committers on the hook:
dinoex jgh pav pgollucci swills wen
Most recent CVS update was:
U devel/rubygem-ruby-statsd/Makefile
U www/Makefile
U www/py-graphite-web/Makefile
U www/py-graphite-web/distinfo
U www/py-graphite-web/pkg-descr
U www/py-graphite-web/pkg-plist
U www/py-graphite-web/files/patch-setup.cfg
U www/py-graphite-web/files/patch-setup.py
U x11-toolkits/p5-Prima/Makefile
___
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
--
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354
Member, Apache Software Foundation
Committer,FreeBSD Foundation
Consultant, P6M7G8 Inc.
Director Operations, Ridecharge Inc.
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
signature.asc
Description: OpenPGP digital signature
INDEX now builds successfully on 7.x
___ 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
