Re: Initial list of ports that fail due to -pthread
Kris Kennaway [EMAIL PROTECTED] wrote: mp3blaster-3.1.3 I have a patch, will talk to maintainer. -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 01:49:50AM -0400, Daniel Eischen wrote: If FreeBSD wants to take the simple approach and only support one thread library in ports (-pthread == -lpthread) and not make it selectable via PTHREAD_LIBS, then its not a problem. It would be nice to be able to support all our thread libraries, but I grow weary. Just an idea (I hope this hasn't been said before in the mega thread but at least I didn't get it this way): - fix all ports to respect PTHREAD_LIBS _ON THE LINKING STAGE_ (so no global search replace, for it shouldn't be used in compile command lines) - keep '-pthread' as a compiler option, which maps to a NOOP for compiling and '-lpthread' (aka libkse) for linking - set PTHREAD_LIBS to the default value of -pthread - allow PTHREAD_LIBS to be set to something other, e.g. '-lthr', in /etc/make.conf (or the make command line) What is the problem with this approach? You get both a 'standard' -pthread knob, _and_ the ability to select your threads library using ports. Third party apps that use -pthread will work. The only case in which some work has to be done by a FreeBSD user is when they want to link a non-ported third-party app with a library other than libpthread (libkse). --Stijn -- Linux has many different distributions, meaning that you can probably find one that is exactly what you want (I even found one that looked like a Unix system). -- Mike Meyer, from a posting at [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Initial list of ports that fail due to -pthread
On Wed, 24 Sep 2003, John Birrell wrote: On Wed, Sep 24, 2003 at 01:49:50AM -0400, Daniel Eischen wrote: It would be nice to be able to support all our thread libraries, but I grow weary. I grow weary yesterday. You've just been around a little longer than I have! -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 08:01:35AM +0200, Stijn Hoop wrote: - fix all ports to respect PTHREAD_LIBS _ON THE LINKING STAGE_ (so no global search replace, for it shouldn't be used in compile command lines) - keep '-pthread' as a compiler option, which maps to a NOOP for compiling and '-lpthread' (aka libkse) for linking - set PTHREAD_LIBS to the default value of -pthread - allow PTHREAD_LIBS to be set to something other, e.g. '-lthr', in /etc/make.conf (or the make command line) What is the problem with this approach? You get both a 'standard' -pthread knob, _and_ the ability to select your threads library using ports. Third party apps that use -pthread will work. The only case in which some work has to be done by a FreeBSD user is when they want to link a non-ported third-party app with a library other than libpthread (libkse). I think you are probably right. We need to remember that third party apps fit best in ports if they work out of the box without patches and twiddles. We probably should only rely on PTHREAD_LIBS for the non-standard cases where people want to be clever. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Wed, 24 Sep 2003, Stijn Hoop wrote: On Wed, Sep 24, 2003 at 01:49:50AM -0400, Daniel Eischen wrote: If FreeBSD wants to take the simple approach and only support one thread library in ports (-pthread == -lpthread) and not make it selectable via PTHREAD_LIBS, then its not a problem. It would be nice to be able to support all our thread libraries, but I grow weary. Just an idea (I hope this hasn't been said before in the mega thread but at least I didn't get it this way): - fix all ports to respect PTHREAD_LIBS _ON THE LINKING STAGE_ (so no global search replace, for it shouldn't be used in compile command lines) This sounds nice, but I don't know that there really is much difference in changes needed. - keep '-pthread' as a compiler option, which maps to a NOOP for compiling and '-lpthread' (aka libkse) for linking That's already the case; -pthread never did anything on the compile, only the link. - set PTHREAD_LIBS to the default value of -pthread - allow PTHREAD_LIBS to be set to something other, e.g. '-lthr', in /etc/make.conf (or the make command line) This is already the path that ports is going down :-) -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 02:11:53AM -0400, Daniel Eischen wrote: On Wed, 24 Sep 2003, Stijn Hoop wrote: Just an idea (I hope this hasn't been said before in the mega thread but at least I didn't get it this way): - fix all ports to respect PTHREAD_LIBS _ON THE LINKING STAGE_ (so no global search replace, for it shouldn't be used in compile command lines) This sounds nice, but I don't know that there really is much difference in changes needed. Well it avoids gcc warnings in case PTHREAD_LIBS == '-lkse'. That's about the only reason I can think of to make the distinction between compiling linking. - keep '-pthread' as a compiler option, which maps to a NOOP for compiling and '-lpthread' (aka libkse) for linking That's already the case; -pthread never did anything on the compile, only the link. OK, but let's keep it that way then. Isn't the removal of -pthread that started all this? - set PTHREAD_LIBS to the default value of -pthread - allow PTHREAD_LIBS to be set to something other, e.g. '-lthr', in /etc/make.conf (or the make command line) This is already the path that ports is going down :-) Well, great. Let's go and fix some ports then, and everybody will be happy :) But if this is really the way to go, we probably need some hack to bsd.port.mk to make PTHREAD_LIBS standard because otherwise every port that needs a threads library needs to have PTHREAD_LIBS hacks. --Stijn -- Help Wanted: Telepath. You know where to apply. pgp0.pgp Description: PGP signature
Re: Initial list of ports that fail due to -pthread
Kris Kennaway wrote: Here is a partial list of the ports that need to be taught to respect PTHREAD_LIBS and PTHREAD_CFLAGS, from the latest 5.x package build (I [skipped] omniORB-4.0.2 PR/56862 is waiting for ports unfreezing. -- Sem. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Tue, Sep 23, 2003 at 07:18:21PM -0700, Kris Kennaway wrote: pwlib-1.5.0_2 I have sent patches for pwlib and gnomemeeting to the maintainer shortly after the gnome2.4 import, and he said they would be commited (with a slight modification) when the ports freeze was lifted. -- Morten Rodal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
* Will Andrews [EMAIL PROTECTED] [030924 01:50]:
On Wed, Sep 24, 2003 at 01:34:13AM -0400, Michael Edenfield wrote:
One very important group of ports that should get looked at when this
gets worked out is KDE. Apparently, Qt uses a different means of
determining wether to use threading, than the ports that depend on it.
The qt-using ports appear to check for -lpthread, then c++ -pthread, and
if neither of those checks pass, disable threading:
Also, I believe I fixed qt32 on 18 September 2003. It certainly
built and works fine on my 5.1-CURRENT 2003/09/19 box. It's just
KDE that needs fixing at the moment.
Yes, Qt itself worked fine, it was just the rest of KDE that gave me
issues. I've already fixed the issue temporarily by passing --enable-mt
and --enable-threading as CONFIGURE_ARGS and doing some post-configure
replacing of -{l}pthread, I just wanted to point out the problem since
it's slightly different than just 'cc breaks because -pthread is an
error.'
But since you're already well ahead of me fixing it I'll skip the pr I
was about to send in :)
--Mike
pgp0.pgp
Description: PGP signature
Re: Initial list of ports that fail due to -pthread
On Wednesday 24 September 2003 04:18, Kris Kennaway wrote: icecast-1.3.12_1 I don't have a -CURRENT machine to test with. I don't mind the port marked BROKEN, since it's unsupported abandonware and due for deorbit anyway. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: signature
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 06:14:52PM +0200, Michael Nottebrock wrote: Content-Description: signed data On Wednesday 24 September 2003 04:18, Kris Kennaway wrote: icecast-1.3.12_1 I don't have a -CURRENT machine to test with. I don't mind the port marked BROKEN, since it's unsupported abandonware and due for deorbit anyway. I object. The Icecast team have barely even documented how to configure Icecast 2 nor have they provided a means of cleanly migrating to the new XML configuration format. SPC is one organization who make a lot of use of this particular port, I am sure there are others. If you must kill it off at least give us time to bury it properly. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Wednesday 24 September 2003 19:36, Bruce M Simpson wrote: On Wed, Sep 24, 2003 at 06:14:52PM +0200, Michael Nottebrock wrote: Content-Description: signed data On Wednesday 24 September 2003 04:18, Kris Kennaway wrote: icecast-1.3.12_1 I don't have a -CURRENT machine to test with. I don't mind the port marked BROKEN, since it's unsupported abandonware and due for deorbit anyway. I object. The Icecast team have barely even documented how to configure Icecast 2 nor have they provided a means of cleanly migrating to the new XML configuration format. SPC is one organization who make a lot of use of this particular port, I am sure there are others. If you must kill it off at least give us time to bury it properly. Don't worry, a port deorbit takes a very long time and right now I'm merely thinking out loud, there's no countdown started yet. But keep in mind that this doesn't change the facts: Icecast 1 _is_ unsupported abandonware, and it is by any means not too early to start investigating the migration to other software. That said, if you have a fix going for the -pthread issue on -CURRENT, I'd appreciate (and commit). -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: signature
Initial list of ports that fail due to -pthread
Here is a partial list of the ports that need to be taught to respect PTHREAD_LIBS and PTHREAD_CFLAGS, from the latest 5.x package build (I just grepped for the -pthread is deprecated error message). None of these were fixed by ports/57047. It is likely that there are many more that also need to be fixed - either they fail in other ways, or are hidden by depending on another port that currently fails. Since the ports tree is currently frozen for 4.9-R, fixes cannot immediately be committed to fix these. Instead, fixes should be stockpiled in private CVS repositories until the freeze ends. If you are interested in helping to fix these errors (or already have a fix), please let me know. 54321-1.0.2001.11.16 aget-0.4 aleph-0.8.2 alsaplayer-0.99.75 amavisd-new-20030616.p5 bacula-1.30a_1 bigloo-2.5a bind9-dlz-9.2.2+0.5.0 boost-1.30.0_1 cfengine-1.6.3_4 cfengine2-2.0.3 clamav-0.60_1 clanlib-0.4.4_1 directfb-0.9.16_2 doomlegacy-1.32b4 drweb_sendmail-4.29.12f evilbar-1.2.1 fasta3-33.t08.d4 firedns-0.1.30 ganglia-monitor-core-2.5.3 glui-2.1 hercules-2.17.1_1 icecast-1.3.12_1 linphone-0.11.0_2 lws-0.1.2 mimedefang-2.37 mnogosearch-3.1.20_1 mp3blaster-3.1.3 nast-0.1.7e ncbi-toolkit-2003.04.21 nitpicker-1.2.1,1 nss-3.8 ocaml-3.06 omniORB-4.0.2 openal-20030724 osrtspproxy-2.0_1 pcsc-lite-1.1.2.b.5 physfs-0.1.8 powerdns-2.9.11 pppoa-1.2b2,1 ppptraf-1.0 privoxy+ipv6-20030523_1 pwlib-1.5.0_2 py-gtkscintilla-0.8.2 qt-2.3.1_2 qt-3.1.2_1 qt-static-2.3.1_2 siege-2.56 siphon-0.666 smtprc-0.9.7 spiralsynthmodular-0.2.1 streamripper-1.0.5 sword-1.5.5 termlog-1.0.3 tinyq-3.0.6 transcode-0.6.9 trickyirc-1.1.0 vida-0.7.1 xbms-0.30.6 xwhois-0.4.2 zebedee-2.4.1 Kris pgp0.pgp Description: PGP signature
Re: Initial list of ports that fail due to -pthread
On Tue, Sep 23, 2003 at 07:18:21PM -0700, Kris Kennaway wrote: Here is a partial list of the ports that need to be taught to respect PTHREAD_LIBS and PTHREAD_CFLAGS, from the latest 5.x package build (I just grepped for the -pthread is deprecated error message). None of these were fixed by ports/57047. It is likely that there are many more that also need to be fixed - either they fail in other ways, or are hidden by depending on another port that currently fails. I had a go at fixing some of the ones listed on your status page. I started with the ones that had the greatest number of dependencies. The thing I'm not sure about is whether there is consensus that the -pthread argument should be removed from GCC. I've supported Dan's approach because I understand the background. I think there have been a few too many don't do that emails. I'm tempted to suggest that -pthread be kept and set to the default thread library (which I think should be libpthread aka libkse). If FreeBSD really wants to have an alternate thread library (libthr), then add another argument to toggle that. I know that'll make things confusing, but having more than one thread library is more confusing than a change to -pthread. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 12:32:05PM +1000, John Birrell wrote:
On Tue, Sep 23, 2003 at 07:18:21PM -0700, Kris Kennaway wrote:
Here is a partial list of the ports that need to be taught to respect
PTHREAD_LIBS and PTHREAD_CFLAGS, from the latest 5.x package build (I
just grepped for the -pthread is deprecated error message). None of
these were fixed by ports/57047. It is likely that there are many
more that also need to be fixed - either they fail in other ways, or
are hidden by depending on another port that currently fails.
I had a go at fixing some of the ones listed on your status page. I started
with the ones that had the greatest number of dependencies.
The thing I'm not sure about is whether there is consensus that the
-pthread argument should be removed from GCC. I've supported Dan's
approach because I understand the background. I think there have been a
few too many don't do that emails.
Won't these ports still need to be fixed to look at
PTHREAD_{LIBS,CFLAGS} though, since the correct values for 4.x and 5.x
will still be different?
Kris
pgp0.pgp
Description: PGP signature
Re: Initial list of ports that fail due to -pthread
On Tue, Sep 23, 2003 at 07:33:43PM -0700, Kris Kennaway wrote:
Won't these ports still need to be fixed to look at
PTHREAD_{LIBS,CFLAGS} though, since the correct values for 4.x and 5.x
will still be different?
Not if -pthread remains. Internally gcc would link to a different
library, but most ports won't see that.
--
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 12:43:54PM +1000, John Birrell wrote:
On Tue, Sep 23, 2003 at 07:33:43PM -0700, Kris Kennaway wrote:
Won't these ports still need to be fixed to look at
PTHREAD_{LIBS,CFLAGS} though, since the correct values for 4.x and 5.x
will still be different?
Not if -pthread remains. Internally gcc would link to a different
library, but most ports won't see that.
OK, I'll put this on hold until you guys sort it out :)
Kris
pgp0.pgp
Description: PGP signature
Re: Initial list of ports that fail due to -pthread
On Wed, 24 Sep 2003, John Birrell wrote:
On Tue, Sep 23, 2003 at 07:33:43PM -0700, Kris Kennaway wrote:
Won't these ports still need to be fixed to look at
PTHREAD_{LIBS,CFLAGS} though, since the correct values for 4.x and 5.x
will still be different?
Not if -pthread remains. Internally gcc would link to a different
library, but most ports won't see that.
The problem will be with ports that somehow get -lc_r
without going through PTHREAD_LIBS. And for those that
use both -lc_r and PTHREAD_LIBS, they'll build but won't
run correctly.
BTW, I just fixed zebedee (started at bottom of list).
--
Dan Eischen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
* Kris Kennaway [EMAIL PROTECTED] [030923 22:21]: Here is a partial list of the ports that need to be taught to respect PTHREAD_LIBS and PTHREAD_CFLAGS, from the latest 5.x package build (I just grepped for the -pthread is deprecated error message). None of One very important group of ports that should get looked at when this gets worked out is KDE. Apparently, Qt uses a different means of determining wether to use threading, than the ports that depend on it. The qt-using ports appear to check for -lpthread, then c++ -pthread, and if neither of those checks pass, disable threading: checking for pthread_create in -lpthread... no checking whether c++ supports -pthread... no However, Qt somehow knows that threads are supported and installs the libqt-mt version of it's libraries. The dependant ports then look for -lqt, not -lqt-mt, since they've disabled threading. I haven't updated my gcc since -pthread started working again, and this doesn't generate the typical -pthread is deprecated error, so I've been pulling my hair out for two days over it :) --Mike pgp0.pgp Description: PGP signature
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 01:34:13AM -0400, Michael Edenfield wrote: One very important group of ports that should get looked at when this gets worked out is KDE. Apparently, Qt uses a different means of determining wether to use threading, than the ports that depend on it. The qt-using ports appear to check for -lpthread, then c++ -pthread, and if neither of those checks pass, disable threading: I have been working with KDE-FreeBSD to make a patch to fix this problem since last week. I am nearly done testing it, so please bear with me and I will get it committed soon. We expect to remove it with the release of KDE 3.2 in a few months as it will be committed to HEAD in KDE. Also, I believe I fixed qt32 on 18 September 2003. It certainly built and works fine on my 5.1-CURRENT 2003/09/19 box. It's just KDE that needs fixing at the moment. I'm typing this in KDE 3.1.4 on said machine. Thanks. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Wed, 24 Sep 2003, Michael Edenfield wrote: * Kris Kennaway [EMAIL PROTECTED] [030923 22:21]: Here is a partial list of the ports that need to be taught to respect PTHREAD_LIBS and PTHREAD_CFLAGS, from the latest 5.x package build (I just grepped for the -pthread is deprecated error message). None of One very important group of ports that should get looked at when this gets worked out is KDE. Apparently, Qt uses a different means of determining wether to use threading, than the ports that depend on it. The qt-using ports appear to check for -lpthread, then c++ -pthread, and if neither of those checks pass, disable threading: checking for pthread_create in -lpthread... no checking whether c++ supports -pthread... no When libkse gets installed as libpthread, the above check will be different. But, if we want the thread library to be selectable by PTHREAD_LIBS, this isn't what you'd want if PTHREAD_LIBS != -lpthread. This was going to be the next hurdle to jump over. If FreeBSD wants to take the simple approach and only support one thread library in ports (-pthread == -lpthread) and not make it selectable via PTHREAD_LIBS, then its not a problem. It would be nice to be able to support all our thread libraries, but I grow weary. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 01:49:50AM -0400, Daniel Eischen wrote: It would be nice to be able to support all our thread libraries, but I grow weary. I grow weary yesterday. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
