Dave Korn wrote:
Might move to 4.3.3 while I'm doing it, and should I make -4 the default?
Oh, yes, yes!
Thanks,
Angelo.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.htm
Dave Korn wrote:
1.5 or 1.7?
I do not use 1.7.
uname -a
CYGWIN_NT-5.1 mypc 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
cygcheck ./test_program.exe
.\test_program.exe
C:\cygwin\bin\cygwin1.dll
C:\WINDOWS\system32\ADVAPI32.DLL
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\
--- Sab 14/3/09, Dave Korn ha scritto:
> Da: Dave Korn
> Oggetto: Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
> A:
> Data: Sabato 14 marzo 2009, 07:56
> Marco Atzeri wrote:
>
> > it seems a 1.7 specific fault. On cygwin 1.5 it works;
>
Marco Atzeri wrote:
> it seems a 1.7 specific fault. On cygwin 1.5 it works; I never checked
> before :-(
Odd! It fails for me on both. (You did update gcc-4 on *both* your
installations, right?)
> is it possible that Cygwin-1.7 is fooled by the not like-C standard output
> ?
>
> "GFORTRAN_
--- Sab 14/3/09, Dave Korn ha scritto:
> Da: Dave Korn
> Oggetto: Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
> A: cygwin@cygwin.com
> Data: Sabato 14 marzo 2009, 04:04
> Angelo Graziosi wrote:
> > Still continuing to test...
> >
> >
Angelo Graziosi wrote:
> Still continuing to test...
>
> Marco Atzeri wrote:
>> if I had ./test_program I see the output on the screen but
>>
>> ./test_program > test_output
>> leave test_output empty.
>
> If I build that tst case with:
>
> gfortran-4 test_program.F -o test_program
>
> then
>
Still continuing to test...
Marco Atzeri wrote:
if I had
./test_program
I see the output on the screen but
./test_program > test_output
leave test_output empty.
If I build that tst case with:
gfortran-4 test_program.F -o test_program
then
$ ./test_program.exe
SUCCESS
$ ./test_program.ex
Dave Korn wrote:
So I think you should check for a bug in the --disable-debug
configure option. ...it seems that the actual overall size of the
stripped exes should be pretty much the same betwen the two compilers
Indeed! I have flagged the thing to the Mrxvt guys.
Thanks a lot,
Angelo.
--
Un
Charles Wilson wrote:
> It looks like CC='gcc -static-libgcc' (or, in our case for now,
> -shared-libgcc and CXX='g++ -shared-libgcc -shared-libstdc++' etc) is the
> "solution".
Shouldn't need anything for CXX, as the default shared libstdc++ implies
shared libgcc:
dkad...@ubik /tmp/hw
$ g++
Yaakov (Cygwin/X) wrote:
> Dave Korn wrote:
>> Can you take this one upstream for us? LT really ought to know about these
>> two options, they're not even Cygwin-specific at all.
>
> Chuck would probably be a better candidate for that, as he works with
> them already.
No, not really. I've had
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dave Korn wrote:
> Can you take this one upstream for us? LT really ought to know about these
> two options, they're not even Cygwin-specific at all.
Chuck would probably be a better candidate for that, as he works with
them already.
Yaakov
---
Dave Korn wrote:
> Tim Prince wrote:
>>
>> http://sites.google.com/site/tprincesite/levine-callahan-dongarra-vectors
>
> gcc: f90_cputime.c: No such file or directory
> I notice you're compiling with -fopenmp; does removing it help any?
Sorry, all these months and no one ever missed those .c f
Angelo Graziosi wrote:
> Dave Korn wrote:
>
>> Can you show me the "objdump -h" output for both?
>
> It seems that here there is a problem. I have build with the same build
> script and without debug info, but, for what I can understand, with gcc4
> the debug info are still there. To reproduce:
Dave Korn wrote:
Can you show me the "objdump -h" output for both?
It seems that here there is a problem. I have build with the same build
script and without debug info, but, for what I can understand, with gcc4
the debug info are still there. To reproduce:
===
Dave Korn wrote:
> Marco Atzeri wrote:
>
>> It seems a problem of output redirection with dynamic
>> fortran library
Oh, another clue: it only affects stdout, not stderr-
ad...@ubik /tmp/fortran/hw
$ ./hw 1>&2 | cat
SUCCESS
ad...@ubik /tmp/fortran/hw
$ ./hw 2>&1 | cat
ad...@ubik /tmp/fortr
Marco Atzeri wrote:
> It seems a problem of output redirection with dynamic
> fortran library
> This did not happened with static linked fortran library.
I agree. If anyone has problems with this issue when using fortran, the
workaround for now will be to use "-static" when compiling.
c
--- Ven 13/3/09, Dave Korn ha scritto:
> Da: Dave Korn
> Oggetto: Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
> A:
> Data: Venerdì 13 marzo 2009, 07:41
> Tim Prince wrote:
> > This doesn't seem to be a magically fully working
> gfortran, such
Tim Prince wrote:
> Dave Korn wrote:
>> Tim Prince wrote:
>>> This doesn't seem to be a magically fully working gfortran, such as we
>>> had fleetingly with the 20090227 snapshot of 4.4.
>> Hi Tim, can you give me a bit of context here?
> I may not have known what to look for, Most 4.3 and
Yaakov (Cygwin/X) wrote:
>> Also, some 3PPs will get warm fuzzies from having one less DLL to
>> distribute, though it hardly makes the resulting executables any more
>> "standalone" ;-)
>
> Since when exactly do we care about 3PPs here? :-)
We don't, hence my smiley!
> Doesn't sound like
Dave Korn wrote:
> Tim Prince wrote:
>> This doesn't seem to be a magically fully working gfortran, such as we
>> had fleetingly with the 20090227 snapshot of 4.4. I'd agree it's likely
>> an "upstream" problem, even if it shows up only on cygwin.
>
> Hi Tim, can you give me a bit of context he
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
First, I must say, many thanks for all your hard work on gcc4!
Dave Korn wrote:
> No reason that I can think of in general. The only case would be when you
> really need to override intra-libstdc++ calls to operators new and delete, in
> which ca
Yaakov (Cygwin/X) wrote:
> Dave Korn wrote:
>> Plain C applications will, by default, be linked statically against libgcc as
>> previously. To link against the shared libgcc DLL, '-shared-libgcc' must be
>> manually specified on the command-line.
>
> 1) What exactly are the pros and cons of this
Tim Prince wrote:
> This doesn't seem to be a magically fully working gfortran, such as we
> had fleetingly with the 20090227 snapshot of 4.4. I'd agree it's likely
> an "upstream" problem, even if it shows up only on cygwin.
Hi Tim, can you give me a bit of context here? I don't know what sor
Angelo Graziosi wrote:
> For completeness I want to flag that, for mrxvt, mrxvt.exe has a size
> which is double respect with the case when Mrxvt is build with GCC-3.4.4.
Stripped or unstripped? Can you show me the "objdump -h" output for both?
DW2 debug (now default over stabs) is pretty b
On Thu, 12 Mar 2009, Dave Korn wrote:
>
> Indeed it did. With the attached patch, build and test both ran to
> completion without any errors.
Indeed!
Now ROOT and its tests build fine... and also the following applications
build fine:
Cernlib 2006, TeXLive-SVN, Emacs-CVS, Mrxvt-398-svn.
F
This doesn't seem to be a magically fully working gfortran, such as we
had fleetingly with the 20090227 snapshot of 4.4. I'd agree it's likely
an "upstream" problem, even if it shows up only on cygwin.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dave Korn wrote:
> Plain C applications will, by default, be linked statically against libgcc as
> previously. To link against the shared libgcc DLL, '-shared-libgcc' must be
> manually specified on the command-line.
1) What exactly are the pros an
Dave Korn wrote:
> [the same post twice]
Oops, sorry all, MTA glitch.
cheers,
DaveK
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: htt
[Bcc's sent to interested third parties]
Dave Korn wrote:
> And the immediate reason for this is the way that TSystem.o is built:
>
> build.log
> g++-4 -O2 -pipe -Wall -Woverloaded-virtual -D_DLL -Iinclude
> -I/usr/X11R6/include -o core/
Peter Rosin wrote:
> Den 2009-03-12 18:01 skrev Dave Korn:
>> Hmmm, I may have misunderstood that. Does -D_DLL mean something
>> special to MSVC, does anyone know?
>
> When you compile with shared libc on MSVC (e.g. -MD), it defines _DLL
> for you.
Ah, thanks. So it's used for internal com
Den 2009-03-12 18:01 skrev Dave Korn:
Dave Korn wrote:
Why is a -D for _DLL present? That is a reserved definition in the
implementation's namespace,
Hmmm, I may have misunderstood that. Does -D_DLL mean something special to
MSVC, does anyone know?
When you compile with shared libc o
Dave Korn wrote:
> Why is a -D for _DLL present? That is a reserved definition in the
> implementation's namespace,
Hmmm, I may have misunderstood that. Does -D_DLL mean something special to
MSVC, does anyone know?
cheers,
DaveK
--
Unsubscribe info: http://cygwin.com/ml/#u
Dave Korn wrote:
> Ok, for some reason it appears that libCore.dll.a exports symbols from
> libstdc++:
>
> dkad...@ubik /work/root/test $ nm /work/root/lib/libCore.dll.a |grep
> St9exception 71d6b958 d .rdata$_ZTISt9exception 71d6ff40 d
> .rdata$_ZTSSt9exception 71d6b958 D __ZTISt9exception 7
Angelo Graziosi wrote:
> To test this new version of the compiler I have rebuild ROOT [1]. It
> builds fine, but when I try to build its tests, at least one fails in
> linking:
> d37.o:(.idata$5+0x0): multiple definition of `__imp___ZTISt9exception'
> /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc+
Angelo Graziosi wrote:
> To test this new version of the compiler I have rebuild ROOT [1]. It
> builds fine, but when I try to build its tests, at least one fails in
> linking:
Thanks for the report, I'm looking into it.
cheers,
DaveK
--
Unsubscribe info: http://cygwin.com/ml/#
To test this new version of the compiler I have rebuild ROOT [1]. It
builds fine, but when I try to build its tests, at least one fails in
linking:
---
[... many build fine ...]
g++-4 -O -pipe -Wall -Woverloaded-virtual -I/usr/X11R6/include
-D_REENTRANT -I/work/r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have just uploaded an updated GCC-4 package to cygwin.com. It will be
arriving at your favourite mirror next time it synchronizes itself with the
official Cygwin repository.
This is a major update to the Cygwin toolchain. It introduces a ful
37 matches
Mail list logo
