Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
On Wed, 10 Sep 2003 12:41:41 -0400 Michael Edenfield [EMAIL PROTECTED] wrote: Err, not quite. Tried to build gnome2 lately? :) gnome2 depends on gnomemedia2. gnomemedia2 depends on gstreamer-plugins. gstreamer-plugins fails because ARTSD_FLAGS in several dozen Makefiles includes -pthread. Artsd is a part of KDE and gstreamer-plugin doesn't build it by default (the plugin gets build if artsd is already installed or you have to ask for it). Artsd isn't maintained by gnome@ and it doesn't use the bsd.gnome.mk framework, so it doesn't fall into my definition of a GNOME port. Bye, Alexander. -- If Bill Gates had a dime for every time a Windows box crashed... ...Oh, wait a minute, he already does. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
On Wed, 10 Sep 2003 15:30:28 +0200 Michael Nottebrock [EMAIL PROTECTED] wrote: Sorry if this sounds a bit flame-ish, but the way I see it we now have a system compiler in -CURRENT that doesn't even compile a hello world if-pedantic is specified and breaks with lots of existing software out there This you have to ask the gcc people... that tries to use a threads library because -pthread errors out (why could this change not have been made _after_ 4.9 is out the door, btw.? Or before 5.0-R FWIW.) I don't see the connection between the change in the 5-current compiler and 4.9... Is the decision criterion for making acceptable changes to core system components that we can somehow make 3rd party software compiling via ports-collection hacks? I feel that a FreeBSD that manages to break so many existing configure-scripts and build systems is degraded in usefulness. In 5-current we have 3 threads libraries and want to be able to install and use them in parallel. So there has to be a way to specify which one. This is why we need the ports collection to respect the PTHREAD* variables. A lot of ports already do this (e.g. the GNOME ones), but not all. It may be inconvenient in the short term, but beneficial in the long term. Bye, Alexander. -- If Bill Gates had a dime for every time a Windows box crashed... ...Oh, wait a minute, he already does. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
Steve Kargl wrote: I have no problems in building the traditional C hello world program with cc -pedantic. You're right about that, you'll need a C++ hello world (iostream, cout). This is in the archives anyway and (should be) well known. (why could this change not have been made _after_ 4.9 is out the door, btw.? Or before 5.0-R FWIW.) 4.9 and 5.0-R are independent branch. By your logic we should wait to 4.10 or 4.11 or 4.12 or ... before any substantial change can be made to -CURRENT. The point is that is isn't wise to commit a change like the -pthread deprecation that breaks many ports just before a ports-freeze. The reason gcc-3.3.1 was committed before 5.0-R should be fairly obvious. I was concerned with the -pthread deprecation. I feel that a FreeBSD that manages to break so many existing configure-scripts and build systems is degraded in usefulness. Please see the Handbook for the distinction between -CURRENT and -STABLE. Oh please. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
Am Mi, 2003-09-10 um 15.30 schrieb Michael Nottebrock: Sorry if this sounds a bit flame-ish, but the way I see it we now have a system compiler in -CURRENT that doesn't even compile a hello world if -pedantic is specified and breaks with lots of existing software out there Yes. I agree on this. I would also like to have a compiler which compiles with strictest warning settings possible, because I'm developing on several platforms at once. But I like gcc-3.x (for my C++ programs) very much and would like to continue programming with this compiler, even it does not compile hello world with -pedantic. Wouldn't it be better to complain in a gcc mailing list? You know exactly that FreeBSD-current is offering the most recent technologies and _this_ is why I like it. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
* Alexander Leidinger [EMAIL PROTECTED] [030910 10:53]:
In 5-current we have 3 threads libraries and want to be able to install
and use them in parallel. So there has to be a way to specify which one.
This is why we need the ports collection to respect the PTHREAD*
variables. A lot of ports already do this (e.g. the GNOME ones), but not
all.
Err, not quite. Tried to build gnome2 lately? :)
gnome2 depends on gnomemedia2.
gnomemedia2 depends on gstreamer-plugins.
gstreamer-plugins fails because ARTSD_FLAGS in several dozen Makefiles
includes -pthread.
The fix is a pretty simple thing:
post-configure::
find ${WRKSRCDIR} -name Makefile | xargs ${SED} -e
s#-pthread#${PTHREAD_LIBS}#g' -i
But of course, it's not a problem on 4.x and the ports tree's frozen at
the moment, so it will probably be a bit until gnome2 fully compiles.
--Mike
pgp0.pgp
Description: PGP signature
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
On Wed, Sep 10, 2003 at 05:23:55PM +0200, Michael Nottebrock wrote: Steve Kargl wrote: I have no problems in building the traditional C hello world program with cc -pedantic. You're right about that, you'll need a C++ hello world (iostream, cout). This is in the archives anyway and (should be) well known. Yes, it is a well known issue. The user is getting exactly what they wanted when she gave -pedantic to g++. (why could this change not have been made _after_ 4.9 is out the door, btw.? Or before 5.0-R FWIW.) 4.9 and 5.0-R are independent branch. By your logic we should wait to 4.10 or 4.11 or 4.12 or ... before any substantial change can be made to -CURRENT. The point is that is isn't wise to commit a change like the -pthread deprecation that breaks many ports just before a ports-freeze. Which threads library should -pthread link to your app (libc_r, libkse, or libthr) on a 5.x system? The reason gcc-3.3.1 was committed before 5.0-R should be fairly obvious. I was concerned with the -pthread deprecation. Why? The portmgr can tag the ports collection at any point in time before or after the -pthread deprecation date. Additionally, your initial email started with your whining about -pedantic a and Hello world programs, which is completely orthogonal to -pthread. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
On Wed, Sep 10, 2003 at 12:41:41PM -0400, Michael Edenfield wrote: gnome2 depends on gnomemedia2. gnomemedia2 depends on gstreamer-plugins. gstreamer-plugins fails because ARTSD_FLAGS in several dozen Makefiles includes -pthread. This is being worked on from the compiler stand point. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
On Wed, Sep 10, 2003 at 09:56:45AM -0700, Steve Kargl wrote: 4.9 and 5.0-R are independent branch. By your logic we should wait to 4.10 or 4.11 or 4.12 or ... before any substantial change can be made to -CURRENT. The point is that is isn't wise to commit a change like the -pthread deprecation that breaks many ports just before a ports-freeze. Which threads library should -pthread link to your app (libc_r, libkse, or libthr) on a 5.x system? It should be a stub that libmap then maps to the threading lib you wanted. Or variations on this. If you have a strong interest in this there is a long discussion about this going on. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
On Wed, 10 Sep 2003, Michael Nottebrock wrote: Sorry if this sounds a bit flame-ish, but the way I see it we now have a system compiler in -CURRENT that doesn't even compile a hello world if -pedantic is specified and breaks with lots of existing software out there that tries to use a threads library because -pthread errors out (why could this change not have been made _after_ 4.9 is out the door, btw.? Or before 5.0-R FWIW.) It should have been made 2 years ago, a few months after libc_r became disconnected from libc. There was a whole thread about how ports should be using PTHREAD_LIBS and not using -pthread. Here is the link: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=629118+0+archive/2001/freebsd-current/20010218.freebsd-current As to the timing; it had to happen soon. We need time to iron out the problems before 5.2-RELEASE. This was the first step; there may be a little more pain in the future but this needed to be addressed first. Are we expecting people to be able to compile software directly from the commandline at all these days and in the future on a (stable) FreeBSD-5? Is the decision criterion for making acceptable changes to core system components that we can somehow make 3rd party software compiling via ports-collection hacks? Things need to get worse before they can get better. If I didn't break -pthread, ports@ would have a harder time trying to make things build with a threading library that is selectable via PTHREAD_LIBS. We've had 2.5 years to do this, but now it needs to get done before 5.2-RELEASE. I feel that a FreeBSD that manages to break so many existing configure-scripts and build systems is degraded in usefulness. Please, this is -current. If you want less pain then stick with -stable and you won't be annoyed by the -pthread removal. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
* David O'Brien [EMAIL PROTECTED] [030910 15:33]:
On Wed, Sep 10, 2003 at 12:41:41PM -0400, Michael Edenfield wrote:
gnome2 depends on gnomemedia2.
gnomemedia2 depends on gstreamer-plugins.
gstreamer-plugins fails because ARTSD_FLAGS in several dozen Makefiles
includes -pthread.
This is being worked on from the compiler stand point.
Which is the main reason I didn't do a pr on it. But from reading other
parts of the thread, it seems that ports should not be using -pthread
anyway... would it be worthwhile to submit patches to remove -pthread
(and, for that matter, -lpthread and other variants) in favor of
${PTHREAD_LIBS} regardless of wether `cc -pthread` is an error or a
no-op, or some magical auto-thread-library-selector?
--Mike
pgp0.pgp
Description: PGP signature
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
On Wed, 10 Sep 2003, Michael Edenfield wrote:
* David O'Brien [EMAIL PROTECTED] [030910 15:33]:
On Wed, Sep 10, 2003 at 12:41:41PM -0400, Michael Edenfield wrote:
gnome2 depends on gnomemedia2.
gnomemedia2 depends on gstreamer-plugins.
gstreamer-plugins fails because ARTSD_FLAGS in several dozen Makefiles
includes -pthread.
This is being worked on from the compiler stand point.
Which is the main reason I didn't do a pr on it. But from reading other
parts of the thread, it seems that ports should not be using -pthread
anyway... would it be worthwhile to submit patches to remove -pthread
(and, for that matter, -lpthread and other variants) in favor of
${PTHREAD_LIBS} regardless of wether `cc -pthread` is an error or a
no-op, or some magical auto-thread-library-selector?
Yes, ${PTHREAD_LIBS} should be used, except perhaps for
ports that are libraries. Under the proposed scheme,
libraries could be weakly linked to a stub pthread
library (or even pthread stubs in libc I suppose). Then
when an application (strongly linked to _a_ threads
library) loads/references the library, that library
uses the same threads library that the application is
linked to.
But threaded executables still need to be linked to
some threads library, and that should be selectable
via PTHREAD_LIBS.
--
Dan Eischen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
Steve Kargl wrote: Why? The portmgr can tag the ports collection at any point in time before or after the -pthread deprecation date. Steve, ports-freeze dates are set and published ahead of time just as dates for releases are. It's obviously not a good thing to have to try and be very conservative with commits to ports (in order to have a maximum number of them working for the next 4.x release) while at the same time there is loud demand for fixing a big number of them for -CURRENT. Don't bother telling me I'm whining, pointing at the handbook again and saying don't expect anything to work on -CURRENT at any given time, you're shooting the messenger. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
Daniel Eischen wrote: I feel that a FreeBSD that manages to break so many existing configure-scripts and build systems is degraded in usefulness. Please, this is -current. If you want less pain then stick with -stable and you won't be annoyed by the -pthread removal. Perhaps I should make it clear that, personally, I'm NOT very much annoyed. I know my way around in ports@, I actually do know what -CURRENT means and I have no problem with using the ports-collection exclusively instead of quickly compiling my own stuff right there in my user-account. The problem is just that this -CURRENT is supposed to be -STABLE rather soon, as we all know (I think the RE status for HEAD is 'Semi-Frozen', too). There are many users out there with 5.1-Release installed which have at best only a very distant clue about the fact they're running an early adopter's release and they won't be upgrading to 4.9-R or 4.10-R when the time arrives. For someone coming from 5.0-R or 5.1-R, the new necessary evil behaviour of cc/c++, be it -pedantic or -pthread, will be totally unexpected. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quo vadis, -CURRENT? (recent changes to cc compatibility)
On Thu, Sep 11, 2003 at 01:41:05AM +0200, Michael Nottebrock wrote:
Steve Kargl wrote:
Why? The portmgr can tag the ports collection at any point in
time before or after the -pthread deprecation date.
Steve, ports-freeze dates are set and published ahead of time just as dates
for releases are.
And the cvs tag can and has in the past been slid forward or
backwards when unforseen problems occur.
Don't bother telling me I'm whining, pointing at the handbook again and
saying don't expect anything to work on -CURRENT at any given time,
you're shooting the messenger.
If you want to use g++ -pedantic, do the following
cd $HOME
mkdir gcc
cd gcc
cvs -qz9 -d :pserver:[EMAIL PROTECTED]:/cvsroot/gcc update\
-r tree-ssa-20020619-branch -PAd gcc
cd ..
mkdir obj
cd obj
../gcc/configure --enable-languages=c,c++ --prefix=$HOME
gmake bootstrap
gmake install
troutmask:sgk[205] $HOME/bin/g++ -static -pedantic -o a a.cc
troutmask:sgk[206] a
hello world
troutmask:sgk[207] cat a.cc
#include iostream
int main(void) {
std::cout hello world\n;
return 0;
}
--
Steve
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
