INDEX build failed for 6.x
INDEX build failed with errors: Generating INDEX-6 - please wait../a/erwin/tindex/ports/Mk/bsd.gnome.mk, line 634: The Pre include part of bsd.gnome.mk part is not included. Did you forget WANT_GNOME=yes before bsd.port.pre.mk? === palm/synce-vdccm failed *** Error code 1 pkg_info: not found pkg_info: not found *** Error code 1 Stop in /a/erwin/tindex/ports. *** Error code 1 Stop in /a/erwin/tindex/ports. 1 error Committers on the hook: amdmi3 cy danfe lioux miwi rafan tdb will Most recent CVS update was: U multimedia/x264/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: LATEST_LINK not in index
Dominic Fandrey píše v st 01. 04. 2009 v 00:12 +0200: Upgrades are easy. Look up @comment ORIGIN line in +CONTENTS file of the port being upgraded, then look up this value in second column of INDEX file. I don't see how this is connected to my question. I want people to be able to use LATEST_LINK to identify ports, e.g. apache for www/apache13, apache20 form www/apache20 and so forth. LATEST_LINK is a unique identifier, unfortunately neither recorded in the INDEX nor +CONTENTS. Also, to read it from +CONTENTS (if it were there) I'd have to know, which package is actually meant, which I don't know, because this is the information I want to find out. Maybe you really want people to specify ports by ORIGIN, not by LATEST_LINK ... -- Pav Lucistnik p...@oook.cz p...@freebsd.org You can't expect to wield supreme executive power just 'cause some watery tart threw a sword at you. signature.asc Description: Toto je digitálně podepsaná část zprávy
INDEX now builds successfully on 6.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
This weeks HOT jobs and TIPS to finding new employment!
Your email client cannot read this email. To view it online, please go here: http://www.globalfmjobs.co.uk/sendstudionx/display.php?M=130904C=dbd523afe161828c7501944a6821b2a7S=77L=12N=33 To stop receiving these emails:http://www.globalfmjobs.co.uk/sendstudionx/unsubscribe.php?M=130904C=dbd523afe161828c7501944a6821b2a7L=12N=77 ___ 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: Possibly unbuildable ports reminder
On Wed, 01 Apr 2009 10:42:47 +0200, Dirk Meyer wrote: It will be useful to add RSS/Atom feeds to some pages on pointyhat.freebsd.org Insted of periodicaly polling of pointyhat, this feed can be added in rss-reader. DM DM This would be a lot of data for an RSS feed. DM Could you elaborate how this data can be mapped? DM This feeds can contain short info about new build error, with link to error log. Per-maintainer and per-port feeds will contain not lot of info. -- Anton Yuzhaninov ___ 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: Status of devel/boost upgrade
* Jeremy Messenger (me...@cox.net) wrote: No need bsd.boost.mk over that small stuff. How about resolve conflict for real by split boost and boost-python by have boost only install non-python stuff and boost-python install only python stuff? That of course would be harder and more interesting, maybe I gotta dig into it. The USE_BOOST isn't going to solve anything either because the boost-check-python still stop and tell it's conflict. Yes, but it's more verbose and it condenses hacks and checks in a single place. Also, if we solve the problem above and make boost-python only install python stuff, it will be easier to change logic in a single place. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ 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: why was XFree86 dropped for ports?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Noland wrote: On Tue, 2009-03-31 at 22:36 -0400, Chuck Robey wrote: I recently got kde4.2 working on my home box, and all the neat eye candy things that are added, I'll have to see, maybe you're right, XFree86 might not work with KDE, but saying that XFree86 hasn't had an update since December makes no sense to me, versus the fact that I *think* git allows no release tags, so I think one could argue that there are no Xorg releases at all. That, or I don't know git well enough, either is possible. If there are tags in git, I will go back and reread the git docs until I find them. git has tags and branches, all of which can be checked out from fd.o. AFAIK, things aren't tagged for Xorg releases, but all of the packages carry tags and some have release branches. I was hoping I would get an answer on this. It is indeed a feature of git, or has it been grafted on by convention? If git's got it, I'll drop this particular topic, and try to find the command I must have missed. If those features are done by convention, I guessed I was relying on the git man pages, and just didn't look hard enough at the web pages for Xorg to spot the info. I've been a bit critical of git in my mind, and need to get myself either justified or corrected. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknTyzgACgkQz62J6PPcoOlfrgCfc9/ZsGKtJOhb4xqUecVLfrhy NDoAnRcfOJdQH1OsxVBTtjlbxlN1jyLG =uHG+ -END PGP SIGNATURE- ___ 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
Chandler port .. ?
Hallo list, I've been wondering if someone here is a user of Chandler (The Note-to-Self Organizer) which is quite a great and useful application: http://chandlerproject.org/ It is a multi platform, written in Python with a few dependencies. It is available for Windows, Mac OS X and Linux (.tar.gz and .deb). The problem is that according to porters to some other (than Ubuntu) Linux distributions it is not that easy task and would require certain skills. Therefore I wonder if and wish that someone skilled would try and port Chandler to FreeBSD. :-) Thanks and regards! Martin ___ 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: Chandler port .. ?
On Wed, Apr 01, 2009 at 11:02:56PM +0200, martinko wrote: Therefore I wonder if and wish that someone skilled would try and port Chandler to FreeBSD. :-) +1 Willy -- Willy Picarde-mail: willy.pic...@ue.poznan.pl Dept. of Information Technology www:http://www.kti.ue.poznan.pl/ Poznan University of Economics tel:+48 61 848 05 49 Mansfelda 4, 60-854 Poznan, Poland fax:+48 61 848 38 40 ___ 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: Chandler port .. ?
martinko wrote: Hallo list, I've been wondering if someone here is a user of Chandler (The Note-to-Self Organizer) which is quite a great and useful application: http://chandlerproject.org/ It is a multi platform, written in Python with a few dependencies. It is available for Windows, Mac OS X and Linux (.tar.gz and .deb). The problem is that according to porters to some other (than Ubuntu) Linux distributions it is not that easy task and would require certain skills. Therefore I wonder if and wish that someone skilled would try and port Chandler to FreeBSD. :-) Thanks and regards! Martin Did you see http://chandlerproject.org/Developers/BuildingChandlerDesktop Brian ___ 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
How to name a port for MPC (the C library)
I need to package MPC (http://www.multiprecision.org/mpc/) which is going to become a prerequisite of GCC 4.5. In principle that should be simple, except that we already have ports/audio/mpc which is something quite different. Any thoughts on how to best handle this? Gerald @FreeBSD.org PS: grep mpc CVSROOT/modules gives akode-plugins-mpc ports/audio/akode-plugins-mpc gmpcports/audio/gmpc gmpc-alarm ports/audio/gmpc-alarm gmpc-autoplaylist ports/audio/gmpc-autoplaylist gmpc-extraplaylist ports/audio/gmpc-extraplaylist gmpc-favorites ports/audio/gmpc-favorites gmpc-lastfm ports/audio/gmpc-lastfm gmpc-libnotify ports/audio/gmpc-libnotify gmpc-lyrics ports/audio/gmpc-lyrics gmpc-lyricwiki ports/audio/gmpc-lyricwiki gmpc-magnatune ports/audio/gmpc-magnatune gmpc-mdcoverports/audio/gmpc-mdcover gmpc-mserverports/audio/gmpc-mserver gmpc-osdports/audio/gmpc-osd gmpc-qosd ports/audio/gmpc-qosd gmpc-random-playlistports/audio/gmpc-random-playlist gmpc-serverstatsports/audio/gmpc-serverstats gmpc-shout ports/audio/gmpc-shout gmpc-stopbutton ports/audio/gmpc-stopbutton gmpc-wikipedia ports/audio/gmpc-wikipedia gmpccaa ports/audio/gmpccaa icmpchatports/net-im/icmpchat ifd-gempc410ports/security/ifd-gempc410 libmpcbdm ports/devel/libmpcbdm libmpcdec ports/audio/libmpcdec lmpcports/games/lmpc mpc ports/audio/mpc ncmpc ports/audio/ncmpc ncmpcpp ports/audio/ncmpcpp scmpc ports/audio/scmpc stmpclean ports/sysutils/stmpclean tempcontrol ports/misc/tempcontrol wmpccardports/sysutils/wmpccard xfce4-mpc-pluginports/audio/xfce4-mpc-plugin xfmpc ports/audio/xfmpc -- Gerald (Jerry) Pfeifer ger...@pfeifer.com http://www.pfeifer.com/gerald/ ___ 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
-pthread propagation
Hi!
I have a question about -pthread. Imagine the situation where one port
installs shared library that uses threads, and other port links with
this library. A question: should the second port explicitely add
-pthread to linker flags?
For example, graphics/ilmbase is built with pthread support by default,
but it's shared libraries are not linked with -pthread:
% ldd /usr/local/lib/libIlmThread.so
/usr/local/lib/libIlmThread.so:
libIex.so.6 = /usr/local/lib/libIex.so.6 (0x2819c000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x2830)
libm.so.5 = /lib/libm.so.5 (0x281ad000)
libc.so.7 = /lib/libc.so.7 (0x2808b000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x281c6000)
no libthr.so mention. Thus,
% gcc helloworld.cc -lIlmThread -L/usr/local/lib
/usr/local/lib/libIlmThread.so: undefined reference to `pthread_create'
I assume this should be fixed in ilmbase instead of all dependent ports
(for example, graphics/nvidia-texture-tools and graphics/devil, which
supports the former), am I right? Btw, libIlmThread.la _does_ have
-pthread in dependency_libs.
However, I've encountered situations where linking with library
linked with -pthread will succeed, but the resulting binary will not
be broken. Example is games/battletanks:
When built as is (note that it has ${PTHREAD_LIBS} explicitely added to
LDFLAGS), it runs without problems. However, if you remove
${PTHREAD_LIBS}, it'll still build successfully, but won't run:
% bt
[03:04:45.449][src/main.cpp:44] [notice] starting up... version: 5800 beta
[03:04:45.449][src/main.cpp:46] [notice] mem avail: -1 mb
terminate called after throwing an instance of
'__gnu_cxx::__concurrence_lock_error'
what(): __gnu_cxx::__concurrence_lock_error
[1]58620 abort (core dumped) bt
I think that's linked with static variable initialization - it should
be protected with a mutex in threaded environment, but it doesn't happen
correctly when linking without -pthread, even if with -lthr.
I'll be really grateful if someone explains what really happens when
using -lpthread, and what happens in the above mentioned error case
(cc'ing hackers@).
So should -pthread be forced in ldflags
1) Only in ports that explicitely use threads
2) In all ports that link with -lthr implicitely, including through
other ports?
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: -pthread propagation
On Thu, 2 Apr 2009, Dmitry Marakasov wrote:
Hi!
I have a question about -pthread. Imagine the situation where one port
installs shared library that uses threads, and other port links with
this library. A question: should the second port explicitely add
-pthread to linker flags?
Yes.
For example, graphics/ilmbase is built with pthread support by default,
but it's shared libraries are not linked with -pthread:
% ldd /usr/local/lib/libIlmThread.so
/usr/local/lib/libIlmThread.so:
libIex.so.6 = /usr/local/lib/libIex.so.6 (0x2819c000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x2830)
libm.so.5 = /lib/libm.so.5 (0x281ad000)
libc.so.7 = /lib/libc.so.7 (0x2808b000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x281c6000)
no libthr.so mention. Thus,
% gcc helloworld.cc -lIlmThread -L/usr/local/lib
/usr/local/lib/libIlmThread.so: undefined reference to `pthread_create'
I assume this should be fixed in ilmbase instead of all dependent ports
(for example, graphics/nvidia-texture-tools and graphics/devil, which
supports the former), am I right? Btw, libIlmThread.la _does_ have
-pthread in dependency_libs.
Yes, all ports that use libraries that create threads on
their behalf should use -pthread.
However, I've encountered situations where linking with library
linked with -pthread will succeed, but the resulting binary will not
be broken. Example is games/battletanks:
This is probably because libc contains some simple thread
wrappers (mostly lock related stuff). They go unused unless
a thread is created (and libthr is explicitly brought in),
in which case those wrappers are overridden by libthr.
When built as is (note that it has ${PTHREAD_LIBS} explicitely added to
LDFLAGS), it runs without problems. However, if you remove
${PTHREAD_LIBS}, it'll still build successfully, but won't run:
% bt
[03:04:45.449][src/main.cpp:44] [notice] starting up... version: 5800 beta
[03:04:45.449][src/main.cpp:46] [notice] mem avail: -1 mb
terminate called after throwing an instance of
'__gnu_cxx::__concurrence_lock_error'
what(): __gnu_cxx::__concurrence_lock_error
[1]58620 abort (core dumped) bt
I think that's linked with static variable initialization - it should
be protected with a mutex in threaded environment, but it doesn't happen
correctly when linking without -pthread, even if with -lthr.
It is possible for a library to be thread-aware and thread-safe.
In this case it can play pragma weak games with pthread_create
and only use locks if pthread_create resolves to a non-null
pointer.
I'll be really grateful if someone explains what really happens when
using -lpthread, and what happens in the above mentioned error case
(cc'ing hackers@).
So should -pthread be forced in ldflags
1) Only in ports that explicitely use threads
2) In all ports that link with -lthr implicitely, including through
other ports?
It depends, libraries can be made thread-safe/aware as
above, and both threaded and non-threaded applications
can link with them just fine. Assuming those libraries
are smart about how they use the locking mechanisms,
and never use them unless they know that pthread_create
is present (or some other symbol not present in libc,
but present in libthr).
But for libraries that create threads, applications must
also link with -pthread (or -lpthread).
If you can understand it, you can see
src/contrib/gcc/gthr-posix.h for how libgcc is
thread-aware. A comment from that file:
/* On Solaris 2.6 up to 9, the libc exposes a POSIX threads
interface even if -pthreads is not specified. The
functions are dummies and most return an error value.
However pthread_once returns 0 without invoking the routine
it is passed so we cannot pretend that the interface is
active if -pthreads is not specified. On Solaris 2.5.1,
the interface is not exposed at all so we need to play the
usual game with weak symbols. On Solaris 10 and up, a
working interface is always exposed. On FreeBSD 6 and
later, libc also exposes a dummy POSIX threads interface,
similar to what Solaris 2.6 up to 9 does. FreeBSD =
700014 even provides a pthread_cancel stub in libc, which
means the alternate __gthread_active_p below cannot be used
there. */
--
DE
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: How to name a port for MPC (the C library)
On Wed, Apr 1, 2009 at 6:28 PM, Gerald Pfeifer ger...@pfeifer.com wrote: I need to package MPC (http://www.multiprecision.org/mpc/) which is going to become a prerequisite of GCC 4.5. In principle that should be simple, except that we already have ports/audio/mpc which is something quite different. Any thoughts on how to best handle this? libmpc maybe? ___ 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: HEADS UP multi processor compilations for everyone
On Wed, 25 Mar 2009 12:57:51 -0400 Coleman Kane cok...@freebsd.org wrote: On Wed, 2009-03-25 at 19:30 +0300, Dmitry Marakasov wrote: * Pav Lucistnik (p...@freebsd.org) wrote: This would break very fast -- it's passing -j3 to port Makefile instead of vendor Makefile. This has worked fine for me for countless years, except where the vendor's Makefiles were not parallel-safe. This has been my trick to get larger things (like mysql or xorg-server) to make in parallel. It *did* work. If this has changed, then it definitely warrants mention in UPDATING. Then it must have worked all these years by pure chance :) Be the way, could anyone clarify how this works? My idea was that passing -j to port Makefile does nothing, as make/gmake on vendor's Makefile is ran without any -j flags - you get usual singlethreaded build. However, I have a broken port, which uses gmake and something like that: sometarget: (cd xxx; make) and that fails with -j (make: illegal option -- -). So is there some magic with recursive make calls and -j? When processing a Makefile, make's that support concurrent operation look for targets that will execute the $(MAKE) program. Whenever a compliant make is run (make or gmake), if it detects $(MAKE) in a rule then it will automatically expand that rule into a child process that has some sort of magical connection to the parent process. The connection allows the different make processes to share the same pool of process count resources amongst each other. I am not sure what the implementation is, but this communication mechanism allows child make processes called with $(MAKE) ... from inside a Makefile to globally only use N children (from -j N), and otherwise block until more free jobs are available amongst their shared job pool. I hope that's clear... Probably more so than the explanation given on GNU make's manual. -- Coleman Kane Indeed, that is why (cd xxx; make) fails where gmake is running this command. The way GNU make and BSD make passes -j related options are different. They are not compatible. If I remember correctly, if GNU make calls BSD make (which is an error of writing Makefiles in most of vendor codes), the differences are significant and fails. Usually, changing make to $(MAKE) fixes the problems. Why did it build when -j was not supplied. That is because makefile rule was not GNU makefile specific such that BSD make could also executed it without problems. With -j switch presented, these two make commands became incompatible each other. I hope this helps if you guys haven't found this facts; I hope I had replied earlier. Regards, Hiro ___ 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
