Re: -pthread support
Hi Ian, Thanks for your reply. This question is appropriate for [EMAIL PROTECTED], not for [EMAIL PROTECTED] Please send any follow-ups to gcc-help. Thanks. I will send to gcc-help. Cheers Maggie
Re: Ada rts fails to build on ppc?
On 9/17/07, Eric Botcazou <[EMAIL PROTECTED]> wrote: > > It's actually powerpc configured like > > > > ../configure --with-cpu=default32 --build=powerpc64-suse-linux > > checking build system type... powerpc64-suse-linux-gnu > > checking host system type... powerpc64-suse-linux-gnu > > checking target system type... powerpc64-suse-linux-gnu > > Looks like > > 2007-08-31 Ben Elliston <[EMAIL PROTECTED]> > > * Makefile.in (LIBGNAT_TARGET_PAIRS): Use system-linux-ppc64.ads > when compiling for powerpc64-*-linux. > * system-linux-ppc64.ads: New file. > > needs to be refined. I have filed PR33657 for this. Richard.
RE: Make/bootstrap failure on i386-apple-darwin8.10.1 (Intel Core Duo)
On 04 October 2007 00:58, Ian Lance Taylor wrote:
> Jack Howarth <[EMAIL PROTECTED]> writes:
>
>>Why should using a Canadian Cross suddenly break on
>> Mac OS X? We have been using --host when building gcc
>> packages in fink on Mac OS X for ages and it has never
>> been a problem. I would think this should become a PR
>> if gcc trunk has regressed on this issue.
>> Jack
>> ps For example, see...
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00847.html
>
> The change in behaviour is due to changing the top level configure
> script from using autoconf 2.13 to autoconf 2.59. With autoconf 2.59,
> if you want to build a normal package--one that will run on the
> machine on which you are doing the build--and you want to say which
> host to build it for, you must use --build, not --host.
Could you just repeat that once more, slowly, for those of us who are a bit
hard-of-thinking? I'm not quite clear about how, if you're building a normal
package, i.e. one that runs on the build machine, why you'd need to tell it
"which host to build it for" at all, since the answer, by definition, is "this
one".
I always thought that if you want to build a "normal" package, i.e. one that
"will run on the machine on which you are doing the build" - what I've always
referred to as "a native build", you simply don't specify anything at all
(well, don't specify any of the --{build,host,target} trio, to be exact).
But yeh, I get the part about how it now assumes that if you're specifying a
--host, you must be doing a cross-build, because if --host was the same as
--build, you wouldn't specify either ...
cheers,
DaveK
--
Can't think of a witty .sigline today
Non-blocking read too slow on file/serial stream
dear all, I am doing a 'read' operation on a non-blocking FILE stream attached to the serial port. Every non-empty read (about 120 bytes) is performed in less than 200 us. However, if no data in buffer, read returns -1 but the operation takes 1500 us or more in average. Too much for my application... Any explanation? Any workaround? Best regards Jesús Spain
Re: [RFC,wwwdocs] Ditch MetaHTML and use our own Perl preprocessor
ping? Gerald, being web pages maintainers, what's your opinion? Answering to Janne's comment, I'm certainly not opposed to any preprocessor/templating system. My own goal is to rewrite the fortran pages, including the common navigation bar, and I can't use MetaHTML to do that. On 9/29/07, FX Coudert <[EMAIL PROTECTED]> wrote: > Hi, > > I am in the process of rewriting the Fortran part of our website > (http://gcc.gnu.org/), part of which consists of adding the GCC > navigation bar. To do so, I had to install localy MetaHTML, our > current web preprocessor, and my experiences with it have left me > less than impressed [1]. We currently use it for including headers > and footer, making them depend on whether we are preprocessing HTML > or XHTML, modifying in place a few tags (, , ) and > adding navigation bar on files that need it. This can easily be done > by a simple preprocessing script, and seeing that MetaHTML was last > released 1999 and apparently unsupported since then, I suggest that > we do this move right now. > > This patch includes the new preprocessor, changes to the script, and > quite a few new files (footer, navigation bars, etc.) split from the > MetaHTML file, style.mhtml. I chose to write the preprocessor script > in Perl, since Perl is already used for the wwwdocs/bin/preprocess > script, so I'm sure it will be available on the webserver. The > preprocessor does what MetaHTML was needed, but it can be extended in > the future if we need more functionality. Also, we can in the future > offload some of its work, such as and modifications and > part of the navigation bar to CSS, which is obviously better suited > for the job. I intend to do so as a follow-up to the preprocessor > change, if/when it is accepted. > > This change shouldn't change the website, but I can't check since I > don't have MetaHTML, so I'd appreciate if someone with shell access > to the webserver could check it. Oh, there is one thing that I > changed: the detailled search page, http://gcc.gnu.org/search.html, > currently has a "Database last updated -MM-DD" line that doesn't > work (it displays "1900--"), so I removed it. > > Comments are highly welcome, both on the idea itself, and on the Perl > script (my Perl is a bit rusty since I haven't used it for years). > > Thanks, > FX > > > [1] As a record, here's what my "final" status is: in addition to > Gerald's patch and script provided by Joel Sherrill (thanks guys), I > needed to patch of few more (~ 15) occurences of multilines strings, > force the Makefiles to use the version of readline included in > metahtml instead of the system one (too recent, apparently there's > been an ABI change), and tweak the Makefiles for the shared modules, > which aren't portable (at least, not to Mac OS). As of yesterday, > I've managed to compile it, but the resulting binary acts as an > endless cpu-consuming loop. At that point, I gave up.
RE: Non-blocking read too slow on file/serial stream
On 04 October 2007 16:02, Jesús wrote: > dear all, > > I am doing a 'read' operation on a non-blocking FILE stream attached to > the serial port. > Every non-empty read (about 120 bytes) is performed in less than 200 us. > However, if no data in buffer, read returns -1 but the operation takes > 1500 us or more in average. Too much for my application... > > Any explanation? > Any workaround? > > Best regards > Jesús > Spain Hi Jesús, Please send this query to the gcc-help list, instead of this one. This list is about programming the internals of the gcc compiler itself; the gcc-help list is for help using the compiler and programming /with/ it. (Also, when you re-send your post, add some details about what computer and operating system you're using. And you might want to google "O_NONBLOCK" while you're waiting for a reply...) cheers, DaveK -- Can't think of a witty .sigline today
Re: Make/bootstrap failure on i386-apple-darwin8.10.1 (Intel Core Duo)
"Dave Korn" <[EMAIL PROTECTED]> writes:
> I always thought that if you want to build a "normal" package, i.e. one that
> "will run on the machine on which you are doing the build" - what I've always
> referred to as "a native build", you simply don't specify anything at all
> (well, don't specify any of the --{build,host,target} trio, to be exact).
Yes. Unless you need to specify the specific OS version you want to
build for.
> But yeh, I get the part about how it now assumes that if you're specifying a
> --host, you must be doing a cross-build, because if --host was the same as
> --build, you wouldn't specify either ...
Yes. That is new autoconf behaviour with 2.59.
Ian
Re: Make/bootstrap failure on i386-apple-darwin8.10.1 (Intel Core Duo)
Dave,
Actually the usage of --host in the fink gcc packaging predates
my ownership of it. I believe the fact that Apple configures their
gcc builds with...
--build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
--target=powerpc-apple-darwin8
...may have been the motivator. This actually will be trival to fix since we
will
just change the egrep command we use to parse out the --host field from the
output
of 'cc -v' to parse out the --build field instead. On Macintel, I think the
usage
of --host was also meant to insure that gcc was built for i686-apple-darwin8
instead
of i386-apple-darwin8.
Jack
On Thu, Oct 04, 2007 at 03:25:45PM +0100, Dave Korn wrote:
>
> Could you just repeat that once more, slowly, for those of us who are a bit
> hard-of-thinking? I'm not quite clear about how, if you're building a normal
> package, i.e. one that runs on the build machine, why you'd need to tell it
> "which host to build it for" at all, since the answer, by definition, is "this
> one".
>
> I always thought that if you want to build a "normal" package, i.e. one that
> "will run on the machine on which you are doing the build" - what I've always
> referred to as "a native build", you simply don't specify anything at all
> (well, don't specify any of the --{build,host,target} trio, to be exact).
>
> But yeh, I get the part about how it now assumes that if you're specifying a
> --host, you must be doing a cross-build, because if --host was the same as
> --build, you wouldn't specify either ...
>
>
> cheers,
> DaveK
> --
> Can't think of a witty .sigline today
Downloading GCC
How do I go about downloading GCC. Which files do I need to download and how can I run a .tar file. Thanks for the help.
Re: Downloading GCC
> How do I go about downloading GCC. Which files do I need to download and > how > can I run a .tar file. Thanks for the help. I'll try to help you here. One of the big problems with the open source world is that it can be tough to get started when you don't know .. much of anything about it. So then .. what OS are you running there ? oh .. also we may need to go to a different mailist. Dennis
How to run testsuite without building a complier
Hello all, I want to know whether its possible to run the gcc testsuite without actually building the complier. I have the dejagnu framework, compiler executables and i have the gcc test suite. So is it possible to run the testsuite without building the complier? Regards, Shafi
Re: How to run testsuite without building a complier
Mohamed Shafi wrote: > I want to know whether its possible to run the gcc testsuite without > actually building the complier. > > I have the dejagnu framework, compiler executables and i have the gcc > test suite. So is it possible to run the testsuite without building > the complier? Use the contrib/test_installed script. Brian
