ports and -current
Well, for weeks now I couldn't compile (almost) any port. It seems that ports aren't tested against -current. Is that true? Not only the -pthread removement broke countless ports (some of them are easy to fix others aren't) also the entire new kde fails. Is there no aim to have ports running on -current? I'm asking because my "workstation" has enough resources to track -current to help testing. But if I breake ports with -current I won't keep tracking it. Thanks, -Harry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sat, Sep 20, 2003 at 08:14:07AM +0200, Harald Schmalzbauer wrote: > Well, for weeks now I couldn't compile (almost) any port. It seems that > ports aren't tested against -current. Is that true? No. > Not only the -pthread removement broke countless ports (some of them are > easy to fix others aren't) also the entire new kde fails. > Is there no aim to have ports running on -current? Also incorrect. The 4.9 ports freeze is holding up commits to fix compile failures on 5.1. Kris pgp0.pgp Description: PGP signature
Re: ports and -current
On Sat, 20 Sep 2003 08:14:07 +0200, Harald Schmalzbauer <[EMAIL PROTECTED]> wrote: Well, for weeks now I couldn't compile (almost) any port. It seems that ports aren't tested against -current. Is that true? Not only the -pthread removement broke countless ports (some of them are easy to fix others aren't) also the entire new kde fails. Is there no aim to have ports running on -current? Check in the bottom at http://lists.freebsd.org/pipermail/freebsd-gnome/2003-September/002846.html .. I believe, we should be expect to see the many fixes for -CURRENT when the ports freeze lift. Cheers, Mezz I'm asking because my "workstation" has enough resources to track -current to help testing. But if I breake ports with -current I won't keep tracking it. Thanks, -Harry -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
Kris Kennaway wrote: On Sat, Sep 20, 2003 at 08:14:07AM +0200, Harald Schmalzbauer wrote: Well, for weeks now I couldn't compile (almost) any port. It seems that ports aren't tested against -current. Is that true? No. Not only the -pthread removement broke countless ports (some of them are easy to fix others aren't) also the entire new kde fails. Is there no aim to have ports running on -current? Also incorrect. The 4.9 ports freeze is holding up commits to fix compile failures on 5.1. Oh I see. Thats a reason. If I only knew about that freeze before my "pkg_delete -a" but that's just my problem Thanks, -Harry Kris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
Harald Schmalzbauer wrote:
Oh I see. Thats a reason. If I only knew about that freeze before my
"pkg_delete -a" but that's just my problem
Thanks,
-Harry
I unfortunatly did the same thing. I wanted to upgrade to gnome 2.4 and
seeing as this box really doesn't have any ports installed other than X
and gnome I just ran pkg_deinstall -Ofa and started from scratch
installing x11/XFree86-4 and x11/gnome2. Then realised that that may
have been a bad thing when devel/pwlib failed to compile with -pthread
issues.
Normally I am quite patient and will spend time fixing stuff, I knew how
to change -pthread into ${PTHREAD_LIBS} etc but being in a 80x25 text
console at the time with no working window manager I took the easy route
out and cvsup'd to before the pthread commits instead. Installed gnome2
which went no problems.
I will now just wait till after the 4.9 port freeze is over before going
back to the current -current level.
It's the first time I've been "bitten" as such by running -current on my
desktop, but hey. That's what running -current is all about :)
Keep up the good work, I look forward to 5.2!
Matt.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
In message: <[EMAIL PROTECTED]> Harald Schmalzbauer <[EMAIL PROTECTED]> writes: : Not only the -pthread removement broke countless ports (some of them are Maybe I missed the reason why FreeBSD needs to be unique wrt threading programs and not have -pthread... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sat, 20 Sep 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Harald Schmalzbauer <[EMAIL PROTECTED]> writes: > : Not only the -pthread removement broke countless ports (some of them are > > Maybe I missed the reason why FreeBSD needs to be unique wrt threading > programs and not have -pthread... Because -pthread allows selection of one specific threadling library, not multiple. It is also unnecessary since the library is specified as a link option, not a compiler option. In the future, -pthread will be a NOOP, but it suits us now to have it cause an error so that ports that don't honor PTHREAD_LIBS can be found and fixed. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sat, 20 Sep 2003, Daniel Eischen wrote: > On Sat, 20 Sep 2003, M. Warner Losh wrote: > > > In message: <[EMAIL PROTECTED]> > > Harald Schmalzbauer <[EMAIL PROTECTED]> writes: > > : Not only the -pthread removement broke countless ports (some of them are > > > > Maybe I missed the reason why FreeBSD needs to be unique wrt threading > > programs and not have -pthread... > > Because -pthread allows selection of one specific threadling library, > not multiple. It is also unnecessary since the library is specified > as a link option, not a compiler option. In the future, -pthread > will be a NOOP, but it suits us now to have it cause an error so > that ports that don't honor PTHREAD_LIBS can be found and fixed. IF this is a good idea (and I'm not convinced it is), I still have two major objections to it. First, this action was taken with very little (any?) discussion. Second, the timing is truly horrible, occurring during a ports freeze. If your goal is actually to find and fix broken ports, there are a LOT of other options, including enlisting volunteers, and using the package building cluster. I'd really like to see this change backed out, at minimum until the ports freeze is over. Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
In message: <[EMAIL PROTECTED]> Daniel Eischen <[EMAIL PROTECTED]> writes: : On Sat, 20 Sep 2003, M. Warner Losh wrote: : : > In message: <[EMAIL PROTECTED]> : > Harald Schmalzbauer <[EMAIL PROTECTED]> writes: : > : Not only the -pthread removement broke countless ports (some of them are : > : > Maybe I missed the reason why FreeBSD needs to be unique wrt threading : > programs and not have -pthread... : : Because -pthread allows selection of one specific threadling library, : not multiple. It is also unnecessary since the library is specified : as a link option, not a compiler option. In the future, -pthread : will be a NOOP, but it suits us now to have it cause an error so : that ports that don't honor PTHREAD_LIBS can be found and fixed. Why does -pthread necessarily force selection of one specific threading library? All it means is that it is that the program uses posix threads, at least traditionally. How FreeBSD causes that to happen is an interesting implementation detail for some, but irrelvant for most ports. Couldn't -pthread be made to give the user the default threading package, and for those that matter a more specific one can be specified? It is insane to have FreeBSD be different than all other systems for this trivial reason. Why fix everthing in the world when allowing -pthread to be a noop would solve the problem? Seems like we're being overly picky for no real gain. I guess I just don't understand. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
In message: <[EMAIL PROTECTED]> Doug Barton <[EMAIL PROTECTED]> writes: : I'd really like to see this change backed out, at minimum until the : ports freeze is over. Me too. I'd like to see a discussion of this in arch@ as well. I know that people have a low bikeshed tolerance these days, but this is a really big change and should be talked about first. We've retained much less widely used interfaces for compatibility for a year or two at times, yet -pthread was removed with little or no discussion. That doesn't seem right to me. It would be one thing if FreeBSD were the only os using it, but it appears that everybody else that supports threads uses it, and making FreeBSD the odd man out seems a little extreme unless there's some big gain that I've overlooked. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sun, 2003-09-21 at 04:09, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Doug Barton <[EMAIL PROTECTED]> writes: > : I'd really like to see this change backed out, at minimum until the > : ports freeze is over. My thoughts exactly. Sincerely, Dan Naumov -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sat, Sep 20, 2003 at 07:05:33PM -0600, M. Warner Losh wrote: > Why does -pthread necessarily force selection of one specific > threading library? All it means is that it is that the program uses > posix threads, at least traditionally. How FreeBSD causes that to > happen is an interesting implementation detail for some, but irrelvant > for most ports. Couldn't -pthread be made to give the user the > default threading package, and for those that matter a more specific > one can be specified? This subject *has* been discussed both within FreeBSD and with the GCC maintainers. I think that the consensus from those who chose to participate in that discussion was that -pthread would be a noop on FreeBSD. > It is insane to have FreeBSD be different than all other systems for > this trivial reason. Why fix everthing in the world when allowing > -pthread to be a noop would solve the problem? Seems like we're being > overly picky for no real gain. I guess I just don't understand. Having -pthread as a noop doesn't fix the ports breakage. For years ports have worked on the basis that libc_r was linked to get user-space threads *instead* of libc. This was the result of certain people in the FreeBSD developer community not wanting thread stubs in libc. Since libc was linked by default (unless -nostdlib was specified), it was necessary to have gcc know to use libc_r instead. That is why the -pthread argument was added. FWIW, Linux and the other BSDs didn't have a -pthread argument back then. Now that libc has thread stubs in libc (in current), there is no longer any need to have gcc know about any of the thread libraries. That's a good thing IMO. The FSF wants GCC to have a -pthread argument on all platforms and they are happy to have it as a noop. I doubt that there would ever be a good time to make this change. The fact that 4.9 has been delayed is making the problem seem worse because people can't commit fixes to the tree. While 4.9 is delayed (due to the PAE instability which never should have been allowed), the ports tree should be unlocked. The fixes are simple. Make them and move on. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
In message: <[EMAIL PROTECTED]> John Birrell <[EMAIL PROTECTED]> writes: : On Sat, Sep 20, 2003 at 07:05:33PM -0600, M. Warner Losh wrote: : > Why does -pthread necessarily force selection of one specific : > threading library? All it means is that it is that the program uses : > posix threads, at least traditionally. How FreeBSD causes that to : > happen is an interesting implementation detail for some, but irrelvant : > for most ports. Couldn't -pthread be made to give the user the : > default threading package, and for those that matter a more specific : > one can be specified? : : This subject *has* been discussed both within FreeBSD and with the GCC : maintainers. I think that the consensus from those who chose to participate : in that discussion was that -pthread would be a noop on FreeBSD. But it was completely removed. That sounds like the consensus wasn't followed. Why was it then removed? : > It is insane to have FreeBSD be different than all other systems for : > this trivial reason. Why fix everthing in the world when allowing : > -pthread to be a noop would solve the problem? Seems like we're being : > overly picky for no real gain. I guess I just don't understand. : : Having -pthread as a noop doesn't fix the ports breakage. For years ports : have worked on the basis that libc_r was linked to get user-space threads : *instead* of libc. This was the result of certain people in the FreeBSD : developer community not wanting thread stubs in libc. Since libc was : linked by default (unless -nostdlib was specified), it was necessary to : have gcc know to use libc_r instead. That is why the -pthread argument : was added. FWIW, Linux and the other BSDs didn't have a -pthread argument : back then. So we change -pthread to mean "link in the default threading package, with whatever magic is necessary for that package" rather than "link in libc_r instead of libc". : Now that libc has thread stubs in libc (in current), there is no longer : any need to have gcc know about any of the thread libraries. That's a : good thing IMO. The FSF wants GCC to have a -pthread argument on all : platforms and they are happy to have it as a noop. Then why was it completely removed? : I doubt that there would ever be a good time to make this change. The fact : that 4.9 has been delayed is making the problem seem worse because people : can't commit fixes to the tree. While 4.9 is delayed (due to the PAE : instability which never should have been allowed), the ports tree should : be unlocked. The fixes are simple. Make them and move on. At the very least, we should put it back as a noop. The timing on this really sucks because it breaks the ports tree for an extended period of time. While the fixes are simple, they haven't been made yet. The fact that the tree is frozen makes it seem like a really bad time to make the change. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote: > But it was completely removed. That sounds like the consensus wasn't > followed. Why was it then removed? It got discussed a bit more after the removal. That was the time when the GCC people got involved. The discussions where on FreeBSD public lists. > So we change -pthread to mean "link in the default threading package, > with whatever magic is necessary for that package" rather than "link > in libc_r instead of libc". A better way is to just link to the thread package you want. Keep knowledge of thread libraries outside GCC. There really is nothing simpler that adding -lc_r or -lpthread or -lmyownthreadlib. No magic required. > Then why was it completely removed? Dan removed it because it wasn't needed and nobody said anything otherwise. > At the very least, we should put it back as a noop. The timing on > this really sucks because it breaks the ports tree for an extended > period of time. While the fixes are simple, they haven't been made > yet. The fact that the tree is frozen makes it seem like a really bad > time to make the change. Yes, I think it should go back as a noop (mostly to satisfy the GCC people though). It sucks that the 4.9 pre-release instability has been so severe. It bit me so much I ended up using current instead. Major functionality changes to things like VM shouldn't be made so late in a branch. It is a point *NINE* release after all. Unfreeze the ports tree then! I'm not a ports committer, but I'm willing to help out fixing the problems on -current if that would help. Lets go forward, not back. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
In message: <[EMAIL PROTECTED]> John Birrell <[EMAIL PROTECTED]> writes: : On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote: : > But it was completely removed. That sounds like the consensus wasn't : > followed. Why was it then removed? : : It got discussed a bit more after the removal. That was the time when the : GCC people got involved. The discussions where on FreeBSD public lists. Yes. However, it is clear that the pain level wasn't adequately disclosed at the time of the removal. : > So we change -pthread to mean "link in the default threading package, : > with whatever magic is necessary for that package" rather than "link : > in libc_r instead of libc". : : A better way is to just link to the thread package you want. Keep knowledge : of thread libraries outside GCC. There really is nothing simpler that : adding -lc_r or -lpthread or -lmyownthreadlib. No magic required. Works for me. : > Then why was it completely removed? : : Dan removed it because it wasn't needed and nobody said anything otherwise. Time has proven the "not needed" part was premature. : > At the very least, we should put it back as a noop. The timing on : > this really sucks because it breaks the ports tree for an extended : > period of time. While the fixes are simple, they haven't been made : > yet. The fact that the tree is frozen makes it seem like a really bad : > time to make the change. : : Yes, I think it should go back as a noop (mostly to satisfy the GCC : people though). Sounds like we're in violent agreement. : It sucks that the 4.9 pre-release instability has been so severe. It bit : me so much I ended up using current instead. Major functionality changes : to things like VM shouldn't be made so late in a branch. It is a point : *NINE* release after all. The problem is that they put an experimental feature into the tree in a way that wasn't a noop for non-users of that feature. This was done because it would be more painful to make it a complete noop. I've said a few times that if PAE isn't ready for 4.9, it should be backed out and firmed up for 4.10, but re seems to think it is a must have feature in 4.9. FWIW, I'm running today's RELENG_4 w/o PAE. I'll see if there are big issues. : Unfreeze the ports tree then! I'm not a ports committer, but I'm willing : to help out fixing the problems on -current if that would help. Lets : go forward, not back. I'll let the portmgr folks comment on this. I think this is a good idea. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sat, 20 Sep 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Daniel Eischen <[EMAIL PROTECTED]> writes: > : On Sat, 20 Sep 2003, M. Warner Losh wrote: > : > : > In message: <[EMAIL PROTECTED]> > : > Harald Schmalzbauer <[EMAIL PROTECTED]> writes: > : > : Not only the -pthread removement broke countless ports (some of them are > : > > : > Maybe I missed the reason why FreeBSD needs to be unique wrt threading > : > programs and not have -pthread... > : > : Because -pthread allows selection of one specific threadling library, > : not multiple. It is also unnecessary since the library is specified > : as a link option, not a compiler option. In the future, -pthread > : will be a NOOP, but it suits us now to have it cause an error so > : that ports that don't honor PTHREAD_LIBS can be found and fixed. > > Why does -pthread necessarily force selection of one specific > threading library? All it means is that it is that the program uses > posix threads, at least traditionally. How FreeBSD causes that to > happen is an interesting implementation detail for some, but irrelvant > for most ports. Couldn't -pthread be made to give the user the > default threading package, and for those that matter a more specific > one can be specified? The default threading package when building in the ports system is PTHREAD_LIBS. You can't make -pthread select that. PTHREAD_LIBS can be overridden in /etc/make.conf or the environment. If you want to argue between which you'd prefer, PTHREAD_LIBS or -pthread, that's fine, but PTHREAD_LIBS is what we currently have and what I'm going by. > It is insane to have FreeBSD be different than all other systems for > this trivial reason. Why fix everthing in the world when allowing > -pthread to be a noop would solve the problem? Seems like we're being > overly picky for no real gain. I guess I just don't understand. Allowing -pthread to be a noop doesn't necessarily solve the problem right now. Ports check for -pthread and use it without also using PTHREAD_LIBS, so they would still be broke. Ports that are libraries that use -pthread won't break when -pthread is NOOP'd, but non-threaded applications that use those libraries may fail to link. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sat, 20 Sep 2003, Doug Barton wrote: > On Sat, 20 Sep 2003, Daniel Eischen wrote: > > > On Sat, 20 Sep 2003, M. Warner Losh wrote: > > > > > In message: <[EMAIL PROTECTED]> > > > Harald Schmalzbauer <[EMAIL PROTECTED]> writes: > > > : Not only the -pthread removement broke countless ports (some of them are > > > > > > Maybe I missed the reason why FreeBSD needs to be unique wrt threading > > > programs and not have -pthread... > > > > Because -pthread allows selection of one specific threadling library, > > not multiple. It is also unnecessary since the library is specified > > as a link option, not a compiler option. In the future, -pthread > > will be a NOOP, but it suits us now to have it cause an error so > > that ports that don't honor PTHREAD_LIBS can be found and fixed. > > IF this is a good idea (and I'm not convinced it is), I still have two > major objections to it. First, this action was taken with very little > (any?) discussion. Second, the timing is truly horrible, occurring > during a ports freeze. This is the longest ports freeze that I can remember. I wasn't expecting it to last long. Not to change the subject, I thought it would just be long enough to lay the tag. I don't think you should label it as bad timing as much as asking why the freeze is taking so long. > If your goal is actually to find and fix broken ports, there are a LOT > of other options, including enlisting volunteers, and using the package > building cluster. > > I'd really like to see this change backed out, at minimum until the > ports freeze is over. I'd like to see some barking up the other tree. Why should fixes to unbreak ports be held up by the freeze? -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sun, 21 Sep 2003, John Birrell wrote: > On Sat, Sep 20, 2003 at 07:05:33PM -0600, M. Warner Losh wrote: > > Why does -pthread necessarily force selection of one specific > > threading library? All it means is that it is that the program uses > > posix threads, at least traditionally. How FreeBSD causes that to > > happen is an interesting implementation detail for some, but irrelvant > > for most ports. Couldn't -pthread be made to give the user the > > default threading package, and for those that matter a more specific > > one can be specified? > > This subject *has* been discussed both within FreeBSD and with the GCC > maintainers. I think that the consensus from those who chose to participate > in that discussion was that -pthread would be a noop on FreeBSD. > > > It is insane to have FreeBSD be different than all other systems for > > this trivial reason. Why fix everthing in the world when allowing > > -pthread to be a noop would solve the problem? Seems like we're being > > overly picky for no real gain. I guess I just don't understand. > > Having -pthread as a noop doesn't fix the ports breakage. For years ports > have worked on the basis that libc_r was linked to get user-space threads > *instead* of libc. This was the result of certain people in the FreeBSD > developer community not wanting thread stubs in libc. Since libc was > linked by default (unless -nostdlib was specified), it was necessary to > have gcc know to use libc_r instead. That is why the -pthread argument > was added. FWIW, Linux and the other BSDs didn't have a -pthread argument > back then. > > Now that libc has thread stubs in libc (in current), there is no longer > any need to have gcc know about any of the thread libraries. That's a > good thing IMO. The FSF wants GCC to have a -pthread argument on all > platforms and they are happy to have it as a noop. > > I doubt that there would ever be a good time to make this change. The fact > that 4.9 has been delayed is making the problem seem worse because people > can't commit fixes to the tree. While 4.9 is delayed (due to the PAE > instability which never should have been allowed), the ports tree should > be unlocked. The fixes are simple. Make them and move on. I couldn't agree more :-) There should be no reason not to commit fixes to unbreak a port. 5.2-RELEASE has to happen relatively soon also. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
In message: <[EMAIL PROTECTED]> Daniel Eischen <[EMAIL PROTECTED]> writes: : I'd like to see some barking up the other tree. Why should fixes : to unbreak ports be held up by the freeze? Because the ports folks do not want random changes going into the tree right now given that they have enough build problems on 4.9 related to GNOME. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sat, 20 Sep 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > John Birrell <[EMAIL PROTECTED]> writes: > : On Sat, Sep 20, 2003 at 07:05:33PM -0600, M. Warner Losh wrote: > : > Why does -pthread necessarily force selection of one specific > : > threading library? All it means is that it is that the program uses > : > posix threads, at least traditionally. How FreeBSD causes that to > : > happen is an interesting implementation detail for some, but irrelvant > : > for most ports. Couldn't -pthread be made to give the user the > : > default threading package, and for those that matter a more specific > : > one can be specified? > : > : This subject *has* been discussed both within FreeBSD and with the GCC > : maintainers. I think that the consensus from those who chose to participate > : in that discussion was that -pthread would be a noop on FreeBSD. > > But it was completely removed. That sounds like the consensus wasn't > followed. Why was it then removed? Consensus occured after further conversation with our FSF GCC maintainer. It doesn't matter now whether it is removed or NOOP'd; ports still break, but not as obviously. > : > It is insane to have FreeBSD be different than all other systems for > : > this trivial reason. Why fix everthing in the world when allowing > : > -pthread to be a noop would solve the problem? Seems like we're being > : > overly picky for no real gain. I guess I just don't understand. > : > : Having -pthread as a noop doesn't fix the ports breakage. For years ports > : have worked on the basis that libc_r was linked to get user-space threads > : *instead* of libc. This was the result of certain people in the FreeBSD > : developer community not wanting thread stubs in libc. Since libc was > : linked by default (unless -nostdlib was specified), it was necessary to > : have gcc know to use libc_r instead. That is why the -pthread argument > : was added. FWIW, Linux and the other BSDs didn't have a -pthread argument > : back then. > > So we change -pthread to mean "link in the default threading package, > with whatever magic is necessary for that package" rather than "link > in libc_r instead of libc". There is no default threading package. That's what PTHREAD_LIBS is suppose to do. If we assigned -pthread to one particular threading package, there would be no way to have a different one selected, except perhaps globally with /etc/libmap.conf. PTHREAD_LIBS allows the port builder to override (via /etc/make.conf) the default threading library with whatever they want. You can't do that with -pthread. > : Now that libc has thread stubs in libc (in current), there is no longer > : any need to have gcc know about any of the thread libraries. That's a > : good thing IMO. The FSF wants GCC to have a -pthread argument on all > : platforms and they are happy to have it as a noop. > > Then why was it completely removed? It doesn't matter; NOOP == removed. > : I doubt that there would ever be a good time to make this change. The fact > : that 4.9 has been delayed is making the problem seem worse because people > : can't commit fixes to the tree. While 4.9 is delayed (due to the PAE > : instability which never should have been allowed), the ports tree should > : be unlocked. The fixes are simple. Make them and move on. > > At the very least, we should put it back as a noop. The timing on > this really sucks because it breaks the ports tree for an extended > period of time. While the fixes are simple, they haven't been made > yet. The fact that the tree is frozen makes it seem like a really bad > time to make the change. Again, whether it is a NOOP or removed, the same ports still break. It is possible that even more ports could break if it is NOOP'd; autoconf/configure can detect that -pthread is a valid switch if it doesn't emit an error. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sat, 20 Sep 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > John Birrell <[EMAIL PROTECTED]> writes: > : On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote: > : > But it was completely removed. That sounds like the consensus wasn't > : > followed. Why was it then removed? > : > : It got discussed a bit more after the removal. That was the time when the > : GCC people got involved. The discussions where on FreeBSD public lists. > > Yes. However, it is clear that the pain level wasn't adequately > disclosed at the time of the removal. > > : > So we change -pthread to mean "link in the default threading package, > : > with whatever magic is necessary for that package" rather than "link > : > in libc_r instead of libc". > : > : A better way is to just link to the thread package you want. Keep knowledge > : of thread libraries outside GCC. There really is nothing simpler that > : adding -lc_r or -lpthread or -lmyownthreadlib. No magic required. > > Works for me. > > : > Then why was it completely removed? > : > : Dan removed it because it wasn't needed and nobody said anything otherwise. > > Time has proven the "not needed" part was premature. > > : > At the very least, we should put it back as a noop. The timing on > : > this really sucks because it breaks the ports tree for an extended > : > period of time. While the fixes are simple, they haven't been made > : > yet. The fact that the tree is frozen makes it seem like a really bad > : > time to make the change. > : > : Yes, I think it should go back as a noop (mostly to satisfy the GCC > : people though). > > Sounds like we're in violent agreement. But you seem to thing -pthread == NOOP unbreaks ports ;-) -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sun, Sep 21, 2003 at 01:07:15AM -0400, Daniel Eischen wrote: > But you seem to thing -pthread == NOOP unbreaks ports ;-) Warner might, but Kris doesn't. Kris is asking for the -pthread option to be restored to let -current users breath easy while the task of updating the ports goes on. Then he's happy for it to become a noop. I susect theat this puts much of the work on a few people rather than many. I hope it doesn't require a volley of emails to each port maintainer to resolve each one. People have jumped off buildings for less than that! -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sat, 20 Sep 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Daniel Eischen <[EMAIL PROTECTED]> writes: > : I'd like to see some barking up the other tree. Why should fixes > : to unbreak ports be held up by the freeze? > > Because the ports folks do not want random changes going into the tree > right now given that they have enough build problems on 4.9 related to > GNOME. Oddly enough, the GNOME ports are supposedly pretty much PTHREAD_LIBS compliant. It's really the KDE ports that have the brunt of the problems. Oh, yeah, and they just updated QT and KDE to the latest releases. I suppose that's OK, but committing fixes to unbreak them on -current isn't. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sun, Sep 21, 2003 at 12:46:30AM -0400, Daniel Eischen wrote: > This is the longest ports freeze that I can remember I can only suppose that you haven't been paying attention to other release cycles, because this one is shorter than usual. > I wasn't > expecting it to last long. Not to change the subject, I thought > it would just be long enough to lay the tag. I don't think you > should label it as bad timing as much as asking why the freeze is > taking so long. The release schedule has been on the website for over a month, so again it looks like you were simply uniformed as to timing and duration of the release events. Daniel, I'm trying to be reasonable here, and I think my previous proposal achieves the ends we all want with a minimum of disruption to the various parties involved. Unfortunately I'm seeing a lot of heat from you and not a lot of discussion. Can we please try and work cooperatively? Kris pgp0.pgp Description: PGP signature
Re: ports and -current
On Sun, Sep 21, 2003 at 03:15:25PM +1000, John Birrell wrote: > On Sun, Sep 21, 2003 at 01:07:15AM -0400, Daniel Eischen wrote: > > But you seem to thing -pthread == NOOP unbreaks ports ;-) > > Warner might, but Kris doesn't. Kris is asking for the -pthread option > to be restored to let -current users breath easy while the task of updating > the ports goes on. Then he's happy for it to become a noop. > > I susect theat this puts much of the work on a few people rather than many. > I hope it doesn't require a volley of emails to each port maintainer to > resolve each one. People have jumped off buildings for less than that! I expect it's about a dozen man-hours of work, or so, if there's a group of people working on the problem. If left to the individual maintainers to solve, it will take a lot longer in wall clock time, and we'll probably end up with a bunch of incorrect fixes. It should be no trouble at all to find volunteer port committers to help with the task. Kris pgp0.pgp Description: PGP signature
Re: ports and -current
In message: <[EMAIL PROTECTED]> John Birrell <[EMAIL PROTECTED]> writes: : On Sun, Sep 21, 2003 at 01:07:15AM -0400, Daniel Eischen wrote: : > But you seem to thing -pthread == NOOP unbreaks ports ;-) : : Warner might It appreas to unbreak one port: icecast. It was the first port I found so I assumed many ports were that way, but I couldn't find any others having gone and looked at the breakage right now. : but Kris doesn't. Kris is asking for the -pthread option : to be restored to let -current users breath easy while the task of updating : the ports goes on. Then he's happy for it to become a noop. I'd be cool with this. I don't think the 'unfreeze the ports' option is a viable one, which leaves us with this. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
John Birrell wrote: On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote: At the very least, we should put [-pthread] back as a noop. The timing on this really sucks because it breaks the ports tree for an extended period of time. While the fixes are simple, they haven't been made yet. The fact that the tree is frozen makes it seem like a really bad time to make the change. Yes, I think it should go back as a noop (mostly to satisfy the GCC people though). Perhaps put it back as a noop with a particularly loud warning: "Warning: -pthread does nothing. If this is a port, complain to the maintainer to fix it." Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
In message: <[EMAIL PROTECTED]> Tim Kientzle <[EMAIL PROTECTED]> writes: : John Birrell wrote: : > On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote: : >>At the very least, we should put [-pthread] back as a noop. The timing on : >>this really sucks because it breaks the ports tree for an extended : >>period of time. While the fixes are simple, they haven't been made : >>yet. The fact that the tree is frozen makes it seem like a really bad : >>time to make the change. : > : > : > Yes, I think it should go back as a noop (mostly to satisfy the GCC : > people though). : : Perhaps put it back as a noop with a particularly : loud warning: : : "Warning: -pthread does nothing. If this is a port, complain to the : maintainer to fix it." Maybe we should just stick to the plan that Kris and Daniel worked out? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fixing -pthreads (Re: ports and -current)
On Sat, Sep 20, 2003 at 08:43:18PM -0400, Daniel Eischen wrote: > On Sat, 20 Sep 2003, M. Warner Losh wrote: > > > In message: <[EMAIL PROTECTED]> > > Harald Schmalzbauer <[EMAIL PROTECTED]> writes: > > : Not only the -pthread removement broke countless ports (some of them are > > > > Maybe I missed the reason why FreeBSD needs to be unique wrt threading > > programs and not have -pthread... > > Because -pthread allows selection of one specific threadling library, > not multiple. It is also unnecessary since the library is specified > as a link option, not a compiler option. In the future, -pthread > will be a NOOP, but it suits us now to have it cause an error so > that ports that don't honor PTHREAD_LIBS can be found and fixed. OK, here's what we can do to fix this: 1) Put back -pthread in -current so all the ports don't fail 2) I will build a full set of -current packages with the -pthread error still in place, to determine the list of packages that need to be fixed (in fact I already have this, see http://dosirak.kr.freebsd.org/errorlogs). 3) You, John Birrell, and whoever else is interested in fixing these ports can work on them at your own pace without disrupting life for the rest of the users. Once they're all fixed, we can turn the error back on or make it a NOP or do whatever else is decided to be appropriate. 4) It is likely that steps 2 and 3 will need to be iterated several times, because there are dozens of ports that need to be fixed, and many of them are hiding other ports that depend on them and also need to be fixed. Kris pgp0.pgp Description: PGP signature
Re: ports and -current (really 4.9 stability)
M. Warner Losh wrote: > FWIW, I'm running today's RELENG_4 w/o PAE. I'll see if there are big > issues. FYI, I've been running 4.9-prerelease since last week, all without PAE. Booted it on all my boxen (including a web server and a database server) as well as doing hardware reconfigurations and testing a device driver. All _without_ PAE, which I won't touch until it has shaken out a bit. Everything has been rock-solid, no problems at all. Were it not for PAE, I would say to go ahead and release it. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote: > 3) You, John Birrell, and whoever else is interested in fixing these > ports can work on them at your own pace without disrupting life for > the rest of the users. Once they're all fixed, we can turn the error > back on or make it a NOP or do whatever else is decided to be > appropriate. OK, so what's the commit procedure going to be? This could generate an awful lot of little PRs. Scot posted a patch for bsd.port.mk. Is that going to be committed? That's needed. Are you prepared to unlock the ports tree and allow a blanket commit auth for commits that only change patch-configure? That should catch most of the simple cases. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, Sep 21, 2003 at 02:03:40PM +1000, John Birrell wrote: > On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote: > > 3) You, John Birrell, and whoever else is interested in fixing these > > ports can work on them at your own pace without disrupting life for > > the rest of the users. Once they're all fixed, we can turn the error > > back on or make it a NOP or do whatever else is decided to be > > appropriate. > > OK, so what's the commit procedure going to be? This could generate an > awful lot of little PRs. Call for volunteers, take the list of failed ports from dosirak and divide it up between yourselves, then mark off the ports as fixes are developed. The fixes can be committed once the freeze is over (and they are demonstrated not to break on 4.x). There's no reason this needs to be coordinated through GNATS, and indeed that would probably be counter-productive. Since it won't be affecting people outside the testing group who continue to run a gcc that treats -pthread as an error, duplicate or bogus PRs won't be generated by people who aren't in the loop. > Scot posted a patch for bsd.port.mk. Is that going to be committed? > That's needed. Sure, if it works. I can test it once the current 5.x build finishes on dosirak. > Are you prepared to unlock the ports tree and allow a blanket commit auth > for commits that only change patch-configure? That should catch most of > the simple cases. I'm unsure of the current status - the original schedule called for the ports tree to be tagged yesterday, but now the schedule has slipped. marcus is in charge of this release, so he'll have to comment on the updated timeline. However, we need to be careful not to destabilize 4.9 in committing hasty and poorly-tested fixes for problems on -current that do not also work on 4.x (this is unfortunately a common occurrence). At any rate, 4.9 will be released sooner or later, and in following step 1) of my proposal the only people the freeze will continue to affect are those who are working on fixing the -pthread issues, which can be kept in private repositories for a week or two. For everyone else, ports that use -pthread will go back to working again (modulo pre-existing compile failures). Kris pgp0.pgp Description: PGP signature
Re: Fixing -pthreads (Re: ports and -current)
On Sun, 2003-09-21 at 00:22, Kris Kennaway wrote: > On Sun, Sep 21, 2003 at 02:03:40PM +1000, John Birrell wrote: > > On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote: > > > 3) You, John Birrell, and whoever else is interested in fixing these > > > ports can work on them at your own pace without disrupting life for > > > the rest of the users. Once they're all fixed, we can turn the error > > > back on or make it a NOP or do whatever else is decided to be > > > appropriate. > > > > OK, so what's the commit procedure going to be? This could generate an > > awful lot of little PRs. > > Call for volunteers, take the list of failed ports from dosirak and > divide it up between yourselves, then mark off the ports as fixes are > developed. The fixes can be committed once the freeze is over (and > they are demonstrated not to break on 4.x). > > There's no reason this needs to be coordinated through GNATS, and > indeed that would probably be counter-productive. Since it won't be > affecting people outside the testing group who continue to run a gcc > that treats -pthread as an error, duplicate or bogus PRs won't be > generated by people who aren't in the loop. > > > Scot posted a patch for bsd.port.mk. Is that going to be committed? > > That's needed. > > Sure, if it works. I can test it once the current 5.x build finishes > on dosirak. > > > Are you prepared to unlock the ports tree and allow a blanket commit auth > > for commits that only change patch-configure? That should catch most of > > the simple cases. > > I'm unsure of the current status - the original schedule called for > the ports tree to be tagged yesterday, but now the schedule has > slipped. marcus is in charge of this release, so he'll have to > comment on the updated timeline. However, we need to be careful not > to destabilize 4.9 in committing hasty and poorly-tested fixes for > problems on -current that do not also work on 4.x (this is > unfortunately a common occurrence). I will most likely be tagging the tree sometime this week once things have stabilized with the recent GNOME and KDE commits. I do not want to start having -pthread commits go in at this time as they do not help the -STABLE build process. Joe > > At any rate, 4.9 will be released sooner or later, and in following > step 1) of my proposal the only people the freeze will continue to > affect are those who are working on fixing the -pthread issues, which > can be kept in private repositories for a week or two. For everyone > else, ports that use -pthread will go back to working again (modulo > pre-existing compile failures). > > Kris -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: Fixing -pthreads (Re: ports and -current)
On Sat, 20 Sep 2003, Kris Kennaway wrote: > On Sat, Sep 20, 2003 at 08:43:18PM -0400, Daniel Eischen wrote: > > On Sat, 20 Sep 2003, M. Warner Losh wrote: > > > > > In message: <[EMAIL PROTECTED]> > > > Harald Schmalzbauer <[EMAIL PROTECTED]> writes: > > > : Not only the -pthread removement broke countless ports (some of them are > > > > > > Maybe I missed the reason why FreeBSD needs to be unique wrt threading > > > programs and not have -pthread... > > > > Because -pthread allows selection of one specific threadling library, > > not multiple. It is also unnecessary since the library is specified > > as a link option, not a compiler option. In the future, -pthread > > will be a NOOP, but it suits us now to have it cause an error so > > that ports that don't honor PTHREAD_LIBS can be found and fixed. > > OK, here's what we can do to fix this: > > 1) Put back -pthread in -current so all the ports don't fail > > 2) I will build a full set of -current packages with the -pthread > error still in place, to determine the list of packages that need to > be fixed (in fact I already have this, see > http://dosirak.kr.freebsd.org/errorlogs). > > 3) You, John Birrell, and whoever else is interested in fixing these > ports can work on them at your own pace without disrupting life for > the rest of the users. Once they're all fixed, we can turn the error > back on or make it a NOP or do whatever else is decided to be > appropriate. > > 4) It is likely that steps 2 and 3 will need to be iterated several > times, because there are dozens of ports that need to be fixed, and > many of them are hiding other ports that depend on them and also need > to be fixed. Just unfreeze the ports tree and allow broken ports to be fixed. Problem solved. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sat, 20 Sep 2003, Kris Kennaway wrote: > On Sun, Sep 21, 2003 at 02:03:40PM +1000, John Birrell wrote: > > On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote: > > > 3) You, John Birrell, and whoever else is interested in fixing these > > > ports can work on them at your own pace without disrupting life for > > > the rest of the users. Once they're all fixed, we can turn the error > > > back on or make it a NOP or do whatever else is decided to be > > > appropriate. > > > > OK, so what's the commit procedure going to be? This could generate an > > awful lot of little PRs. > > Call for volunteers, take the list of failed ports from dosirak and > divide it up between yourselves, then mark off the ports as fixes are > developed. The fixes can be committed once the freeze is over (and > they are demonstrated not to break on 4.x). > > There's no reason this needs to be coordinated through GNATS, and > indeed that would probably be counter-productive. Since it won't be > affecting people outside the testing group who continue to run a gcc > that treats -pthread as an error, duplicate or bogus PRs won't be > generated by people who aren't in the loop. > > > Scot posted a patch for bsd.port.mk. Is that going to be committed? > > That's needed. > > Sure, if it works. I can test it once the current 5.x build finishes > on dosirak. > > > Are you prepared to unlock the ports tree and allow a blanket commit auth > > for commits that only change patch-configure? That should catch most of > > the simple cases. > > I'm unsure of the current status - the original schedule called for > the ports tree to be tagged yesterday, but now the schedule has > slipped. marcus is in charge of this release, so he'll have to > comment on the updated timeline. However, we need to be careful not > to destabilize 4.9 in committing hasty and poorly-tested fixes for > problems on -current that do not also work on 4.x (this is > unfortunately a common occurrence). > > At any rate, 4.9 will be released sooner or later, and in following > step 1) of my proposal the only people the freeze will continue to > affect are those who are working on fixing the -pthread issues, which > can be kept in private repositories for a week or two. For everyone > else, ports that use -pthread will go back to working again (modulo > pre-existing compile failures). Because -pthread has broken ports, fixes are already being and have been developed. Just unfreeze the tree or give permission to commit -current breakage fixes (with the caveat they are compile tested on -stable). -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, Sep 21, 2003 at 01:04:49AM -0400, Daniel Eischen wrote: > On Sat, 20 Sep 2003, Kris Kennaway wrote: > > > On Sat, Sep 20, 2003 at 08:43:18PM -0400, Daniel Eischen wrote: > > > On Sat, 20 Sep 2003, M. Warner Losh wrote: > > > > > > > In message: <[EMAIL PROTECTED]> > > > > Harald Schmalzbauer <[EMAIL PROTECTED]> writes: > > > > : Not only the -pthread removement broke countless ports (some of them are > > > > > > > > Maybe I missed the reason why FreeBSD needs to be unique wrt threading > > > > programs and not have -pthread... > > > > > > Because -pthread allows selection of one specific threadling library, > > > not multiple. It is also unnecessary since the library is specified > > > as a link option, not a compiler option. In the future, -pthread > > > will be a NOOP, but it suits us now to have it cause an error so > > > that ports that don't honor PTHREAD_LIBS can be found and fixed. > > > > OK, here's what we can do to fix this: > > > > 1) Put back -pthread in -current so all the ports don't fail > > > > 2) I will build a full set of -current packages with the -pthread > > error still in place, to determine the list of packages that need to > > be fixed (in fact I already have this, see > > http://dosirak.kr.freebsd.org/errorlogs). > > > > 3) You, John Birrell, and whoever else is interested in fixing these > > ports can work on them at your own pace without disrupting life for > > the rest of the users. Once they're all fixed, we can turn the error > > back on or make it a NOP or do whatever else is decided to be > > appropriate. > > > > 4) It is likely that steps 2 and 3 will need to be iterated several > > times, because there are dozens of ports that need to be fixed, and > > many of them are hiding other ports that depend on them and also need > > to be fixed. > > Just unfreeze the ports tree and allow broken ports to be > fixed. Problem solved. Daniel, this is most unhelpful. We're a week or two way from releasing 4.9-RELEASE, and unfreezing now would lead to guaranteed problems for the release (recall the point of having ports freezes in the first place). What, precisely, do you object to in the above proposal? Kris pgp0.pgp Description: PGP signature
Re: Fixing -pthreads (Re: ports and -current)
On Sat, 20 Sep 2003, Kris Kennaway wrote: > On Sun, Sep 21, 2003 at 01:04:49AM -0400, Daniel Eischen wrote: > > On Sat, 20 Sep 2003, Kris Kennaway wrote: > > > > > On Sat, Sep 20, 2003 at 08:43:18PM -0400, Daniel Eischen wrote: > > > > On Sat, 20 Sep 2003, M. Warner Losh wrote: > > > > > > > > > In message: <[EMAIL PROTECTED]> > > > > > Harald Schmalzbauer <[EMAIL PROTECTED]> writes: > > > > > : Not only the -pthread removement broke countless ports (some of them are > > > > > > > > > > Maybe I missed the reason why FreeBSD needs to be unique wrt threading > > > > > programs and not have -pthread... > > > > > > > > Because -pthread allows selection of one specific threadling library, > > > > not multiple. It is also unnecessary since the library is specified > > > > as a link option, not a compiler option. In the future, -pthread > > > > will be a NOOP, but it suits us now to have it cause an error so > > > > that ports that don't honor PTHREAD_LIBS can be found and fixed. > > > > > > OK, here's what we can do to fix this: > > > > > > 1) Put back -pthread in -current so all the ports don't fail > > > > > > 2) I will build a full set of -current packages with the -pthread > > > error still in place, to determine the list of packages that need to > > > be fixed (in fact I already have this, see > > > http://dosirak.kr.freebsd.org/errorlogs). > > > > > > 3) You, John Birrell, and whoever else is interested in fixing these > > > ports can work on them at your own pace without disrupting life for > > > the rest of the users. Once they're all fixed, we can turn the error > > > back on or make it a NOP or do whatever else is decided to be > > > appropriate. > > > > > > 4) It is likely that steps 2 and 3 will need to be iterated several > > > times, because there are dozens of ports that need to be fixed, and > > > many of them are hiding other ports that depend on them and also need > > > to be fixed. > > > > Just unfreeze the ports tree and allow broken ports to be > > fixed. Problem solved. > > Daniel, this is most unhelpful. We're a week or two way from > releasing 4.9-RELEASE, and unfreezing now would lead to guaranteed > problems for the release (recall the point of having ports freezes in > the first place). I don't think committing fixes for -current breakages should cause problems for 4.9-RELEASE (especially with the caveat that they be compile tested on -stable). Out of curiosity, what's the reason the tag can't be laid now? In a better world, freezing -stable shouldn't hinder -current. > What, precisely, do you object to in the above proposal? 1, 2, and 3. I don't think backing out -pthread change helps much in fixing ports... -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote: > I don't think committing fixes for -current breakages should cause > problems for 4.9-RELEASE (especially with the caveat that they be > compile tested on -stable). Out of curiosity, what's the reason > the tag can't be laid now? In a better world, freezing -stable > shouldn't hinder -current. There are other fixes that are still being committed. It was a release engineering decision to upgrade kde and gnome for 4.9-R, and there are still bugs being shaken out as a result. Since you (and others who have expressed similar puzzlement about the need for ports freezes) are not involved in the actual mechanics of FreeBSD release engineering, please just try to accept that there are technical challenges in making sure that things don't go wrong at the last minute, and the way we try to make sure the release doesn't get botched up by a poorly-considered change at the 11th hour is by enforcing a period of quietude on the tree so that there's a reasonable chance that any problems will be detected before the release instead of after. This is the reality of it, and wishing that things were different just isn't productive right now. > > What, precisely, do you object to in the above proposal? > > 1, 2, and 3. I don't think backing out -pthread change helps > much in fixing ports... Again, why? Please explain instead of asserting, because that's getting us nowhere towards resolving this. Kris pgp0.pgp Description: PGP signature
Re: Fixing -pthreads (Re: ports and -current)
On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote: > OK, here's what we can do to fix this: > > 1) Put back -pthread in -current so all the ports don't fail > > 2) I will build a full set of -current packages with the -pthread > error still in place, to determine the list of packages that need to > be fixed (in fact I already have this, see > http://dosirak.kr.freebsd.org/errorlogs). > > 3) You, John Birrell, and whoever else is interested in fixing these > ports can work on them at your own pace without disrupting life for > the rest of the users. Once they're all fixed, we can turn the error > back on or make it a NOP or do whatever else is decided to be > appropriate. > > 4) It is likely that steps 2 and 3 will need to be iterated several > times, because there are dozens of ports that need to be fixed, and > many of them are hiding other ports that depend on them and also need > to be fixed. I don't know if there is much point to #1 at this point since it's been gone for about 2 weeks now. #2/3/4 sounds fine to me. In the meantime KF is working on a patch to properly support PTHREAD_LIBS in KDE's configure scripts. We plan to commit it when the freeze lifts, pending PR #55325. I suggest that people not build ports on -CURRENT for a few weeks until things get sorted out, unless they're going to fix the problems with specific ports. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sat, 20 Sep 2003, Kris Kennaway wrote: > On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote: > > > What, precisely, do you object to in the above proposal? > > > > 1, 2, and 3. I don't think backing out -pthread change helps > > much in fixing ports... > > Again, why? Please explain instead of asserting, because that's > getting us nowhere towards resolving this. Because when things break, people fix them. There is no motivation (as seen in the last 2+ years) to fix something that isn't broken. Please also see: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports my posting to ports@ in May of this year. When the GCC-3.3 import broke a lot of ports, did you ask for it to be backed out so that ports could first be fixed? Yeah, OK, we're in a ports freeze, so that's different now. But once the freeze is lifted, I don't see a need to keep -pthread in (assuming it was added back for the freeze). -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, Sep 21, 2003 at 02:12:55AM -0400, Daniel Eischen wrote: > Because when things break, people fix them. There is no > motivation (as seen in the last 2+ years) to fix something > that isn't broken. > > Please also see: > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports > > my posting to ports@ in May of this year. I wish you'd pushed the issue a bit more aggressively. Sometimes people don't pay close enough attention, and I am definitely one of those people. My apologies for missing that message. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, Sep 21, 2003 at 02:12:55AM -0400, Daniel Eischen wrote: > On Sat, 20 Sep 2003, Kris Kennaway wrote: > > > On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote: > > > > What, precisely, do you object to in the above proposal? > > > > > > 1, 2, and 3. I don't think backing out -pthread change helps > > > much in fixing ports... > > > > Again, why? Please explain instead of asserting, because that's > > getting us nowhere towards resolving this. > > Because when things break, people fix them. There is no > motivation (as seen in the last 2+ years) to fix something > that isn't broken. What's the real issue here? It seems like you're suggesting that it's not your responsibility to help fix the broken ports, and that other people should do the work instead. > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports > > my posting to ports@ in May of this year. That change doesn't seem to have happened, or to be the same thing we're discussing here. Anyway, if you'd been interested in pre-empting problems with the -pthread change you could have asked me to do a package build with the change in place to test the waters, and then worked with me and others to minimize the impact at the time when the commit went in. I routinely do this with other committers (including the gcc imports), and I'm happy to continue doing so. However, the strategy of just dumping a change into the tree and then leaving it to others to clean up the mess is not a good one - it's disruptive to the development cycle, it causes developers to get bogged down in arguments like we find ourselves having now, and the bottom line is that it's just not very polite to the people that your change affects. > When the GCC-3.3 import broke a lot of ports, did you ask for it to > be backed out so that ports could first be fixed? No, kan and I worked together before the change went in to evaluate the impact on packages, then I coordinated a group of volunteers to help fix the resulting fallout. I'm trying to do the same thing now. Are you willing to be part of the solution to this problem? Kris pgp0.pgp Description: PGP signature
Re: Fixing -pthreads (Re: ports and -current)
On Sat, 20 Sep 2003, Kris Kennaway wrote: > On Sun, Sep 21, 2003 at 02:12:55AM -0400, Daniel Eischen wrote: > > On Sat, 20 Sep 2003, Kris Kennaway wrote: > > > > > On Sun, Sep 21, 2003 at 01:44:35AM -0400, Daniel Eischen wrote: > > > > > What, precisely, do you object to in the above proposal? > > > > > > > > 1, 2, and 3. I don't think backing out -pthread change helps > > > > much in fixing ports... > > > > > > Again, why? Please explain instead of asserting, because that's > > > getting us nowhere towards resolving this. > > > > Because when things break, people fix them. There is no > > motivation (as seen in the last 2+ years) to fix something > > that isn't broken. > > What's the real issue here? It seems like you're suggesting that it's > not your responsibility to help fix the broken ports, and that other > people should do the work instead. Well, sorta yes. I don't have the time to fix broken ports but I can help guide others. I have other things on my plate. I do have one of my own ports to fix though. > > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=321307+0+archive/2003/freebsd-ports/20030601.freebsd-ports > > > > my posting to ports@ in May of this year. > > That change doesn't seem to have happened, or to be the same thing > we're discussing here. Anyway, if you'd been interested in > pre-empting problems with the -pthread change you could have asked me > to do a package build with the change in place to test the waters, and > then worked with me and others to minimize the impact at the time when > the commit went in. I routinely do this with other committers > (including the gcc imports), and I'm happy to continue doing so. Well, actually it is directly related. Part of the plan to transition to libpthread is making ports PTHREAD_LIBS compliant. As stated in that thread, if a libpthread exists on the system, autoconf/configure will pick it up and the port will also end up using -pthread and/or PTHREAD_LIBS. If PTHREAD_LIBS is set to libthr or libc_r (something other than libpthread), then the port ends up linking to both libraries. This doesn't work but you don't know it until your run the application and very weird things happen. Causing a clean breakage is better because you know at compile-time that something is wrong. So ports need to first be PTHREAD_LIBS compliant before we make the switch. Soon after ports are fixed, we can rename it. I think doing a build of all the ports is a good idea. I guess you've already done that if I recall an earlier email correctly. I also think most of the problems are already known, and if you give it a few days after the freeze things should look a lot better. Actually, to look ahead a bit... After ports are fixed, it still might be a good idea to do another package build, but this time with libkse installed as libpthread and PTHREAD_LIBS set to libc_r (or something that is not libpthread). Is there an easy way to do an 'ldd' of the resulting binaries to make sure libpthread isn't referenced? Feel free to take this offline if you want... > However, the strategy of just dumping a change into the tree and then > leaving it to others to clean up the mess is not a good one - it's > disruptive to the development cycle, it causes developers to get > bogged down in arguments like we find ourselves having now, and the > bottom line is that it's just not very polite to the people that your > change affects. As Will mentioned, I think the changes are mostly done. I don't think I just 'dumped' the changes into the tree. It has been over 2 years since, yada yada yada, and the ports system should have been using PTHREAD_LIBS since then. I don't want to argue with you; I respect you and everyone else here and God knows you guys contribute an awful lot. > > When the GCC-3.3 import broke a lot of ports, did you ask for it to > > be backed out so that ports could first be fixed? > > No, kan and I worked together before the change went in to evaluate > the impact on packages, then I coordinated a group of volunteers to > help fix the resulting fallout. I'm trying to do the same thing now. > Are you willing to be part of the solution to this problem? >From what I've recently read, the freeze should be lifting this week. Can we hold off till then? Is a few more days going to matter? If the freeze continues longer than expected, I'll back the change out until it's over. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, Sep 21, 2003 at 03:17:28AM -0400, Daniel Eischen wrote: > From what I've recently read, the freeze should be lifting > this week. Can we hold off till then? Is a few more days > going to matter? If the freeze continues longer than expected, > I'll back the change out until it's over. I think we are going to extend it to allow more fixes for 4.9 since it's going to be delayed. But I'm not positive. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
IMHO if the ports tree is unfrozen for the -pthreads fixes, the 4.9 release schedule will drift days if not weeks. While it's not as apparent as the kernel build issues, there are significant QA issues that go into the ports system. That's why the freeze is in place, to allow the QA process to run its course. Executive summary: POLA was violated for all the ports maintainers who do not keep up with kernel intricacies. Dismissing their distress at this doesn't really help the project move along. mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
> I don't think committing fixes for -current breakages should cause > problems for 4.9-RELEASE (especially with the caveat that they be > compile tested on -stable). It takes several days to do the compile QA. That's assuming that no actual users are allowed to have time to test the changes before the release is cut. IMHO, what you think just doesn't reflect the actual reality involved. We are just going to have to disagree on this. You should really look at the bento logs and get an understanding of the continual QA that is done on the _over_ 9000 ports (many of which have _no_ maintainer signed up) before you make assumptions that there shouldn't be significant problems with what you propose. mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, 21 Sep 2003, Will Andrews wrote: > On Sun, Sep 21, 2003 at 03:17:28AM -0400, Daniel Eischen wrote: > > From what I've recently read, the freeze should be lifting > > this week. Can we hold off till then? Is a few more days > > going to matter? If the freeze continues longer than expected, > > I'll back the change out until it's over. > > I think we are going to extend it to allow more fixes for 4.9 > since it's going to be delayed. But I'm not positive. OK, instead of waiting for it to be delayed, I backed out the -pthread removal until it's over. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, 21 Sep 2003, Daniel Eischen wrote: > Well, actually it is directly related. Part of the plan to > transition to libpthread is making ports PTHREAD_LIBS compliant. > As stated in that thread, if a libpthread exists on the system, > autoconf/configure will pick it up and the port will also end up > using -pthread and/or PTHREAD_LIBS. If PTHREAD_LIBS is set > to libthr or libc_r (something other than libpthread), then > the port ends up linking to both libraries. This doesn't work > but you don't know it until your run the application and very > weird things happen. Causing a clean breakage is better because > you know at compile-time that something is wrong. So ports need to > first be PTHREAD_LIBS compliant before we make the switch. Soon > after ports are fixed, we can rename it. Where the ports are concerned, I think this is a reasonable course of action, and I'd like to thank you for backing out the -pthread change on HEAD. I am a little confused about one thing though. What is going to happen to third party apps that use -pthread that aren't compiled through the ports? Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, Sep 21, 2003 at 01:25:09AM -0700, Doug Barton wrote: > I am a little confused about one thing though. What is going to > happen to third party apps that use -pthread that aren't compiled > through the ports? They need to replace -pthread with their thread library of choice (e.g. -lc_r or -lpthread). -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, 21 Sep 2003, Doug Barton wrote: > On Sun, 21 Sep 2003, Daniel Eischen wrote: > > > Well, actually it is directly related. Part of the plan to > > transition to libpthread is making ports PTHREAD_LIBS compliant. > > As stated in that thread, if a libpthread exists on the system, > > autoconf/configure will pick it up and the port will also end up > > using -pthread and/or PTHREAD_LIBS. If PTHREAD_LIBS is set > > to libthr or libc_r (something other than libpthread), then > > the port ends up linking to both libraries. This doesn't work > > but you don't know it until your run the application and very > > weird things happen. Causing a clean breakage is better because > > you know at compile-time that something is wrong. So ports need to > > first be PTHREAD_LIBS compliant before we make the switch. Soon > > after ports are fixed, we can rename it. > > Where the ports are concerned, I think this is a reasonable course of > action, and I'd like to thank you for backing out the -pthread change on > HEAD. I am a little confused about one thing though. What is going to > happen to third party apps that use -pthread that aren't compiled > through the ports? They'll have to choose one of our threading libraries. -pthread will be a NOOP for them, so their application will fail to link. If the third party application is a library, it won't be as obvious because it won't cause a compile or link error. This holds true for ports also. It might not be that much of a problem though, because applications that link to the third party library can always link to whatever threads library they want. Then the third party library would end up using the threads library chosen by the application. This might be the way to go for OpenGL or other similar libraries. It allows you to have applications linked with different thread libraries and not be broken by OpenGL (or whatever) being explicitly linked to a different threads library than the application. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, 21 Sep 2003, John Birrell wrote: > On Sun, Sep 21, 2003 at 01:25:09AM -0700, Doug Barton wrote: > > I am a little confused about one thing though. What is going to > > happen to third party apps that use -pthread that aren't compiled > > through the ports? > > They need to replace -pthread with their thread library of choice > (e.g. -lc_r or -lpthread). E... I'm not sure this is an optimal solution. There is an awful lot of software out there which expects -pthread to "just work." Wouldn't it make more sense to default it to one thing or the other, then make it configurable (isn't this what libmap.conf is supposed to help with)? Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, 21 Sep 2003, Doug Barton wrote: > On Sun, 21 Sep 2003, John Birrell wrote: > > > On Sun, Sep 21, 2003 at 01:25:09AM -0700, Doug Barton wrote: > > > I am a little confused about one thing though. What is going to > > > happen to third party apps that use -pthread that aren't compiled > > > through the ports? > > > > They need to replace -pthread with their thread library of choice > > (e.g. -lc_r or -lpthread). > > E... I'm not sure this is an optimal solution. There is an awful > lot of software out there which expects -pthread to "just work." > Wouldn't it make more sense to default it to one thing or the other, > then make it configurable (isn't this what libmap.conf is supposed to > help with)? We've already been over this before. The problem is not as bad as you think, and there are other platforms that don't have -pthread. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Mon, 2003-09-22 at 00:42, Daniel Eischen wrote: > We've already been over this before. The problem is not > as bad as you think, and there are other platforms that > don't have -pthread. And those platforms would be? Sincerely, Dan Naumov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Mon, 22 Sep 2003, Dan Naumov wrote: > On Mon, 2003-09-22 at 00:42, Daniel Eischen wrote: > > We've already been over this before. The problem is not > > as bad as you think, and there are other platforms that > > don't have -pthread. > > And those platforms would be? Solaris for one: bash-2.05$ uname -a SunOS pcnet5 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-2 bash-2.05$ type cc cc is hashed (/usr/ucb/cc) bash-2.05$ type gcc gcc is hashed (/usr/local/bin/gcc) bash-2.05$ cc -pthread cc: unrecognized option `-pthread' cc: No input files bash-2.05$ gcc -pthread gcc: unrecognized option `-pthread' gcc: No input files gcc does have -pthreads and -threads for Solaris, but these are basically NOOPs (just what we are doing). They define -D_REENTRANT -D_PTHREADS for -pthreads and -D_REENTRANT and -D_SOLARIS_THREADS for -threads. These do not specify any libraries to link, just predefines. FreeBSD doesn't have anything to predefine, so it is a true NOOP. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, 21 Sep 2003, Daniel Eischen wrote: > On Mon, 22 Sep 2003, Dan Naumov wrote: > > > On Mon, 2003-09-22 at 00:42, Daniel Eischen wrote: > > > We've already been over this before. The problem is not > > > as bad as you think, and there are other platforms that > > > don't have -pthread. > > > > And those platforms would be? > > Solaris for one: > > bash-2.05$ uname -a > SunOS pcnet5 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-2 > bash-2.05$ type cc > cc is hashed (/usr/ucb/cc) > bash-2.05$ type gcc > gcc is hashed (/usr/local/bin/gcc) > bash-2.05$ cc -pthread > cc: unrecognized option `-pthread' > cc: No input files > bash-2.05$ gcc -pthread > gcc: unrecognized option `-pthread' > gcc: No input files > > gcc does have -pthreads and -threads for Solaris, but these are > basically NOOPs (just what we are doing). They define > -D_REENTRANT -D_PTHREADS for -pthreads and -D_REENTRANT > and -D_SOLARIS_THREADS for -threads. These do not specify > any libraries to link, just predefines. FreeBSD doesn't > have anything to predefine, so it is a true NOOP. Actually, it does look like the Solaris -threads and -pthreads options do imply linking to -lthread and -lpthread respectively (when not building with -shared). But regardless, -threads and -pthreads are not portable. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
Doug Barton wrote: On Sun, 21 Sep 2003, John Birrell wrote: On Sun, Sep 21, 2003 at 01:25:09AM -0700, Doug Barton wrote: I am a little confused about one thing though. What is going to happen to third party apps that use -pthread that aren't compiled through the ports? They need to replace -pthread with their thread library of choice (e.g. -lc_r or -lpthread). E... I'm not sure this is an optimal solution. There is an awful lot of software out there which expects -pthread to "just work." Wouldn't it make more sense to default it to one thing or the other, then make it configurable (isn't this what libmap.conf is supposed to help with)? Doug I have to agree with this. '-pthread' seems to have taken on the meaning of 'turn on whatever magic makes the pthreads library work'. The application writer is allowed to focus on the application, not the FreeBSD-specific threading library options. The user is allowed to compile a third-party app without having to worry about the FreeBSD-specific threading library options. Everyone wins. If we take the stand that any software that uses '-pthread' is broken and should be fixed by the author, it will make FreeBSD wildly unpopular. If we take the stand that the only sactioned way to compile a third-party app in FreeBSD is via the ports system, then FreeBSD will become much less usable. I've tried to stay silent on this issue in hopes that it would work itself out, but I'm not quite sure that it is. Making FreeBSD harder to use and harder to program for in the name of pendanticy is not the best direction. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, 21 Sep 2003, Scott Long wrote: > Doug Barton wrote: > > E... I'm not sure this is an optimal solution. There is an awful > > lot of software out there which expects -pthread to "just work." > > Wouldn't it make more sense to default it to one thing or the other, > > then make it configurable (isn't this what libmap.conf is supposed to > > help with)? > > > > Doug > > > > I have to agree with this. '-pthread' seems to have taken on the > meaning of 'turn on whatever magic makes the pthreads library work'. > The application writer is allowed to focus on the application, not > the FreeBSD-specific threading library options. The user is allowed > to compile a third-party app without having to worry about the > FreeBSD-specific threading library options. Everyone wins. Most everyone that writes threaded applications and runs on multiple platforms knows that most thread libraries are called libpthread and are linked to with -lpthread. Once we rename libkse to libpthread, the problem largely goes away. The porter, or configure script, will find libpthread and all should be fine. > If we take the stand that any software that uses '-pthread' is broken > and should be fixed by the author, it will make FreeBSD wildly > unpopular. If we take the stand that the only sactioned way to > compile a third-party app in FreeBSD is via the ports system, then > FreeBSD will become much less usable. There will be a libpthread and -pthread will be NOOP'd. It should be a very familiar environment. > I've tried to stay silent on this issue in hopes that it would work > itself out, but I'm not quite sure that it is. Making FreeBSD harder > to use and harder to program for in the name of pendanticy is not the > best direction. As I've said in a previous email, Solaris doesn't have -pthread and it hasn't seemed to cause any problems. If you are going to have -pthread (libpthread), -thread (libpthread1:1), -thr (libthr), -uthread (libc_r), this is no different than making them the appropriate link arguments. There should be very little problem for 3rd party applications. -pthread won't cause an error. If there is any problem, it will be on the link command and it should be very obvious that a threading library wasn't pulled in. Since a libpthread will be present on the system, it's pretty much a no-brainer how to fix the problem. This is not like we're changing kernel or library interfaces. I think folks are making a bigger deal out of it than it really is. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Fixing -pthreads (Re: ports and -current)
> On Sun, 21 Sep 2003, Scott Long wrote: > Most everyone that writes threaded applications and runs on > multiple platforms knows that most thread libraries are > called libpthread and are linked to with -lpthread. Once > we rename libkse to libpthread, the problem largely goes > away. The porter, or configure script, will find libpthread > and all should be fine. No, most people only fall back on trying to figure out what threading library to link to if '-pthread' causes an error. > There will be a libpthread and -pthread will be NOOP'd. It > should be a very familiar environment. You know another environment that has '-pthread' (that is, it does not produce an error) but fails to compile and link pthreads code when that flag is supplied? > As I've said in a previous email, Solaris doesn't have -pthread > and it hasn't seemed to cause any problems. If you are going > to have -pthread (libpthread), -thread (libpthread1:1), > -thr (libthr), -uthread (libc_r), this is no different than > making them the appropriate link arguments. Yes, but it returns an error when '-pthread' is supplied. > There should be very little problem for 3rd party applications. > -pthread won't cause an error. That's the problem. This will dupe configuration scripts into believing that the option is supported. > If there is any problem, it > will be on the link command and it should be very obvious > that a threading library wasn't pulled in. Since a libpthread > will be present on the system, it's pretty much a no-brainer > how to fix the problem. Yes, by either removing the '-pthread' flag or making it work. > This is not like we're changing kernel or library interfaces. > I think folks are making a bigger deal out of it than it > really is. The whole point of '-pthread' is to provide one standardized way to easily figure out what magic compiler/linker flags you need so you don't have to special case every platform. However, you are suggesting behavior for this flag that is unlike any other platform, turning the stardization attempt on its head. DS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Fixing -pthreads (Re: ports and -current)
On Mon, 22 Sep 2003, David Schwartz wrote: > > There will be a libpthread and -pthread will be NOOP'd. It > > should be a very familiar environment. > > You know another environment that has '-pthread' (that is, it does not > produce an error) but fails to compile and link pthreads code when that flag > is supplied? No. There are other environments that don't have -pthread though. > > As I've said in a previous email, Solaris doesn't have -pthread > > and it hasn't seemed to cause any problems. If you are going > > to have -pthread (libpthread), -thread (libpthread1:1), > > -thr (libthr), -uthread (libc_r), this is no different than > > making them the appropriate link arguments. > > Yes, but it returns an error when '-pthread' is supplied. > > > There should be very little problem for 3rd party applications. > > -pthread won't cause an error. > > That's the problem. This will dupe configuration scripts into believing > that the option is supported. No, some scripts use both -pthread and -lpthread together already (on Linux!). I just checked the configure script in kdebase-3.1.3. The threads library check seems to be independent of the compiler check. To test this, I made a link from /usr/lib/libpthread.so to /usr/lib/libkse.so and manually ran the configure script. It worked just fine. It picked up -lpthread and didn't use -pthread (on this system, -pthread still worked). > > > If there is any problem, it > > will be on the link command and it should be very obvious > > that a threading library wasn't pulled in. Since a libpthread > > will be present on the system, it's pretty much a no-brainer > > how to fix the problem. > > Yes, by either removing the '-pthread' flag or making it work. I'm all for removing it, but our FSF GCC maintainer thought it better to make it a NOOP. We're just going by his advice. > > > This is not like we're changing kernel or library interfaces. > > I think folks are making a bigger deal out of it than it > > really is. > > The whole point of '-pthread' is to provide one standardized way to easily > figure out what magic compiler/linker flags you need so you don't have to > special case every platform. However, you are suggesting behavior for this > flag that is unlike any other platform, turning the stardization attempt on > its head. Why do you want to shoehorn -pthread onto us when it is not a good fit? We don't have one standard library. The example I like to use is Solaris. They have 2 thread libraries and have a compiler switch for each one (-pthreads and -threads, note -pthreads != -pthread). Probably the reason they have a compiler switch in the first place is because they need to define __REENTRANT; FreeBSD doesn't need to define anything. If you are going to have more than one compiler switch, then it defeats the purpose for it because you might just as well use the correct link command. Don't think about ports. We have to make them PTHREAD_LIBS compliant so the user can select a different library. If you want to argue that, then start another discussion on ports about it. This is about 3rd party applications built outside of ports. The only possible problem you are going to have is on the link command, and it should be obvious that you're missing a link to the threads library. This is trivial to fix. It's not like we're making someone change their code to accomodate library or kernel interface changes. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
Daniel Eischen wrote: This is about 3rd party applications built outside of ports. The only possible problem you are going to have is on the link command, and it should be obvious that you're missing a link to the threads library. This is trivial to fix. It's not like we're making someone change their code to accomodate library or kernel interface changes. This is exactly the case the is going to cause the problems, though. For you, compiling a 3rd party app and dealing with failures in the linker is easy to deal with. For someone else, it might not be. If they go to compile an app and it compiles and runs fine on linux but fails on FreeBSD with linker errors, it will likely leave a negative impression in their mind. I'm comparing my arguments to linux because a lot more apps are written with linux in mind than with solaris in mind these days. People who are writing for linux or switching from linux might not know that '-lpthread' is a requirement, but they are more likely to know that '-pthread' will take care of all of that magic for them. This argument really comes down to ease of use and user experience. Steering away from de-facto standards steers us away from a positive user and developer experience. I'm perfectly happy to support the libkse->libpthread switch, and I'm perfectly happy to support making libpthread be the default threading library. But, I strongly believe that we need to also treat -pthread sanely. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Mon, Sep 22, 2003 at 10:35:10PM -0600, Scott Long wrote: [...] Scott said it all for me. Seriously. The whole idea of breaking backwards & de-facto compatibility is bad, bad, bad. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Mon, Sep 22, 2003 at 10:35:10PM -0600, Scott Long wrote: > Daniel Eischen wrote: > >This is about 3rd party applications built outside of > >ports. The only possible problem you are going to > >have is on the link command, and it should be obvious > >that you're missing a link to the threads library. > >This is trivial to fix. It's not like we're making > >someone change their code to accomodate library or > >kernel interface changes. > > > > This is exactly the case the is going to cause the problems, though. > For you, compiling a 3rd party app and dealing with failures in the > linker is easy to deal with. For someone else, it might not be. If > they go to compile an app and it compiles and runs fine on linux but > fails on FreeBSD with linker errors, it will likely leave a negative > impression in their mind. > > I'm comparing my arguments to linux because a lot more apps are written > with linux in mind than with solaris in mind these days. People who are > writing for linux or switching from linux might not know that > '-lpthread' is a requirement, but they are more likely to know that > '-pthread' will take care of all of that magic for them. This argument > really comes down to ease of use and user experience. Steering away > from de-facto standards steers us away from a positive user and > developer experience. > If the behavior of -pthread is documented in the man pages, then your argument holds no water. If the link stage fails, one would hope that the user can read the documention. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
Steve Kargl wrote: On Mon, Sep 22, 2003 at 10:35:10PM -0600, Scott Long wrote: Daniel Eischen wrote: This is about 3rd party applications built outside of ports. The only possible problem you are going to have is on the link command, and it should be obvious that you're missing a link to the threads library. This is trivial to fix. It's not like we're making someone change their code to accomodate library or kernel interface changes. This is exactly the case the is going to cause the problems, though. For you, compiling a 3rd party app and dealing with failures in the linker is easy to deal with. For someone else, it might not be. If they go to compile an app and it compiles and runs fine on linux but fails on FreeBSD with linker errors, it will likely leave a negative impression in their mind. I'm comparing my arguments to linux because a lot more apps are written with linux in mind than with solaris in mind these days. People who are writing for linux or switching from linux might not know that '-lpthread' is a requirement, but they are more likely to know that '-pthread' will take care of all of that magic for them. This argument really comes down to ease of use and user experience. Steering away from de-facto standards steers us away from a positive user and developer experience. If the behavior of -pthread is documented in the man pages, then your argument holds no water. If the link stage fails, one would hope that the user can read the documention. Many, many, many things that are documented in the man pages still generate questions and frustration. Adding an extra learning step is not the best way to make the OS more usable. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Mon, 22 Sep 2003, Scott Long wrote: > Daniel Eischen wrote: > > This is about 3rd party applications built outside of > > ports. The only possible problem you are going to > > have is on the link command, and it should be obvious > > that you're missing a link to the threads library. > > This is trivial to fix. It's not like we're making > > someone change their code to accomodate library or > > kernel interface changes. > > > > This is exactly the case the is going to cause the problems, though. > For you, compiling a 3rd party app and dealing with failures in the > linker is easy to deal with. For someone else, it might not be. If > they go to compile an app and it compiles and runs fine on linux but > fails on FreeBSD with linker errors, it will likely leave a negative > impression in their mind. > > I'm comparing my arguments to linux because a lot more apps are written > with linux in mind than with solaris in mind these days. People who are > writing for linux or switching from linux might not know that > '-lpthread' is a requirement, but they are more likely to know that > '-pthread' will take care of all of that magic for them. This argument > really comes down to ease of use and user experience. Steering away > from de-facto standards steers us away from a positive user and > developer experience. > > I'm perfectly happy to support the libkse->libpthread switch, and I'm > perfectly happy to support making libpthread be the default threading > library. But, I strongly believe that we need to also treat -pthread > sanely. I stand by my opinion. Also, you may end up breaking more things if -pthread causes libpthread to be linked in. Applications that want to link with libthread (1:1), libc_r, or libthr and use -pthread with -lpthread1:1, -lc_r, or -lthr will break. And it won't be obvious until weird things happen when they run. You guys are assuming this is going to cause large problems. Just wait and see. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
> I'm all for removing it, but our FSF GCC maintainer thought > it better to make it a NOOP. We're just going by his advice. I agreed that making -pthread == NOOP was probably better than the ~Sept 5 -CURRENT system compiler however that was not my full advice. In my view (and thus my advice), it is the stated collective opinion of the FSF gcc development team that -pthread should exist for all gcc ports which support POSIX threads. This is true even if not well documented. It would be best if adding the switch actually implied everything to support threads. If adding the -pthread switch is a NOOP to gcc but users could later add (e.g.): LD_PRELOAD=libc_r.so (or one of the newer choices) and not break anything, then I think that would be fully acceptable and meet the specification of the switch. This would be very cool in that you could test/run against multiple thread libraries without a re-link. If adding the -pthread switch is a NOOP to gcc but users must also add -lc_r (or one of the newer choices) for correct operation, then I think making it a NOOP is a bad idea and I attempted to state so. Regards, Loren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Tue, 23 Sep 2003, Loren James Rittle wrote: > > I'm all for removing it, but our FSF GCC maintainer thought > > it better to make it a NOOP. We're just going by his advice. > > I agreed that making -pthread == NOOP was probably better than the > ~Sept 5 -CURRENT system compiler however that was not my full advice. > > In my view (and thus my advice), it is the stated collective opinion > of the FSF gcc development team that -pthread should exist for all gcc > ports which support POSIX threads. This is true even if not well > documented. It would be best if adding the switch actually implied > everything to support threads. > > If adding the -pthread switch is a NOOP to gcc but users could later > add (e.g.): LD_PRELOAD=libc_r.so (or one of the newer choices) and not > break anything, then I think that would be fully acceptable and meet > the specification of the switch. This would be very cool in that you > could test/run against multiple thread libraries without a re-link. Yes, and I agree. If someone were to tell me how to implement that, I would do it. If it is just a matter of adding some missing pthread interfaces as stubs to libc, then it is pretty simple. > If adding the -pthread switch is a NOOP to gcc but users must also add > -lc_r (or one of the newer choices) for correct operation, then I > think making it a NOOP is a bad idea and I attempted to state so. Well, if they don't use LD_PRELOAD=libc_r.so or whatever and try to run the application, it isn't going to work very well using pthread stubs. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Fixing -pthreads (Re: ports and -current)
> On Mon, 22 Sep 2003, David Schwartz wrote: > No. There are other environments that don't have -pthread > though. So now FreeBSD will support a flag that numerous other platforms support, however it will support it differently from every other platform. On every other platform I know of where '-pthread' does anything other than generate an error, it causes the compiler to conform to the pthreads standard. FreeBSD will be the only platform that knows what '-pthread' is but doesn't do the right thing when it gets it. Isn't it good to have one flag that, on every platform that supports it, gives you whatever's needed to get the default pthreads implementation to work? And isn't that what '-pthread' was supposed to be for? > Why do you want to shoehorn -pthread onto us when it is not > a good fit? Then don't support it. Return an error and nothing will break. However, I'd also suggest making it easy for people to set '-pthread' to give whatever pthreads library they think is the most sensible default for their installation. There is a push to make all platforms that support pthreads support '-pthread' to provide the needed compiler/linker goo to make pthreads work. This move is a slap in the face against that standardization effort. It means that configuration scripts will have to special case FreeBSD's current behavior. And in the future, if FreeBSD threading libraries start requiring compiler goo, they'll have to special case again. Another imcompatible definition for the same compiler flag is a slap in the face to the effort to standardize the meaning of the '-pthread' flag. This is, I realize, turning into a bikeshed. This is cut down from a much longer reply that I wrote while downloading email that made most of the other points I was going to make. DS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Fixing -pthreads (Re: ports and -current)
On Tue, 23 Sep 2003, David Schwartz wrote: > > > On Mon, 22 Sep 2003, David Schwartz wrote: > > > No. There are other environments that don't have -pthread > > though. > > So now FreeBSD will support a flag that numerous other platforms support, > however it will support it differently from every other platform. On every > other platform I know of where '-pthread' does anything other than generate > an error, it causes the compiler to conform to the pthreads standard. > FreeBSD will be the only platform that knows what '-pthread' is but doesn't > do the right thing when it gets it. > > Isn't it good to have one flag that, on every platform that supports it, > gives you whatever's needed to get the default pthreads implementation to > work? And isn't that what '-pthread' was supposed to be for? > > > Why do you want to shoehorn -pthread onto us when it is not > > a good fit? > > Then don't support it. Return an error and nothing will break. You have the support of the threads guys here, including jb. But we've been pushed the other way. > However, I'd > also suggest making it easy for people to set '-pthread' to give whatever > pthreads library they think is the most sensible default for their > installation. You can't make it variable. I'm running out of energy here. None of the threads guys want -pthread and if forced on them would prefer it to be a NOOP. I am trying very hard not to be biased towards one threads library over another, and having -pthread automatically link to libpthread gives preference to it over libthr (or libthread (KSE in 1:1 mode) or libc_r). Pros: o Allows us to define macros common to all the threads libraries. o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that are not dependent on a particular threads library, but will use whatever threads library the application uses (i.e., you want mplayer to use libpthread and ogle to use libthr). o If we support LD_PRELOAD properly, will allow us to select the threads library without having to rebuild/relink the application. o Doesn't break applications that use both -pthread and -l. We've been able to link both libc_r and libc in -current for well over 2 years. Indeed, if you build KDE and X with libpthread installed, you will see binaries that are linked to both libc_r and libpthread. o Makes it easier to spot ports that are not PTHREAD_LIBS compliant. Cons: o Third party applications that use -pthread exclusively (without linking to a threads library) will have to add a link option. I understand that folks want to wave their hands and say "just make -pthread work and do whatever it needs to". I'm like that myself. I just don't think it's a good idea. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Fixing -pthreads (Re: ports and -current)
On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: > I understand that folks want to wave their hands and say "just make > -pthread work and do whatever it needs to". I am one of those folks as well. As an end-user, I am not interested in hacking around the source of 3rd-party applications that use -pthread when compiling them from source myself. Not in the slightest. This is BAD BAD BAD for usability. Sincerely, Dan Naumov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Fixing -pthreads (Re: ports and -current)
On Tue, 2003-09-23 at 23:25, Dan Naumov wrote: > On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: > > I understand that folks want to wave their hands and say "just make > > -pthread work and do whatever it needs to". > > I am one of those folks as well. As an end-user, I am not interested in > hacking around the source of 3rd-party applications that use -pthread > when compiling them from source myself. Not in the slightest. This is > BAD BAD BAD for usability. > > Sincerely, > Dan Naumov I also believe that a question has to be asked, what do the -core and -arch people think of all this ? I think that they should have the final say in the matter. Sincerely, Dan Naumov ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
Scott Long wrote: I'm perfectly happy to support the libkse->libpthread switch, and I'm perfectly happy to support making libpthread be the default threading library. But, I strongly believe that we need to also treat -pthread sanely. You have to decide what the therading lib should be indeed. However recent expirence shows that a 1:n model seems to be the one the world over you is gearing around: Linux never did anything else. Windows anyway. Solaris switched from n:m to 1:n on the step between version 8 and 9 Having two of them isn't the solution for me as a developer since I'm simply not interresed in debugging both cases. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
[cc trimmed] Hi Daniel, On Tue, Sep 23, 2003 at 04:13:11PM -0400, Daniel Eischen wrote: > > However, I'd > > also suggest making it easy for people to set '-pthread' to give whatever > > pthreads library they think is the most sensible default for their > > installation. > > You can't make it variable. I followed the whole thread and probably I'm being dense, but I still can't get this point. Note that I'm not taking position one way or the other, just asking. Why is that so? Isn't it possible to have -pthread: - do nothing when linking libraries - use libmap.conf(5) (possibly integrated by whatever env magic we want to add to allow this to be temporarily overridden) to decide what to link with. Bye, Andrea -- Press every key to continue. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Fixing -pthreads (Re: ports and -current)
On Tue, 23 Sep 2003, Daniel Eischen wrote: > Date: Tue, 23 Sep 2003 16:13:11 -0400 (EDT) > From: Daniel Eischen <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > To: David Schwartz <[EMAIL PROTECTED]> > Cc: Doug Barton <[EMAIL PROTECTED]>, Freebsd Current <[EMAIL PROTECTED]> > Subject: RE: Fixing -pthreads (Re: ports and -current) > ... >From a practical point of view: In former times nobody complained when we had only one threading library: libc_r. The only complaints came from its shortcomings... So could we please define that: - libpthread (aka libkse) is the primary threading library under FreeBSD. - libpthread gets linked agains unsing -pthread - The user can use whatever he wants instead of libpthread using /etc/libmap.conf - If libpthread should prove to have shortcomings it gets fixed or replaced by better software Bye/2 --- Michael Reifenberger, Business Unit Manager SAP-Basis, Plaut Consulting Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] http://www.plaut.de | http://www.Reifenberger.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Tue, 23 Sep 2003, Marcin Dalecki wrote: > Scott Long wrote: > > > I'm perfectly happy to support the libkse->libpthread switch, and I'm > > perfectly happy to support making libpthread be the default threading > > library. But, I strongly believe that we need to also treat -pthread > > sanely. > > You have to decide what the therading lib should be indeed. > However recent expirence shows that a 1:n model seems to be the > one the world over you is gearing around: Linux never did anything else. > Windows anyway. Solaris switched from n:m to 1:n on the step between > version 8 and 9 Having two of them isn't the solution for me as a developer > since I'm simply not interresed in debugging both cases. This is a reason why -pthread shouldn't imply linking to any one library. If you only want to deal with libthr or libthread (KSE in 1:1 mode), then you are free to choose them and only them. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Tue, 23 Sep 2003, Andrea Campi wrote: > [cc trimmed] > > Hi Daniel, > > On Tue, Sep 23, 2003 at 04:13:11PM -0400, Daniel Eischen wrote: > > > However, I'd > > > also suggest making it easy for people to set '-pthread' to give whatever > > > pthreads library they think is the most sensible default for their > > > installation. > > > > You can't make it variable. > > I followed the whole thread and probably I'm being dense, but I still can't > get this point. Note that I'm not taking position one way or the other, just > asking. > > Why is that so? Isn't it possible to have -pthread: > > - do nothing when linking libraries This could and should be done. > - use libmap.conf(5) (possibly integrated by whatever env magic we want to > add to allow this to be temporarily overridden) to decide what to link with. No, you can't do that. You're welcome to try. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
Daniel Eischen wrote: On Tue, 23 Sep 2003, Marcin Dalecki wrote: Scott Long wrote: I'm perfectly happy to support the libkse->libpthread switch, and I'm perfectly happy to support making libpthread be the default threading library. But, I strongly believe that we need to also treat -pthread sanely. You have to decide what the therading lib should be indeed. However recent expirence shows that a 1:n model seems to be the one the world over you is gearing around: Linux never did anything else. Windows anyway. Solaris switched from n:m to 1:n on the step between version 8 and 9 Having two of them isn't the solution for me as a developer since I'm simply not interresed in debugging both cases. This is a reason why -pthread shouldn't imply linking to any one library. If you only want to deal with libthr or libthread (KSE in 1:1 mode), then you are free to choose them and only them. Last time I heard that "this is a link time option". So you are supposed to change the lib under the hood of the applications controll. Making -ptherad empty is silly. If you are going to disable this perfectly sensible compiler switch then BY EVERY MEANS better make it BREAK CYRING ABOUT THIS FACT. But don't just silent it ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Wed, 24 Sep 2003, Marcin Dalecki wrote: > Daniel Eischen wrote: > > On Tue, 23 Sep 2003, Marcin Dalecki wrote: > > > > > >>Scott Long wrote: > >> > >> > >>>I'm perfectly happy to support the libkse->libpthread switch, and I'm > >>>perfectly happy to support making libpthread be the default threading > >>>library. But, I strongly believe that we need to also treat -pthread > >>>sanely. > >> > >>You have to decide what the therading lib should be indeed. > >>However recent expirence shows that a 1:n model seems to be the > >>one the world over you is gearing around: Linux never did anything else. > >>Windows anyway. Solaris switched from n:m to 1:n on the step between > >>version 8 and 9 Having two of them isn't the solution for me as a developer > >>since I'm simply not interresed in debugging both cases. > > > > > > This is a reason why -pthread shouldn't imply linking > > to any one library. If you only want to deal with > > libthr or libthread (KSE in 1:1 mode), then you are > > free to choose them and only them. > > Last time I heard that "this is a link time option". So you are supposed > to change the lib under the hood of the applications controll. The applications is free to link to whatever it wants; we're not changing that. If it wants to link to 1:1 libthr or whatever, then it had better be sure to use -lthr because -pthread won't do it regardless of whether it is a NOOP or not. > Making -ptherad empty is silly. If you are going to disable this > perfectly sensible compiler switch then BY EVERY MEANS better make it BREAK > CYRING ABOUT THIS FACT. But don't just silent it Making -pthread a NOOP _would_ (*) break the application in the link stage; it would be obvious when the application failed to link with lots of unresolved pthread symbols. (*) Unless we want to support LD_PRELOAD being able to change the threads library. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
Daniel Eischen wrote: On Tue, 23 Sep 2003, David Schwartz wrote: On Mon, 22 Sep 2003, David Schwartz wrote: No. There are other environments that don't have -pthread though. So now FreeBSD will support a flag that numerous other platforms support, however it will support it differently from every other platform. On every other platform I know of where '-pthread' does anything other than generate an error, it causes the compiler to conform to the pthreads standard. FreeBSD will be the only platform that knows what '-pthread' is but doesn't do the right thing when it gets it. Isn't it good to have one flag that, on every platform that supports it, gives you whatever's needed to get the default pthreads implementation to work? And isn't that what '-pthread' was supposed to be for? Why do you want to shoehorn -pthread onto us when it is not a good fit? Then don't support it. Return an error and nothing will break. You have the support of the threads guys here, including jb. But we've been pushed the other way. However, I'd also suggest making it easy for people to set '-pthread' to give whatever pthreads library they think is the most sensible default for their installation. You can't make it variable. I'm running out of energy here. None of the threads guys want -pthread and if forced on them would prefer it to be a NOOP. I am trying very hard not to be biased towards one threads library over another, and having -pthread automatically link to libpthread gives preference to it over libthr (or libthread (KSE in 1:1 mode) or libc_r). Pros: o Allows us to define macros common to all the threads libraries. o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that are not dependent on a particular threads library, but will use whatever threads library the application uses (i.e., you want mplayer to use libpthread and ogle to use libthr). I'm a big advocate of using libmap to deal with this. o If we support LD_PRELOAD properly, will allow us to select the threads library without having to rebuild/relink the application. I'm a big advocate of using libmap to deal with this. o Doesn't break applications that use both -pthread and -l. We've been able to link both libc_r and libc in -current for well over 2 years. Indeed, if you build KDE and X with libpthread installed, you will see binaries that are linked to both libc_r and libpthread. I can't see how this behaviour would not be considered a bug, if it is indeed true. Are you saying that there are packages out there that will detect both -lpthread and -pthread and attempt to use both on the compilers and linker lines? o Makes it easier to spot ports that are not PTHREAD_LIBS compliant. PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't mean anything outside of that. I suspect that the majority of users won't give a hoot about the mechanics of all of this as long as it Just Works. The more sophisticated users that want to mix/match threading libraries can be expected to exert a little more effort and learn the tools like libmap, etc. Cons: o Third party applications that use -pthread exclusively (without linking to a threads library) will have to add a link option. This is where I have the biggest problem. I firmly believe that it is incorrect for you to downplay this scenario, and it appears that others agree too. This is the case that will give us the black eye with users and developers that want things to Just Work. I understand that folks want to wave their hands and say "just make -pthread work and do whatever it needs to". I'm like that myself. I just don't think it's a good idea. I'm unclear why it is impossible to do this. The whole point of -pthread is to make it Just Work. We have complete control over how we make that happen. Why is it impossible to make -pthread honor PTHREAD_LIBS? Why is it impossible to fix ports that try to mix pthread schemas? Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
Daniel Eischen wrote: Making -pthread a NOOP _would_ (*) break the application in the link stage; it would be obvious when the application failed to link with lots of unresolved pthread symbols. Yeah it would break. It would break in a way where the first thing I would suppose to be the case would be a problem with the compiler install instead of what it's supposed to tell me. I still stay by this: This is silly and annoying for someone not esp. interrested in all those wars about which thread lib is better then the other. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On (2003/09/23 19:35), Daniel Eischen wrote:
> The applications is free to link to whatever it wants;
> we're not changing that. If it wants to link to 1:1
> libthr or whatever, then it had better be sure to use
> -lthr because -pthread won't do it regardless of whether
> it is a NOOP or not.
Okay, so what are we supposed to do to ports that are now broken because
-pthread doesn't exist (e.g. devel/pwlib)?
This discussion has gone around in circles and I haven't read every
message, but it's pretty obvious there's a lot of confusion.
Is there a simple rule we should follow when trying to fix ports, or do
we have to think now? At the moment, I'm just patching configure files
to use ${PTHREAD_LIBS} instead of -pthread, and pushing PTHREAD_LIBS
into the ports' CONFIGURE_ENV.
Ciao,
Sheldon.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Wed, Sep 24, 2003 at 11:51:53AM +0200, Sheldon Hearn wrote:
> Okay, so what are we supposed to do to ports that are now broken because
> -pthread doesn't exist (e.g. devel/pwlib)?
-pthread is back in current. It just had a little holiday. It's back,
refreshed, eager and willing to do the deed. 8-)
> Is there a simple rule we should follow when trying to fix ports, or do
> we have to think now?
Someone has to think and make a decision. Is simplicity (the -pthread switch)
reason enough to support one thread library by default?
> At the moment, I'm just patching configure files
> to use ${PTHREAD_LIBS} instead of -pthread, and pushing PTHREAD_LIBS
> into the ports' CONFIGURE_ENV.
I don't think that CONFIGURE_ENV should be modified in each port's makefile
to cope with PTHREAD_LIBS. It's supposed to be a ports-wide thing, so it
belongs in bsd.port.mk.
--
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
Why don't we make -pthread link to the *default* thread library (kse)? Solaris has a similar -mt option: -mt Passes D_REENTRANT to preprocessor. Appends -lthread after all other user-specified libraries on the command line. If you are doing your own multithread coding, you must use this option in the compile and link steps. To obtain faster execution, this option requires a multiprocessor system. On a single-processor system, the resulting executable usually runs more slowly with this option. Solaris 8 also has two pthread libraries, M:N and 1:1, located in /usr/lib and /usr/lib/lwp, respectively. It defaults to M:N, but the alternate libpthread can be selected at runtime by setting the dynamic linker search path as follows: LD_LIBRARY_PATH=/usr/lib/lwp (32-bit) LD_LIBRARY_PATH_64=/usr/lib/lwp/sparcv9 (64-bit) Alternatively, the runpath can be specified at link time: cc -mt ... -R /usr/lib/lwp (32-bit) cc -mt ... -R /usr/lib/lwp/sparcv9 (64-bit) Alex Keahan Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On (2003/09/24 20:18), John Birrell wrote: > > Okay, so what are we supposed to do to ports that are now broken because > > -pthread doesn't exist (e.g. devel/pwlib)? > > -pthread is back in current. It just had a little holiday. It's back, > refreshed, eager and willing to do the deed. 8-) That's really, REALLY good news. Will Andrews recently posted a patch on -current and mentioned that -pthread is back but will go away again soon. Can I relax and disregard his comment? :-) > > Is there a simple rule we should follow when trying to fix ports, or do > > we have to think now? > > Someone has to think and make a decision. Is simplicity (the -pthread switch) > reason enough to support one thread library by default? I'm happy with -pthread providing a simple default, which I can override if I think I know what my software really wants. :-) Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
At 7:35 PM -0400 2003/09/23, Daniel Eischen wrote: The applications is free to link to whatever it wants; we're not changing that. If it wants to link to 1:1 libthr or whatever, then it had better be sure to use -lthr because -pthread won't do it regardless of whether it is a NOOP or not. It strikes me that the compiler and linker should be able to detect -lthr vs. -lpthread vs. -lksethread (or whatever) on the command line, and if they see something like that to just DTRT with regards to a -pthread as well. Contrariwise, if there is a -pthread and no corresponding -lthr, -lpthread, or other thread library linkage that is explicitly specified, then we should be able to go through pmap.conf and figure out what the default "right thing" is that should be done. What am I missing? Making -pthread a NOOP _would_ (*) break the application in the link stage; it would be obvious when the application failed to link with lots of unresolved pthread symbols. (*) Unless we want to support LD_PRELOAD being able to change the threads library. That would seem to be another reasonable option. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Fixing -pthreads (Re: ports and -current)
On 23-Sep-2003 Dan Naumov wrote: > On Tue, 2003-09-23 at 23:25, Dan Naumov wrote: >> On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: >> > I understand that folks want to wave their hands and say "just make >> > -pthread work and do whatever it needs to". >> >> I am one of those folks as well. As an end-user, I am not interested in >> hacking around the source of 3rd-party applications that use -pthread >> when compiling them from source myself. Not in the slightest. This is >> BAD BAD BAD for usability. >> >> Sincerely, >> Dan Naumov > > I also believe that a question has to be asked, what do the -core and > -arch people think of all this ? I think that they should have the final > say in the matter. I think having a magic option to gcc that translates to 'link with the foo library' is rediculous. What's next, a gcc -math to get the math functions in libm? The fact that functions live in libraries and that to get access to said functions you link with said libraries has been the practice on Un*x for longer than I've been alive. Please, people, let the -pthread hack die and just use -l. I think any FreeBSD-specific -pthread bits should just be removed and have the compiler complain about a bogus option. If gcc chooses to have a machine independent -pthread (or -thread) to turn on TLS or some such, that's great and all, but that would be gcc code, not FreeBSD-specific code. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Wed, 24 Sep 2003, Scott Long wrote: > I'm a big advocate of using libmap to deal with this. Ditto. Based on the results seen thus far, my preference would really be for: (1) Keep -pthread, make it imply -lpthread, saving a lot of hassle. (2) Ship all packages and binaries using threading with -lpthread -- i.e., a dynamic library dependency on libpthread. This will mean that administrators don't have to list each possible threading library in /etc/libmap.conf in order to be sure they caught all of them. (3) Use libmap to perform the necessary substitution on a per-application or per-system basis. If libpthread isn't available on an architecture, default ship libmap.conf to substitute libthr for libpthread on the platform for all applications. Or libc_r, or whatever. This will result in all applications we ship having a consistent thread library name so that administrators can substitute more easily. libpthread would give you M:N threading by default, but it would be easy to perform local changes to improve performance for applications that specifically benefit from 1:1 threading, cothreads, etc. Or if a serious compatibility bug is found between libpthread and an application, they can substitute easily as well. I suppose this case might imply (4): (4) If an application is known to be compatible only with a specific threading model, do hard-code that in the application build somehow. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
> > On Wed, 24 Sep 2003, Scott Long wrote: > >> I'm a big advocate of using libmap to deal with this. > > Ditto. > > Based on the results seen thus far, my preference would really be for: > > (1) Keep -pthread, make it imply -lpthread, saving a lot of hassle. > > (2) Ship all packages and binaries using threading with -lpthread -- > i.e., > a dynamic library dependency on libpthread. This will mean that > administrators don't have to list each possible threading library in > /etc/libmap.conf in order to be sure they caught all of them. > > (3) Use libmap to perform the necessary substitution on a > per-application > or per-system basis. If libpthread isn't available on an > architecture, default ship libmap.conf to substitute libthr for > libpthread on the platform for all applications. Or libc_r, or > whatever. > > This will result in all applications we ship having a consistent thread > library name so that administrators can substitute more easily. > libpthread would give you M:N threading by default, but it would be easy > to perform local changes to improve performance for applications that > specifically benefit from 1:1 threading, cothreads, etc. Or if a > serious compatibility bug is found between libpthread and an > application, they can substitute easily as well. I suppose this case > might imply (4): > > (4) If an application is known to be compatible only with a specific > threading model, do hard-code that in the application build somehow. This sounds to me like the best solution I've seen so far. We have libmap, so why not use it? Only expert users will probably want to play with different thread libraries, and they can find out about libmap.conf themselves. Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On 23-Sep-2003 Scott Long wrote: > Daniel Eischen wrote: >> This is about 3rd party applications built outside of >> ports. The only possible problem you are going to >> have is on the link command, and it should be obvious >> that you're missing a link to the threads library. >> This is trivial to fix. It's not like we're making >> someone change their code to accomodate library or >> kernel interface changes. >> > > This is exactly the case the is going to cause the problems, though. > For you, compiling a 3rd party app and dealing with failures in the > linker is easy to deal with. For someone else, it might not be. If > they go to compile an app and it compiles and runs fine on linux but > fails on FreeBSD with linker errors, it will likely leave a negative > impression in their mind. > > I'm comparing my arguments to linux because a lot more apps are written > with linux in mind than with solaris in mind these days. People who are > writing for linux or switching from linux might not know that > '-lpthread' is a requirement, but they are more likely to know that > '-pthread' will take care of all of that magic for them. This argument > really comes down to ease of use and user experience. Steering away > from de-facto standards steers us away from a positive user and > developer experience. > > I'm perfectly happy to support the libkse->libpthread switch, and I'm > perfectly happy to support making libpthread be the default threading > library. But, I strongly believe that we need to also treat -pthread > sanely. Erm, I thought (if I remember correctly), that all the autoconf scripts, etc., that I've seen for Linnex use -lpthread, not -pthread. So we are actually becoming more like the de facto standard by dropping -pthread, not less. -pthread is a hack, please let it die. Either that or lets have gcc -math (for libm), gcc -standalone (libstand?) gcc -X11 (for X libraries), gcc -kde, gcc -gnome, etc. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Wed, 24 Sep 2003, Scott Long wrote: > Daniel Eischen wrote: > > I'm running out of energy here. None of the threads guys want -pthread > > and if forced on them would prefer it to be a NOOP. I am trying very > > hard not to be biased towards one threads library over another, and > > having -pthread automatically link to libpthread gives preference to > > it over libthr (or libthread (KSE in 1:1 mode) or libc_r). > > > > Pros: > > o Allows us to define macros common to all the threads libraries. > > o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that > > are not dependent on a particular threads library, but will use > > whatever threads library the application uses (i.e., you want mplayer > > to use libpthread and ogle to use libthr). > > I'm a big advocate of using libmap to deal with this. It isn't clear that libmap can deal with libraries that are linked to one specific threads library, and how libmap'd applications work. If mplayer is libmap'd to libthr, ogle is libmap'd to libpthread, and both are linked to libGL which is linked to libc_r, what happens? At the least, -pthread should be a NOOP when building shared and dynamic. > > o If we support LD_PRELOAD properly, will allow us to select the > > threads library without having to rebuild/relink the application. > > I'm a big advocate of using libmap to deal with this. libmap is in /etc and not writable by normal users. LD_PRELOAD can be set in a script or command line. Our FSF GCC maintainer has been advocating it and it solves the problem without the need for libmap. > > > o Doesn't break applications that use both -pthread and -l. > > We've been able to link both libc_r and libc in -current for well > > over 2 years. Indeed, if you build KDE and X with libpthread installed, > > you will see binaries that are linked to both libc_r and libpthread. > > I can't see how this behaviour would not be considered a bug, if it is > indeed true. Are you saying that there are packages out there that will > detect both -lpthread and -pthread and attempt to use both on the > compilers and linker lines? Yes, it's not just that. They can also find libc_r and include that (-lc_r) with -pthread. I installed libkse as libpthread and made the appropriate links and built X and KDE and there were a lot of binaries that were linked to both libc_r and libpthread. Perhaps this is because some shared libraries were linked to one or the other while the applications got linked to the other one -- I don't know. Making -pthread a NOOP when building shared libraries may help the situation. > > o Makes it easier to spot ports that are not PTHREAD_LIBS compliant. > > PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't > mean anything outside of that. That just meant it makes it easier to maintain ports so that they are PTHREAD_LIBS compliant (they would break when linked). I know it has no bearing on 3rd party stuff. > I suspect that the majority of users won't give a hoot about the > mechanics of all of this as long as it Just Works. The more > sophisticated users that want to mix/match threading libraries can be > expected to exert a little more effort and learn the tools like libmap, > etc. > > > > > Cons: > > o Third party applications that use -pthread exclusively (without > > linking to a threads library) will have to add a link option. > > This is where I have the biggest problem. I firmly believe that it is > incorrect for you to downplay this scenario, and it appears that others > agree too. This is the case that will give us the black eye with users > and developers that want things to Just Work. Well, we can agree to disagree :-) I think folks are getting upset that -pthread is an error and seeing all the problems in ports and thinking the same thing is going to happen in 3rd party applications. Things aren't nearly as broke when it is a NOOP _and_ we have libpthread installed. Any configure script I've seen looks for -lpthread and will use it. > > I understand that folks want to wave their hands and say "just make > > -pthread work and do whatever it needs to". I'm like that myself. > > I just don't think it's a good idea. > > > > I'm unclear why it is impossible to do this. The whole point of > -pthread is to make it Just Work. We have complete control over how > we make that happen. Why is it impossible to make -pthread honor > PTHREAD_LIBS? PTHREAD_LIBS is an bsd.port.mk thing. -pthread is a compiler switch (contrib/gcc/config/freebsd-spec.h). I certainly don't know how you would do this. > Why is it impossible to fix ports that try to > mix pthread schemas? It's not impossible, it's just not as easy to spot them because they don't break when building. You have to wade through complaints saying "X doesn't work correctly, what happened?" and hopefully get an 'ldd X' out of them so you can spot the problem. Then you have to figure out if it
RE: Fixing -pthreads (Re: ports and -current)
On Wed, 24 Sep 2003, John Baldwin wrote: > > On 23-Sep-2003 Dan Naumov wrote: > > On Tue, 2003-09-23 at 23:25, Dan Naumov wrote: > >> On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: > >> > I understand that folks want to wave their hands and say "just make > >> > -pthread work and do whatever it needs to". > >> > >> I am one of those folks as well. As an end-user, I am not interested in > >> hacking around the source of 3rd-party applications that use -pthread > >> when compiling them from source myself. Not in the slightest. This is > >> BAD BAD BAD for usability. > >> > >> Sincerely, > >> Dan Naumov > > > > I also believe that a question has to be asked, what do the -core and > > -arch people think of all this ? I think that they should have the final > > say in the matter. > > I think having a magic option to gcc that translates to 'link with the > foo library' is rediculous. What's next, a gcc -math to get the math > functions in libm? The fact that functions live in libraries and that > to get access to said functions you link with said libraries has been > the practice on Un*x for longer than I've been alive. Please, people, > let the -pthread hack die and just use -l. > I think any FreeBSD-specific -pthread bits should just be removed > and have the compiler complain about a bogus option. If gcc chooses > to have a machine independent -pthread (or -thread) to turn on TLS or > some such, that's great and all, but that would be gcc code, not > FreeBSD-specific code. Where were you a few days ago! -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
[Mostly trying to stay out of this thread, but I must comment at least on this point.] On Wed, Sep 24, 2003 at 11:01:01AM -0400, Daniel Eischen wrote: > On Wed, 24 Sep 2003, Scott Long wrote: > > Daniel Eischen wrote: > > > o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that > > > are not dependent on a particular threads library, but will use > > > whatever threads library the application uses (i.e., you want mplayer > > > to use libpthread and ogle to use libthr). > > > > I'm a big advocate of using libmap to deal with this. > > It isn't clear that libmap can deal with libraries that are > linked to one specific threads library, and how libmap'd > applications work. If mplayer is libmap'd to libthr, > ogle is libmap'd to libpthread, and both are linked to > libGL which is linked to libc_r, what happens? > > At the least, -pthread should be a NOOP when building > shared and dynamic. While libmap is a very neat hack and very useful, it is indeed a hack and I do not think it should be the primary method of determining what libraries to load. The mere existance of a libmap.conf file means additional file opening and parsing every time a dynamically linked executable is loaded; as well as one or more string searches/substitutions for every dynamic object name that rtld encounters (not just thread libraries). I believe that we should be able to make decisions at link time and at run time. At link time, either (a) I want *this* threaded library damnit, or (b) choose a threaded library at run time, with (b) being the default. Choosing (a) probably allows you to shoot your foot by mixing threading libraries, but it may also allow you to use `extensions' that one threading library might provide but not another. At run time (if (b) was chosen at link time): use *this* threaded library. By what mechanism? I imagined that there could be a library (say libpthread :-P) that made the decision and loaded the *real* threading library and forwarded or fixed-up thread-related functions. A degenerate-but-simple implementation might be a symlink. This seems to be more-or-less what GCC developer Loren James Rittle <[EMAIL PROTECTED]> had in mind when he posted the following suggestion to freebsd-threads some weeks back: Thank you for considering these words. BTW, wouldn't it be cooler if (example only): -pthread (whatever the system default) -pthread=1 (1 process, aka -lc_r) -pthread=1:1 (1 process per thread, aka -lthr) -pthread=M:N (M threads in N processes, aka -lkse) -pthread=late/weak (perhaps not good ELF form, link against a stub to which all POSIX thread libraries on FreeBSD must conform, do not record the dependency ala FreeBSD4 default for -lc; or that does it in a weak manner en mass such that binding is deferred to the final selection made at a final link time) Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Wed, Sep 24, 2003 at 10:27:29AM -0500, Jacques A. Vidrine wrote: > At link time, either (a) I want *this* threaded library damnit, or (b) ^^^ > that one threading library might provide but not another. As an aside, apparently I couldn't (or at least didn't) decide between `threaded library' and `threading library'. I wasn't trying to make some subtle distinction here :-) Probably I should have said `thread library' throughout. Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
In message <[EMAIL PROTECTED]>, Daniel
Eischen writes:
>On Wed, 24 Sep 2003, Scott Long wrote:
>> PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't
>> mean anything outside of that.
>
>That just meant it makes it easier to maintain ports so that
>they are PTHREAD_LIBS compliant (they would break when linked).
>I know it has no bearing on 3rd party stuff.
Just to throw one further approach out on the table, below is a
patch that makes gcc read from a file to determine what library to
associate with the -pthread flag. It's a hack of course, and probably
neither correct or optimal. If you want to make -pthread mean libkse,
create an /etc/pthread.libs that looks like:
-lc_r: -lkse
-lc_r_p:-lkse_p
I haven't been following the discussion in any detail - this is
just another possibility that is worth mentioning as it could retain
compatibility for users that want -pthread to mean use the default
thread library.
Ian
Index: gcc.c
===
RCS file: /dump/FreeBSD-CVS/src/contrib/gcc/gcc.c,v
retrieving revision 1.36
diff -u -r1.36 gcc.c
--- gcc.c 11 Jul 2003 04:45:39 - 1.36
+++ gcc.c 24 Sep 2003 15:37:14 -
@@ -331,6 +331,7 @@
static const char *if_exists_spec_function PARAMS ((int, const char **));
static const char *if_exists_else_spec_function PARAMS ((int, const char **));
+static const char *thread_lib_override_spec_function PARAMS ((int, const char **));
/* The Specs Language
@@ -1440,6 +1441,7 @@
{
{ "if-exists", if_exists_spec_function },
{ "if-exists-else", if_exists_else_spec_function },
+ { "thread-lib-override", thread_lib_override_spec_function },
{ 0, 0 }
};
@@ -7335,4 +7337,46 @@
return argv[0];
return argv[1];
+}
+
+/* thread-lib-override built-in spec function.
+
+ Override a thread library according to /etc/pthread.libs */
+
+static const char *
+thread_lib_override_spec_function (argc, argv)
+ int argc;
+ const char **argv;
+{
+ static char buf[256];
+ FILE *fp;
+ int n;
+
+ /* Must have exactly one argument. */
+ if (argc != 1)
+return NULL;
+
+ fp = fopen ("/etc/pthread.libs", "r");
+ if (fp == NULL)
+return argv[0];
+
+ while (fgets (buf, sizeof(buf), fp) != NULL)
+{
+ n = strlen (buf);
+ while (n > 0 && buf[n - 1] == '\n')
+ buf[--n] = '\0';
+ if (buf[0] == '#' || buf[0] == '\0')
+ continue;
+ n = strlen (argv[0]);
+ if (strncmp (buf, argv[0], n) != 0 || n >= sizeof (buf) || buf[n] != ':')
+ continue;
+ n++;
+ while (buf[n] != '\0' && isspace ((unsigned char)buf[n]))
+ n++;
+ fclose (fp);
+
+ return &buf[n];
+}
+ fclose (fp);
+ return argv[0];
}
Index: config/freebsd-spec.h
===
RCS file: /dump/FreeBSD-CVS/src/contrib/gcc/config/freebsd-spec.h,v
retrieving revision 1.14
diff -u -r1.14 freebsd-spec.h
--- config/freebsd-spec.h 21 Sep 2003 07:59:16 - 1.14
+++ config/freebsd-spec.h 24 Sep 2003 15:38:11 -
@@ -160,8 +160,8 @@
#if __FreeBSD_version >= 500016
#define FBSD_LIB_SPEC "\
%{!shared: \
-%{!pg: %{pthread:-lc_r} -lc} \
-%{pg: %{pthread:-lc_r_p} -lc_p} \
+%{!pg: %{pthread:%:thread-lib-override(-lc_r)} -lc}\
+%{pg: %{pthread:%:thread-lib-override(-lc_r_p)} -lc_p}\
}"
#else
#define FBSD_LIB_SPEC "\
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Wed, 24 Sep 2003, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Daniel > Eischen writes: > >On Wed, 24 Sep 2003, Scott Long wrote: > >> PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't > >> mean anything outside of that. > > > >That just meant it makes it easier to maintain ports so that > >they are PTHREAD_LIBS compliant (they would break when linked). > >I know it has no bearing on 3rd party stuff. > > Just to throw one further approach out on the table, below is a > patch that makes gcc read from a file to determine what library to > associate with the -pthread flag. It's a hack of course, and probably > neither correct or optimal. Hey, neat. I wouldn't have known how to do such a thing from gcc. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Fixing -pthreads (Re: ports and -current)
On 24-Sep-2003 Daniel Eischen wrote: > On Wed, 24 Sep 2003, John Baldwin wrote: > >> >> On 23-Sep-2003 Dan Naumov wrote: >> > On Tue, 2003-09-23 at 23:25, Dan Naumov wrote: >> >> On Tue, 2003-09-23 at 23:13, Daniel Eischen wrote: >> >> > I understand that folks want to wave their hands and say "just make >> >> > -pthread work and do whatever it needs to". >> >> >> >> I am one of those folks as well. As an end-user, I am not interested in >> >> hacking around the source of 3rd-party applications that use -pthread >> >> when compiling them from source myself. Not in the slightest. This is >> >> BAD BAD BAD for usability. >> >> >> >> Sincerely, >> >> Dan Naumov >> > >> > I also believe that a question has to be asked, what do the -core and >> > -arch people think of all this ? I think that they should have the final >> > say in the matter. >> >> I think having a magic option to gcc that translates to 'link with the >> foo library' is rediculous. What's next, a gcc -math to get the math >> functions in libm? The fact that functions live in libraries and that >> to get access to said functions you link with said libraries has been >> the practice on Un*x for longer than I've been alive. Please, people, >> let the -pthread hack die and just use -l. >> I think any FreeBSD-specific -pthread bits should just be removed >> and have the compiler complain about a bogus option. If gcc chooses >> to have a machine independent -pthread (or -thread) to turn on TLS or >> some such, that's great and all, but that would be gcc code, not >> FreeBSD-specific code. > > Where were you a few days ago! DNS problems == no outbound e-mail. :-P If gcc does want to go with a gcc-mandated -pthread option, then we should follow suit with that (and it seems that gcc might), but I don't think we need a FreeBSD-only flag if gcc doesn't mandate a -pthread option. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Fixing -pthreads (Re: ports and -current)
I think it was John Baldwin who wrote: >> I think having a magic option to gcc that translates to 'link with the >> foo library' is rediculous. What's next, a gcc -math to get the math >> functions in libm? As far as POSIX is concerned, that's precisely how it works. `c99 foo.c -l m' means `link in the math functions, wherever they may happen to live'. Likewise `-l rt' for realtime -- and (relevant to this discussion) `-l pthread' for threads. There is no requirement that any of these libraries exist as such. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
In the last episode (Sep 24), Daniel Eischen said: > On Wed, 24 Sep 2003, Scott Long wrote: > > Daniel Eischen wrote: > > > o Doesn't break applications that use both -pthread and > > > -l. We've been able to link both libc_r and libc > > > in -current for well over 2 years. Indeed, if you build KDE > > > and X with libpthread installed, you will see binaries that > > > are linked to both libc_r and libpthread. > > > > I can't see how this behaviour would not be considered a bug, if it > > is indeed true. Are you saying that there are packages out there > > that will detect both -lpthread and -pthread and attempt to use > > both on the compilers and linker lines? > > Yes, it's not just that. They can also find libc_r and include that > (-lc_r) with -pthread. I installed libkse as libpthread and made the > appropriate links and built X and KDE and there were a lot of > binaries that were linked to both libc_r and libpthread. Does it really matter if you end up linked to multiple threads libraries? The first library providing a symbol wins, so the other shlibs just won't get used at all. Libraries linked from the executable trump libraries linked from libraries, and LD_PRELOAD wins above all. If one threads library exports a symbol not in the others, I'd call that an API bug in the first library. This should be no different from explicitly linking in dmalloc to override the malloc functions in libc, for example. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Wed, 24 Sep 2003, Dan Nelson wrote: > Does it really matter if you end up linked to multiple threads > libraries? The first library providing a symbol wins, so the other > shlibs just won't get used at all. Libraries linked from the executable > trump libraries linked from libraries, and LD_PRELOAD wins above all. > If one threads library exports a symbol not in the others, I'd call that > an API bug in the first library. > > This should be no different from explicitly linking in dmalloc to > override the malloc functions in libc, for example. One potential downside to the LD_PRELOAD approach is that it will only work for applications that aren't setuid/setgid. While today most of our privileged and credential-munging applications aren't threaded, I'd like to avoid precluding that in the future as much as possible. What mechanism should be used when LD_PRELOAD is being ignored due to issetugid() returning true? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
* Ian Dowse <[EMAIL PROTECTED]> [030924 12:03]:
> In message <[EMAIL PROTECTED]>, Daniel
> Eischen writes:
> >On Wed, 24 Sep 2003, Scott Long wrote:
> >> PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't
> >> mean anything outside of that.
> >
> >That just meant it makes it easier to maintain ports so that
> >they are PTHREAD_LIBS compliant (they would break when linked).
> >I know it has no bearing on 3rd party stuff.
>
> Just to throw one further approach out on the table, below is a
> patch that makes gcc read from a file to determine what library to
> associate with the -pthread flag. It's a hack of course, and probably
> neither correct or optimal. If you want to make -pthread mean libkse,
> create an /etc/pthread.libs that looks like:
I was looking through gcc last night to see how conceptually difficult
it would be to do something like this. But instead of a file, I was
thinking of this process:
* if env("PTHREADS_LIBS") then LDFLAGS += PTHREADS_LIBS
* elseif fileexists("libpthread") then LDFLAGS += -lpthread
* elseif fileexists("libthr") then LDFLAGS += -lthr
* elseif fileexists("libc_r") then LDFLAGS += -lc_r
* else error("Threading not supported.")
or whatever. At that point, simply having PTHREADS_LIBS moved into the
environment in bsd.port.mk and leaving all the ports using -pthread
alone would automatically have them support PTHREADS_LIBS. Even better,
the existing bsd.port.mk construct could become just another pre-defined
environment variable, similar to LD_PRELOAD for the runtime linker, but
which affects the compiler/link editor instead.
--Mike
pgp0.pgp
Description: PGP signature
Re: Fixing -pthreads (Re: ports and -current)
* Michael Edenfield <[EMAIL PROTECTED]> [030924 13:21]: > * Ian Dowse <[EMAIL PROTECTED]> [030924 12:03]: > > In message <[EMAIL PROTECTED]>, Daniel > > Eischen writes: > > >On Wed, 24 Sep 2003, Scott Long wrote: > > >> PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't > > >> mean anything outside of that. > > > > > >That just meant it makes it easier to maintain ports so that > > >they are PTHREAD_LIBS compliant (they would break when linked). > > >I know it has no bearing on 3rd party stuff. > > > > Just to throw one further approach out on the table, below is a > > patch that makes gcc read from a file to determine what library to > > associate with the -pthread flag. It's a hack of course, and probably > > neither correct or optimal. If you want to make -pthread mean libkse, > > create an /etc/pthread.libs that looks like: > > I was looking through gcc last night to see how conceptually difficult > it would be to do something like this. But instead of a file, I was > thinking of this process: I should point out that my main concern here is not technical but policy. Right now -pthread is implemented entirely as a gcc spec as part of LIB_SPEC. I didn't have time to get very far so I'm not sure how much special-case argument handling is done in gcc currently. Would this kind of approach, to moving the "-pthread" handling out of a specfile and into args handling code, fly with the FSF people? --Mike pgp0.pgp Description: PGP signature
