This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: C++ script doesn't work using g++


 
Thanks Jeremy and yes, in the message I forgot to put the  and  respectively, but my script has them and however it doesn't work. I now know cygwin doesn't support borland c++, and thanks for the posts about it. I have to start working under c++ now! more interesting and wonderful work :).
 

Gery Herbozo Jimenez wrote:
>
> I have a simple script:
>
> #include
> #include
> int main()
> {
> clrscr();
> cout<<"Hallo";
> getch();
> }

It looks like your include statements are missing what they are supposed
to include. I made a guess that they should be as follows:

#include 
#include 

> However it doesn't work under this command:
>
> g++ hallo.cpp -o hallo.exe
>
> It gives:
>
> In file included from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/backward/iostream.h:31,
> from hallo.cpp:1:
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please
> consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the header for the header for C++ includes, or
> instead of the deprecated header . To disable this warning use -Wno-deprecated.
> hallo.cpp:2:19: conio.h: No such file or directory
> hallo.cpp: In function `int main()':
> hallo.cpp:6: error: `clrscr' undeclared (first use this function)
> hallo.cpp:6: error: (Each undeclared identifier is reported only once for each function it appears in.)
> hallo.cpp:8: error: `getch' undeclared (first use this function)
>
> Someone knows why? I tested it under borland c++ (v.5) in windows and works perfectly.
>
> Any hint is grateful.

It's been a decade since I last used any significant C++, but it appears
that conio.h is missing. Googling around tells me that conio is a
Borland extension, so it probably won't be available by default for g++.
There appears to be a SourceForge project to provide an equivalent for
MinGW however:

http://conio.sourceforge.net/

This blog post looks like it might also be helpful:

http://www.technology-included.co.cc/2009/05/conioh-on-gcc-linux.html

The file it instructs you to download doesn't work for me with g++ under
Cygwin though. It causes the compiler to report a bunch of errors.
Maybe you'll have better luck.

-Jeremy


--Archivo adjunto de mensaje reenviado--
Date: Fri, 11 Sep 2009 20:04:19 +0000
From: gchicares@sbcglobal.net
To: cygwin@cygwin.com
Subject: Re: C++ script doesn't work using g++


On 2009-09-11 18:49Z, Gery Herbozo Jimenez wrote:
>
> int main()
> {
> clrscr();
> cout<<"Hallo";
> getch();
> }

This message:
http://www.cygwin.com/ml/cygwin/1999-09/msg00326.html
mentions the danger of mixing getch() with C++ streams,
and explains why Cygwin doesn't provide "conio.h".
Consider using ncurses instead.


--Archivo adjunto de mensaje reenviado--
Date: Sat, 12 Sep 2009 00:00:31 +0200
From: Christian.Franke@t-online.de
To: cygwin@cygwin.com
Subject: [1.7] binutils-2.19.51-1: ld -r bug ?


Testing build of grub 1.97 beta on Cygwin 1.7, I found that the grub
.mod files are much larger than on 1.5. The modules are build by 'ld -r'
(and later converted to ELF).

The root of the problem is that the binutils-2.19.51-1 ld behavior
differs from previous 1.5 binutils. The new ld increases the size of
each segment by the size of the previous segment. Bug?


Testcase:

$ cat segm.c
void text() { __asm__(".space 104"); }
char data[256] = "DATA";
const char rdata[16] = "RDATA";

$ gcc -c segm.c


cygwin-1.5:
$ cygcheck -f /bin/ld
binutils-20080624-2

$ ld -r -o segm-r5.o segm.o


cygwin-1.7:
$ cygcheck -f /bin/ld
binutils-2.19.51-1

$ ld -r -o segm-r7.o segm.o


$ size segm.o segm-*.o
text data bss dec hex filename
128 256 0 384 180 segm.o
128 256 0 384 180 segm-r5.o
512 384 400 1296 510 segm-r7.o


$ objdump -s segm-r*.o

segm-r5.o: file format pe-i386

Contents of section .text:
0000 5589e500 00000000 00000000 00000000 U...............
...
0060 00000000 00000000 0000005d c3909090 ...........]....
Contents of section .data:
0080 44415441 00000000 00000000 00000000 DATA............
...
0170 00000000 00000000 00000000 00000000 ................
Contents of section .rdata:
0180 52444154 41000000 00000000 00000000 RDATA...........

segm-r7.o: file format pe-i386

Contents of section .text:
0000 5589e500 00000000 00000000 00000000 U...............
...
0060 00000000 00000000 0000005d c3909090 ...........]....
Contents of section .data:
0000 00000000 00000000 00000000 00000000 ................
...
0080 44415441 00000000 00000000 00000000 DATA............
...
0170 00000000 00000000 00000000 00000000 ................
Contents of section .rdata:
0000 00000000 00000000 00000000 00000000 ................
...
0180 52444154 41000000 00000000 00000000 RDATA...........


There are no related changes in the builtin linker scripts (ld --verbose
-r).

Christian



--Archivo adjunto de mensaje reenviado--
Date: Sat, 12 Sep 2009 02:02:40 +0100
From: dave.korn.cygwin@googlemail.com
To: cygwin@cygwin.com
Subject: Re: [1.7] binutils-2.19.51-1: ld -r bug ?


Christian Franke wrote:
> Testing build of grub 1.97 beta on Cygwin 1.7, I found that the grub
> .mod files are much larger than on 1.5. The modules are build by 'ld -r'
> (and later converted to ELF).
>
> The root of the problem is that the binutils-2.19.51-1 ld behavior
> differs from previous 1.5 binutils. The new ld increases the size of
> each segment by the size of the previous segment. Bug?

Yes, it looks so. Thanks for the report, this is now tracked at

http://sourceware.org/bugzilla/show_bug.cgi?id=10634

cheers,
DaveK


--Archivo adjunto de mensaje reenviado--
Date: Sat, 12 Sep 2009 06:46:03 -0600
From: ebb9@byu.net
To: cygwin@cygwin.com
Subject: docbook-xml 4.5


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm getting these messages while building git, even though I have the
latest docbook-xml44 installed; is it time for the docbook-xml maintainer
to release docbook-xml45?

XMLTO git-archive.1
I/O error : Attempt to load network entity
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
/usr/src/git-1.6.4.2-1/build/Documentation/git-archive.xml:2: warning:
failed to load external entity
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd";
D DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd";


- --
Don't work too hard, make some time for fun as well!

Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqrmAsACgkQ84KuGfSFAYCXFACfUlVSqfT0hn7KF/1moltD3Bkj
dpgAoJzY4RnCHLICLs5VoT8cSe7UJ7cM
=CXBx
-----END PGP SIGNATURE-----
_________________________________________________________________
Hay tantos ordenadores como personas. ¡Descubre ahora cuál eres tú!
http://www.quepceres.com/

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]