Re: [g...@wooledge.org: Re: Fw: locating blocked port]
On 2023-02-04, Haines Brown wrote: > - Forwarded message from Greg Wooledge - > > Date: Thu, 2 Feb 2023 08:57:30 -0500 > From: Greg Wooledge > To: debian-user@lists.debian.org > Subject: Re: Fw: locating blocked port > > I finally managed to get jabref to run. > Your first post's terminal ouput: Arguments passed on to running JabRef instance. Shutting down. *** So as some poor soul who was ignored already pointed out, I'm afraid the problem as well as its solution was manifest from the very beginning.
Re: g++ can't build "Hello World" programm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Oct 19, 2017 at 02:01:18AM +0600, Evgeny wrote: > Problems gone when i reinstalled libc6-dev, now hello world compiling fine, > but the problem is that after removing lib6c-dev a lot of other packages > was deleted and when I trying to install them back I have error (Unable to > correct problems, you have held broken packages) Phew :-) You might try apt-get -s install --fix-broken (the -s is for "simulate": then you can see what apt-get would do. You don't need sudo while simulating). If you like what the system proposes, then sudo apt-get install --fix-broken > Anyway, thanks a lot, I finally figured it out Glad you found it! Cheers - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlnnuf8ACgkQBcgs9XrR2kZaXgCfTrOwIWGgJ2z/B16EZsfelSX0 q0sAoIEEilHIiTIRjMDdReDpNvG96ovG =nlbf -END PGP SIGNATURE-
Re: g++ can't build "Hello World" programm
Hi, Evgeny wrote: > any > "bits/locale.h" among indlude files that you listed have already existed in > my system. but g++ continue give me error message that there is no such file > or directory What do you get from g++ -o test -H test.cpp If i rename my local /usr/include/x86_64-linux-gnu/bits/locale.h then i get exactly your error message: ... /usr/include/locale.h /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stddef.h In file included from /usr/include/c++/4.9/clocale:42:0, from /usr/include/x86_64-linux-gnu/c++/4.9/bits/c++locale.h:41, from /usr/include/c++/4.9/bits/localefwd.h:40, from /usr/include/c++/4.9/ios:41, from /usr/include/c++/4.9/ostream:38, from /usr/include/c++/4.9/iostream:39, from test.cpp:1: /usr/include/locale.h:29:25: fatal error: bits/locale.h: No such file or directory My g++ version is like yours g++ (Debian 4.9.2-10) 4.9.2 > -I/way-to-the-missing-lib, The path up to but not including "bits" idid not help ? Like: -I /usr/include/x86_64-linux-gnu/ > What can it be? Is the the file name invisibly altered ? What do you get when explicitely asking for its path: ls -ld '/usr/include/x86_64-linux-gnu/bits/locale.h' Have a nice day :) Thomas
Re: g++ can't build "Hello World" programm
Problems gone when i reinstalled libc6-dev, now hello world compiling fine, but the problem is that after removing lib6c-dev a lot of other packages was deleted and when I trying to install them back I have error (Unable to correct problems, you have held broken packages) Anyway, thanks a lot, I finally figured it out 2017-10-19 1:20 GMT+06:00 : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thu, Oct 19, 2017 at 01:04:05AM +0600, Evgeny wrote: > > Thanks all for answers, libc6-dev was installed. And more intresting, any > > "bits/locale.h" among indlude files that you listed have already existed > in > > my system. but g++ continue give me error message that there is no such > > file or directory > > > > even if I use -I/usr/include/x86_64-linux-gnu/ flag or add directory in > > cmake include directories > > > > What can it be? > > Strange. I'd try to eliminate actors one by one. What happens if you bypass > cmake and call g++ directly? > > Another approach is to call g++ under strace and see what files it tries > to open (caution: this will produce copious output: use the -o option > to let strace write to a file, and the -f option to follow the process > forks, I'd expect g++ to spawn quite a few subprocesses). > > Or just re-install g++ and all the "interesting" libs: likely there's > something broken in your setup. > > Are you sure you're calling the g++ you think you are calling? > > Cheers > - -- tomás > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > > iEYEARECAAYFAlnnqYUACgkQBcgs9XrR2kaTsQCeJFZ7BLtE7yquaj7sxrIMGGWQ > mjUAn2bvDioeqkd4JcbG/VgGTLH6Gdu4 > =O6jp > -END PGP SIGNATURE- >
Re: g++ can't build "Hello World" programm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Oct 19, 2017 at 01:04:05AM +0600, Evgeny wrote: > Thanks all for answers, libc6-dev was installed. And more intresting, any > "bits/locale.h" among indlude files that you listed have already existed in > my system. but g++ continue give me error message that there is no such > file or directory > > even if I use -I/usr/include/x86_64-linux-gnu/ flag or add directory in > cmake include directories > > What can it be? Strange. I'd try to eliminate actors one by one. What happens if you bypass cmake and call g++ directly? Another approach is to call g++ under strace and see what files it tries to open (caution: this will produce copious output: use the -o option to let strace write to a file, and the -f option to follow the process forks, I'd expect g++ to spawn quite a few subprocesses). Or just re-install g++ and all the "interesting" libs: likely there's something broken in your setup. Are you sure you're calling the g++ you think you are calling? Cheers - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlnnqYUACgkQBcgs9XrR2kaTsQCeJFZ7BLtE7yquaj7sxrIMGGWQ mjUAn2bvDioeqkd4JcbG/VgGTLH6Gdu4 =O6jp -END PGP SIGNATURE-
Re: g++ can't build "Hello World" programm
On Thu, Oct 19, 2017 at 01:04:05AM +0600, Evgeny wrote: > Thanks all for answers, libc6-dev was installed. And more intresting, any > "bits/locale.h" among indlude files that you listed have already existed in > my system. but g++ continue give me error message that there is no such > file or directory You need more than libc6-dev for C++ programs. There are C++ specific library packages. Installing build-essential should be your first step.
Re: g++ can't build "Hello World" programm
Thanks all for answers, libc6-dev was installed. And more intresting, any "bits/locale.h" among indlude files that you listed have already existed in my system. but g++ continue give me error message that there is no such file or directory even if I use -I/usr/include/x86_64-linux-gnu/ flag or add directory in cmake include directories What can it be? 2017-10-13 20:42 GMT+06:00 Thomas Schmitt : > Hi, > > i can compile the test program on my amd64 Debian 8. > > Google and > https://stackoverflow.com/questions/5834778/how-to-tell- > where-a-header-file-is-included-from > caused me to run > > $ g++ -H test.cpp > > to see all included files. > Maybe it helps you to find what's missing on your system or where > your local include empire derails: > > . /usr/include/c++/4.9/iostream > .. /usr/include/x86_64-linux-gnu/c++/4.9/bits/c++config.h > ... /usr/include/x86_64-linux-gnu/c++/4.9/bits/os_defines.h > /usr/include/features.h > . /usr/include/x86_64-linux-gnu/sys/cdefs.h > .. /usr/include/x86_64-linux-gnu/bits/wordsize.h > . /usr/include/x86_64-linux-gnu/gnu/stubs.h > .. /usr/include/x86_64-linux-gnu/gnu/stubs-64.h > ... /usr/include/x86_64-linux-gnu/c++/4.9/bits/cpu_defines.h > .. /usr/include/c++/4.9/ostream > ... /usr/include/c++/4.9/ios > /usr/include/c++/4.9/iosfwd > . /usr/include/c++/4.9/bits/stringfwd.h > .. /usr/include/c++/4.9/bits/memoryfwd.h > . /usr/include/c++/4.9/bits/postypes.h > .. /usr/include/c++/4.9/cwchar > ... /usr/include/wchar.h > /usr/include/stdio.h > /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stdarg.h > /usr/include/x86_64-linux-gnu/bits/wchar.h > /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stddef.h > /usr/include/xlocale.h > /usr/include/c++/4.9/exception > . /usr/include/c++/4.9/bits/atomic_lockfree_defines.h > /usr/include/c++/4.9/bits/char_traits.h > . /usr/include/c++/4.9/bits/stl_algobase.h > .. /usr/include/c++/4.9/bits/functexcept.h > ... /usr/include/c++/4.9/bits/exception_defines.h > .. /usr/include/c++/4.9/bits/cpp_type_traits.h > .. /usr/include/c++/4.9/ext/type_traits.h > .. /usr/include/c++/4.9/ext/numeric_traits.h > .. /usr/include/c++/4.9/bits/stl_pair.h > ... /usr/include/c++/4.9/bits/move.h > /usr/include/c++/4.9/bits/concept_check.h > .. /usr/include/c++/4.9/bits/stl_iterator_base_types.h > .. /usr/include/c++/4.9/bits/stl_iterator_base_funcs.h > ... /usr/include/c++/4.9/debug/debug.h > .. /usr/include/c++/4.9/bits/stl_iterator.h > ... /usr/include/c++/4.9/bits/ptr_traits.h > .. /usr/include/c++/4.9/bits/predefined_ops.h > . /usr/include/c++/4.9/cwchar > .. /usr/include/wchar.h > /usr/include/c++/4.9/bits/localefwd.h > . /usr/include/x86_64-linux-gnu/c++/4.9/bits/c++locale.h > .. /usr/include/c++/4.9/clocale > ... /usr/include/locale.h > /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stddef.h > /usr/include/x86_64-linux-gnu/bits/locale.h > . /usr/include/c++/4.9/cctype > .. /usr/include/ctype.h > ... /usr/include/x86_64-linux-gnu/bits/types.h > /usr/include/x86_64-linux-gnu/bits/wordsize.h > /usr/include/x86_64-linux-gnu/bits/typesizes.h > ... /usr/include/endian.h > /usr/include/x86_64-linux-gnu/bits/endian.h > /usr/include/x86_64-linux-gnu/bits/byteswap.h > . /usr/include/x86_64-linux-gnu/bits/wordsize.h > . /usr/include/x86_64-linux-gnu/bits/byteswap-16.h > /usr/include/c++/4.9/bits/ios_base.h > . /usr/include/c++/4.9/ext/atomicity.h > .. /usr/include/x86_64-linux-gnu/c++/4.9/bits/gthr.h > ... /usr/include/x86_64-linux-gnu/c++/4.9/bits/gthr-default.h > /usr/include/pthread.h > . /usr/include/sched.h > .. /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stddef.h > .. /usr/include/time.h > .. /usr/include/x86_64-linux-gnu/bits/sched.h > . /usr/include/time.h > .. /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stddef.h > .. /usr/include/x86_64-linux-gnu/bits/time.h > ... /usr/include/x86_64-linux-gnu/bits/timex.h > . /usr/include/x86_64-linux-gnu/bits/pthreadtypes.h > .. /usr/include/x86_64-linux-gnu/bits/wordsize.h > . /usr/include/x86_64-linux-gnu/bits/setjmp.h > .. /usr/include/x86_64-linux-gnu/bits/wordsize.h > . /usr/include/x86_64-linux-gnu/bits/wordsize.h > .. /usr/include/x86_64-linux-gnu/c++/4.9/bits/atomic_word.h > . /usr/include/c++/4.9/bits/locale_classes.h > .. /usr/include/c++/4.9/string > ... /usr/include/c++/4.9/bits/allocator.h > /usr/include/x86_64-linux-gnu/c++/4.9/bits/c++allocator.h > . /usr/include/c++/4.9/ext/new_allocator.h > .. /usr/include/c++/4.
Re: g++ can't build "Hello World" programm
Hi, i can compile the test program on my amd64 Debian 8. Google and https://stackoverflow.com/questions/5834778/how-to-tell-where-a-header-file-is-included-from caused me to run $ g++ -H test.cpp to see all included files. Maybe it helps you to find what's missing on your system or where your local include empire derails: . /usr/include/c++/4.9/iostream .. /usr/include/x86_64-linux-gnu/c++/4.9/bits/c++config.h ... /usr/include/x86_64-linux-gnu/c++/4.9/bits/os_defines.h /usr/include/features.h . /usr/include/x86_64-linux-gnu/sys/cdefs.h .. /usr/include/x86_64-linux-gnu/bits/wordsize.h . /usr/include/x86_64-linux-gnu/gnu/stubs.h .. /usr/include/x86_64-linux-gnu/gnu/stubs-64.h ... /usr/include/x86_64-linux-gnu/c++/4.9/bits/cpu_defines.h .. /usr/include/c++/4.9/ostream ... /usr/include/c++/4.9/ios /usr/include/c++/4.9/iosfwd . /usr/include/c++/4.9/bits/stringfwd.h .. /usr/include/c++/4.9/bits/memoryfwd.h . /usr/include/c++/4.9/bits/postypes.h .. /usr/include/c++/4.9/cwchar ... /usr/include/wchar.h /usr/include/stdio.h /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stdarg.h /usr/include/x86_64-linux-gnu/bits/wchar.h /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stddef.h /usr/include/xlocale.h /usr/include/c++/4.9/exception . /usr/include/c++/4.9/bits/atomic_lockfree_defines.h /usr/include/c++/4.9/bits/char_traits.h . /usr/include/c++/4.9/bits/stl_algobase.h .. /usr/include/c++/4.9/bits/functexcept.h ... /usr/include/c++/4.9/bits/exception_defines.h .. /usr/include/c++/4.9/bits/cpp_type_traits.h .. /usr/include/c++/4.9/ext/type_traits.h .. /usr/include/c++/4.9/ext/numeric_traits.h .. /usr/include/c++/4.9/bits/stl_pair.h ... /usr/include/c++/4.9/bits/move.h /usr/include/c++/4.9/bits/concept_check.h .. /usr/include/c++/4.9/bits/stl_iterator_base_types.h .. /usr/include/c++/4.9/bits/stl_iterator_base_funcs.h ... /usr/include/c++/4.9/debug/debug.h .. /usr/include/c++/4.9/bits/stl_iterator.h ... /usr/include/c++/4.9/bits/ptr_traits.h .. /usr/include/c++/4.9/bits/predefined_ops.h . /usr/include/c++/4.9/cwchar .. /usr/include/wchar.h /usr/include/c++/4.9/bits/localefwd.h . /usr/include/x86_64-linux-gnu/c++/4.9/bits/c++locale.h .. /usr/include/c++/4.9/clocale ... /usr/include/locale.h /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stddef.h /usr/include/x86_64-linux-gnu/bits/locale.h . /usr/include/c++/4.9/cctype .. /usr/include/ctype.h ... /usr/include/x86_64-linux-gnu/bits/types.h /usr/include/x86_64-linux-gnu/bits/wordsize.h /usr/include/x86_64-linux-gnu/bits/typesizes.h ... /usr/include/endian.h /usr/include/x86_64-linux-gnu/bits/endian.h /usr/include/x86_64-linux-gnu/bits/byteswap.h . /usr/include/x86_64-linux-gnu/bits/wordsize.h . /usr/include/x86_64-linux-gnu/bits/byteswap-16.h /usr/include/c++/4.9/bits/ios_base.h . /usr/include/c++/4.9/ext/atomicity.h .. /usr/include/x86_64-linux-gnu/c++/4.9/bits/gthr.h ... /usr/include/x86_64-linux-gnu/c++/4.9/bits/gthr-default.h /usr/include/pthread.h . /usr/include/sched.h .. /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stddef.h .. /usr/include/time.h .. /usr/include/x86_64-linux-gnu/bits/sched.h . /usr/include/time.h .. /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stddef.h .. /usr/include/x86_64-linux-gnu/bits/time.h ... /usr/include/x86_64-linux-gnu/bits/timex.h . /usr/include/x86_64-linux-gnu/bits/pthreadtypes.h .. /usr/include/x86_64-linux-gnu/bits/wordsize.h . /usr/include/x86_64-linux-gnu/bits/setjmp.h .. /usr/include/x86_64-linux-gnu/bits/wordsize.h . /usr/include/x86_64-linux-gnu/bits/wordsize.h .. /usr/include/x86_64-linux-gnu/c++/4.9/bits/atomic_word.h . /usr/include/c++/4.9/bits/locale_classes.h .. /usr/include/c++/4.9/string ... /usr/include/c++/4.9/bits/allocator.h /usr/include/x86_64-linux-gnu/c++/4.9/bits/c++allocator.h . /usr/include/c++/4.9/ext/new_allocator.h .. /usr/include/c++/4.9/new ... /usr/include/c++/4.9/bits/ostream_insert.h /usr/include/c++/4.9/bits/cxxabi_forced.h ... /usr/include/c++/4.9/bits/stl_function.h /usr/include/c++/4.9/backward/binders.h ... /usr/include/c++/4.9/bits/range_access.h ... /usr/include/c++/4.9/bits/basic_string.h ... /usr/include/c++/4.9/bits/basic_string.tcc .. /usr/include/c++/4.9/bits/locale_classes.tcc /usr/include/c++/4.9/streambuf . /usr/include/c++/4.9/bits/streambuf.tcc /usr/include/c++/4.9/bits/basic_ios.h . /usr/include/c++/4.9/bits/loca
Re: g++ can't build "Hello World" programm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Oct 13, 2017 at 09:17:32AM -0400, Greg Wooledge wrote: > On Fri, Oct 13, 2017 at 07:11:28PM +0600, Evgeny wrote: > > error: bits/locale.h: No such file or directory > > Make sure build-essential is installed. > > > #include > > ^ > > compilation terminated. > > Make sure the file uses Unix newline (line feed) terminators, and not > Microsoft's CR-LF terminators. This is a good point too! But a quick test on my box seems to suggest that GCC just doesn't care. It seems to treat CR as normal whitespace. A minimal hello world stored with DOS line endings compiles and runs fine. Cheers - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlngv7AACgkQBcgs9XrR2kaangCdGYtdKyykz6xmV02eZMj/YgJl lYkAn3lVxeogfaaNXh/Ar34ZqgRFndaW =yWxe -END PGP SIGNATURE-
Re: g++ can't build "Hello World" programm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Oct 13, 2017 at 07:11:28PM +0600, Evgeny wrote:
> Dear all, i have some problems with , etc. libraries on
> my debian.
>
> I have pretty simple code:
>
> #include
>
> using namespace std;
>
> int main(void) {
>
> cout << "Hello World!" << endl;
> return 0;
> }
>
> And when i try to compile it, compiler gives me error:
>
> evgeny@debian:~/Documents/Programming$ g++ test.cpp -o testIn file
> included from /usr/include/c++/4.9/clocale:42:0,
> from
> /usr/include/x86_64-linux-gnu/c++/4.9/32/bits/c++locale.h:41,
> from /usr/include/c++/4.9/bits/localefwd.h:40,
> from /usr/include/c++/4.9/ios:41,
> from /usr/include/c++/4.9/ostream:38,
> from /usr/include/c++/4.9/iostream:39,
> from test.cpp:1:/usr/include/locale.h:29:25: fatal
> error: bits/locale.h: No such file or directory
> #include
> ^
> compilation terminated.
Seems the compiler doesn't find /usr/include/bits/locale.h. Is that
file there? (if you have multi-arch support (I guess you have( it will
be in /usr/include//bits/locale.h, where is the architecture
you're compiling for, e.g. "x86_64-linux-gnu" or "arm-linux-gnueabihf"
or something similar).
This file comes with libc6-dev. I didn't see that one in the list
you provided, but I may have missed it.
Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlngvngACgkQBcgs9XrR2kazMwCfbUrYGL2F/EPj1ufcTMLEyWnI
fW0An0Q+fOGF1ShnC1VHWfYKYm16exCw
=Y+5x
-END PGP SIGNATURE-
Re: g++ can't build "Hello World" programm
On Fri, Oct 13, 2017 at 07:11:28PM +0600, Evgeny wrote: > error: bits/locale.h: No such file or directory Make sure build-essential is installed. > #include > ^ > compilation terminated. Make sure the file uses Unix newline (line feed) terminators, and not Microsoft's CR-LF terminators. (Though it's probably the missing packages.)
Re: g++ missing
Marc Auslander <[EMAIL PROTECTED]> writes: > A while ago I upgraded to etch from sarge. I now discover the g++ is > missing. aptitude doesn't show the package. my sources.list points > at ... My dumb mistake. aptitude search appears to be reg exp, so searching for g++ doesn't work! Search for g\+\+ finds it. sigh. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: g++ missing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/31/08 16:43, Marc Auslander wrote: > A while ago I upgraded to etch from sarge. I now discover the g++ is > missing. aptitude doesn't show the package. my sources.list points > at > > deb http://ftp.us.debian.org/debian/ etch main > deb-src http://ftp.us.debian.org/debian/ etch main > > deb http://security.debian.org/ etch/updates main > > > what am I doing wrong? Try this, and send us the results. $ apt-cache search g++ | grep g++ | sort - -- Ron Johnson, Jr. Jefferson LA USA PETA - People Eating Tasty Animals -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHol5QS9HxQb37XmcRAukLAJ0UQaq9FUP3XXaM7yk1eNM6VQrHNgCfaOUt 8/OQZjXHhxXLTPtvhG5C5/A= =oyfO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: g++ problem - Thanks
Thanks - I was just out of date. It works now. Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: g++ problem
On 2/8/06, Thomas H. George <[EMAIL PROTECTED]> wrote: > As a occasional programmer I tried to recompile an old program I > intended to expand. Although #include was entered before the > start of main the g++ compiler did not recognize cin and cout. This > seems so elementary it certainly shouldn't have changed and it > certainly worked before as I am using the makefile I created when I > first wrote and compiled the program. I am running the dist-upgrade > version of Sarge. Is there a problem with the current release? Or am I > hopelessly out of date? Try std::cin and std::cout. The more recent GNU compilers enforce the std namespace. I think that started with the 3.X series. You'll also need to use std::endl instead of just endl. -- Michael A. Marsh http://www.umiacs.umd.edu/~mmarsh http://mamarsh.blogspot.com
Re: g++ problem
On 2006-02-08T20:26:58-0500, Thomas H. George wrote: > As a occasional programmer I tried to recompile an old program I > intended to expand. Although #include was entered before the > start of main the g++ compiler did not recognize cin and cout. Add a "using namespace std;" or prefix each cin and cout with the standard name space (i.e. std::cin). /Allan signature.asc Description: Digital signature
Re: (G)Vim Oddity
On 2005-12-20, Heimdall Midgard penned: > > But surely in *n*x you can't assume what a file is on the basis of > its extension? > Well, sometimes it's a good starting point. For example, one of my vim configuration files has: au BufNewFile,BufRead *.java call JavaBuildEnv() -- monique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (G)Vim Oddity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Heimdall Midgard wrote: > I just noticed something weird with my (G)Vim installation > when editing generic config files. The syntax highlighting > colors appear wrong. Could somebody do a test to confirm if > this is really a bug or just a misconfiguration on my end? this isn't a generic configuration file this is a snort configuration file, go figure what its syntax is. :set filetype? yielded filetype=hog, /usr/share/vim/vim63/syntax/hog.vim says: " Snort syntax file " Language: Snort Configuration File (see: http://www.snort.org) " Maintainer: Phil Wood, [EMAIL PROTECTED] " Last Change:$Date: 2001/05/23 19:48:42 $ " Filenames: *.hog *.rules snort.conf vision.conf > To do the test, create two files both named "udev.rules" > (perhaps in two different directories to avoid any > collision). > > Put the following lines (with no blank lines above, below or > between them) in the first file: > > # Line 1 is a comment colored Blue > # Line 2 is a comment colored Blue > Line 3 is not a comment, so is colored Black > # Line 4 is a comment but colored Black > > And put the following lines (again with not blank lines > abover, below or between them) in the second file: > > # Line 1 is a comment colored Blue > # Line 2 is a comment colored Blue > Line 3 is not a comment, so is colored Black () > # Line 4 is a comment now colored Blue > > Now open the file in GVim. The dummy text of the two files > should explain the problem. GVim displays the text in the > colors I listed for each line. The colors for console-mode > Vim should differ slightly but should display the same > pattern. > > Note how addition of a pair of parentheses to Line 3 of the > second file "causes" Line 4 to be displayed in the right > "comment" color. > > -- > Albert Einstein: Phantasie ist wichtiger als Wissen, denn > Wissen ist begrenzt. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3-cvs (MingW32) Comment: GnuPT-Light 0.5 Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDp8LSEpWP9DofOAQRAmChAKCzV9MQMKl1gP1aTxldbGR5i5UjpwCgu2Ci +r7H3L/hOUhzudjo3I8GHCw= =9QEn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (G)Vim Oddity
2005/12/20, Paolo Pantaleo <[EMAIL PROTECTED]>: > 2005/12/20, Joris Huizer <[EMAIL PROTECTED]>: > > Heimdall Midgard wrote: > > > I just noticed something weird with my (G)Vim > > > installation when editing generic config files. The > > > syntax highlighting colors appear wrong. Could > > > somebody do a test to confirm if this is really a bug > > > or just a misconfiguration on my end? [...] > > Seeing this too... but I do not know much about gvim > > highlighting so I can only attach my ~/.vimrc to help ? > > (no system-wide changes made) [...] Joris: I'll look into setting up a proper ~/.*vimrc. The only thing I have in is "syntax on" in my ~/.vimrc and and "set guifont=Bitstream\ Vera\ Sans\ Mono\ 14" in ~/.gvimrc. The thing is (g)vim appears to work out of the box with the files I usually work with (mostly HTML with some tcsh scripts). > 1) what version ov vim? Paolo: It appears to be 6.4 (Debian Unstable version). > 2) syntax realted things are in > /usr/share/vim/vim63/syntax > how vim identify a file type shold be written in > /usr/share/vim/vim63/filetype.vim > > anyway i do not think it is a bug. What files are supposed > to be the two you created? they have not a recognizable > syntax. It is just that vim thinks that your file is of a > certain type and the related syntax highlight is applied. Actually the tests were simply designed to mimick the behavior (g)vim was already displaying when I was editing my /etc/udev/rules.d/001_custom.rules. The highlighting appears to be better behaved if I renamed the file to, say, "001_custom.sh" (at least the comments are colored corrrectly). But surely in *n*x you can't assume what a file is on the basis of its extension? Actually there's something more sinister behind this. I first noticed this while editing (using vim as root) my custom udev rules. After I saved the file, some lines were apparently not being read by udev. These were the same lines that vim would not color or highlight correctly if I put a "#" at the beginning of the line. At present my udev rules file consists of a weird tangle of rules and blank comment lines (a pure blank line would do as well). In schematic form the problem would appear like this: # My UDEV rules # UDEV RULE # UDEV RULE UDEV RULE # So I was trying to cover all bases. I know it it's unlikely. But is vim inserting some hidden, non-ASCII characters? Is it simply a udev bug? Or a more general locale bug that happens to affect both udev and vim? -- Albert Einstein: Phantasie ist wichtiger als Wissen, denn Wissen ist begrenzt.
Re: (G)Vim Oddity
Heimdall Midgard wrote: Note how addition of a pair of parentheses to Line 3 of the second file "causes" Line 4 to be displayed in the right "comment" color. I can reproduce the behavior you were talking both in vim and gvim. But I do not know anything about udev syntax, so cannot comment upon "whether it is a bug/feature" issue. Using vim 6.4.4, stable. hth raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/ http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (G)Vim Oddity
2005/12/20, Joris Huizer <[EMAIL PROTECTED]>:
> Heimdall Midgard wrote:
> > I just noticed something weird with my (G)Vim installation
> > when editing generic config files. The syntax highlighting
> > colors appear wrong. Could somebody do a test to confirm if
> > this is really a bug or just a misconfiguration on my end?
> >
> > To do the test, create two files both named "udev.rules"
> > (perhaps in two different directories to avoid any
> > collision).
> >
> > Put the following lines (with no blank lines above, below or
> > between them) in the first file:
> >
> > # Line 1 is a comment colored Blue
> > # Line 2 is a comment colored Blue
> > Line 3 is not a comment, so is colored Black
> > # Line 4 is a comment but colored Black
> >
> > And put the following lines (again with not blank lines
> > abover, below or between them) in the second file:
> >
> > # Line 1 is a comment colored Blue
> > # Line 2 is a comment colored Blue
> > Line 3 is not a comment, so is colored Black ()
> > # Line 4 is a comment now colored Blue
> >
> > Now open the file in GVim. The dummy text of the two files
> > should explain the problem. GVim displays the text in the
> > colors I listed for each line. The colors for console-mode
> > Vim should differ slightly but should display the same
> > pattern.
> >
> > Note how addition of a pair of parentheses to Line 3 of the
> > second file "causes" Line 4 to be displayed in the right
> > "comment" color.
> >
> > --
> > Albert Einstein: Phantasie ist wichtiger als Wissen, denn
> > Wissen ist begrenzt.
> >
> >
>
> Seeing this too... but I do not know much about gvim highlighting so I
> can only attach my ~/.vimrc to help ?
> (no system-wide changes made)
>
> HTH,
>
> Joris
>
>
> " An example for a vimrc file.
> "
> " Maintainer: Bram Moolenaar <[EMAIL PROTECTED]>
> " Last change: 2002 May 28
> "
> " To use it, copy it to
> " for Unix and OS/2: ~/.vimrc
> " for Amiga: s:.vimrc
> " for MS-DOS and Win32: $VIM\_vimrc
> " for OpenVMS: sys$login:.vimrc
>
> " When started as "evim", evim.vim will already have done these settings.
> if v:progname =~? "evim"
> finish
> endif
>
> " Use Vim settings, rather then Vi settings (much better!).
> " This must be first, because it changes other options as a side effect.
> set nocompatible
>
> " allow backspacing over everything in insert mode
> set backspace=indent,eol,start
>
> set autoindent " always set autoindenting on
> "if has("vms")
> set nobackup " do not keep a backup file, use versions instead
> "else
> " set backup " keep a backup file
> "endif
> set history=50 " keep 50 lines of command line history
> set ruler " show the cursor position all the time
> set showcmd " display incomplete commands
> set incsearch " do incremental searching
>
> " For Win32 GUI: remove 't' flag from 'guioptions': no tearoff menu entries
> " let &guioptions = substitute(&guioptions, "t", "", "g")
>
> " Don't use Ex mode, use Q for formatting
> map Q gq
>
> " This is an alternative that also works in block mode, but the deleted
> " text is lost and it only works for putting the current register.
> "vnoremap p "_dp
>
> " Switch syntax highlighting on, when the terminal has colors
> " Also switch on highlighting the last used search pattern.
> if &t_Co > 2 || has("gui_running")
> syntax on
> " set hlsearch
> endif
>
> " don't make it look like there are line breaks where there aren't:
> " set nowrap
>
> " use indents of 2 spaces, and have them copied down lines:
> set shiftwidth=2
> set shiftround
> set expandtab
> set autoindent
>
>
> au BufNewFile,BufRead * set cindent
> " au BufNewFile,BufRead *.c *.js *.cc *.cpp set cindent
>
>
> " Only do this part when compiled with support for autocommands.
> if has("autocmd")
>
> " Enable file type detection.
> " Use the default filetype settings, so that mail gets 'tw' set to 72,
> " 'cindent' is on in C files, etc.
> " Also load indent files, to automatically do language-dependent indenting.
> " filetype plugin indent on
>
> " For all text files set 'textwidth' to 78 characters.
>autocmd FileType text setlocal textwidth=78
>
> " When editing a file, always jump to the last known cursor position.
> " Don't do it when the position is invalid or when inside an event handler
> " (happens when dropping a file on gvim).
> autocmd BufReadPost *
> \ if line("'\"") > 0 && line("'\"") <= line("$") |
> \ exe "normal g`\"" |
> \ endif
>
> endif " has("autocmd")
>
>
>
>
1) what version ov vim?
2) syntax realted things are in
/usr/share/vim/vim63/syntax
how vim identify a file type shold be written in
/usr/share/vim/vim63/filetype.vim
anyway i do not think it is a bug. What files are supposed to be the
two you created? they have not a recognizable syntax. It is just that
vim thinks that your file is of a certain type and the related syntax
highlight is applied.
PAolo
--
If
Re: (G)Vim Oddity
Heimdall Midgard wrote:
I just noticed something weird with my (G)Vim installation
when editing generic config files. The syntax highlighting
colors appear wrong. Could somebody do a test to confirm if
this is really a bug or just a misconfiguration on my end?
To do the test, create two files both named "udev.rules"
(perhaps in two different directories to avoid any
collision).
Put the following lines (with no blank lines above, below or
between them) in the first file:
# Line 1 is a comment colored Blue
# Line 2 is a comment colored Blue
Line 3 is not a comment, so is colored Black
# Line 4 is a comment but colored Black
And put the following lines (again with not blank lines
abover, below or between them) in the second file:
# Line 1 is a comment colored Blue
# Line 2 is a comment colored Blue
Line 3 is not a comment, so is colored Black ()
# Line 4 is a comment now colored Blue
Now open the file in GVim. The dummy text of the two files
should explain the problem. GVim displays the text in the
colors I listed for each line. The colors for console-mode
Vim should differ slightly but should display the same
pattern.
Note how addition of a pair of parentheses to Line 3 of the
second file "causes" Line 4 to be displayed in the right
"comment" color.
--
Albert Einstein: Phantasie ist wichtiger als Wissen, denn
Wissen ist begrenzt.
Seeing this too... but I do not know much about gvim highlighting so I
can only attach my ~/.vimrc to help ?
(no system-wide changes made)
HTH,
Joris
" An example for a vimrc file.
"
" Maintainer: Bram Moolenaar <[EMAIL PROTECTED]>
" Last change: 2002 May 28
"
" To use it, copy it to
" for Unix and OS/2: ~/.vimrc
" for Amiga: s:.vimrc
" for MS-DOS and Win32: $VIM\_vimrc
" for OpenVMS: sys$login:.vimrc
" When started as "evim", evim.vim will already have done these settings.
if v:progname =~? "evim"
finish
endif
" Use Vim settings, rather then Vi settings (much better!).
" This must be first, because it changes other options as a side effect.
set nocompatible
" allow backspacing over everything in insert mode
set backspace=indent,eol,start
set autoindent " always set autoindenting on
"if has("vms")
set nobackup " do not keep a backup file, use versions instead
"else
" set backup " keep a backup file
"endif
set history=50 " keep 50 lines of command line history
set ruler " show the cursor position all the time
set showcmd " display incomplete commands
set incsearch " do incremental searching
" For Win32 GUI: remove 't' flag from 'guioptions': no tearoff menu entries
" let &guioptions = substitute(&guioptions, "t", "", "g")
" Don't use Ex mode, use Q for formatting
map Q gq
" This is an alternative that also works in block mode, but the deleted
" text is lost and it only works for putting the current register.
"vnoremap p "_dp
" Switch syntax highlighting on, when the terminal has colors
" Also switch on highlighting the last used search pattern.
if &t_Co > 2 || has("gui_running")
syntax on
" set hlsearch
endif
" don't make it look like there are line breaks where there aren't:
" set nowrap
" use indents of 2 spaces, and have them copied down lines:
set shiftwidth=2
set shiftround
set expandtab
set autoindent
au BufNewFile,BufRead * set cindent
" au BufNewFile,BufRead *.c *.js *.cc *.cpp set cindent
" Only do this part when compiled with support for autocommands.
if has("autocmd")
" Enable file type detection.
" Use the default filetype settings, so that mail gets 'tw' set to 72,
" 'cindent' is on in C files, etc.
" Also load indent files, to automatically do language-dependent indenting.
" filetype plugin indent on
" For all text files set 'textwidth' to 78 characters.
autocmd FileType text setlocal textwidth=78
" When editing a file, always jump to the last known cursor position.
" Don't do it when the position is invalid or when inside an event handler
" (happens when dropping a file on gvim).
autocmd BufReadPost *
\ if line("'\"") > 0 && line("'\"") <= line("$") |
\ exe "normal g`\"" |
\ endif
endif " has("autocmd")
Re: g++ 2.96 on debian?
On 25-Jun-2002 Marcelo Chiapparini wrote: > On Tue, 25 Jun 2002 14:34:52 +0200 > "J.H.M. Dassen (Ray)" <[EMAIL PROTECTED]> wrote: > > > >> That's because Debian tries to stick as closely as is reasonably >> possible to official gcc releases. "2.96" (of which there appear to be >> many versions which are difficult to distinguish) has a lot of issues; >> it has e.g. been known to build gnumeric binaries which produced >> extremely inaccurate results; gnumeric's CVS version (and some other >> software as well AFAIK) has been changed to refuse compilation with >> "2.96". >> >> Your best option is to go for 3.1. > > but 3.1 is only in unstable! In testing it only goes till 3.0. How does > compare 3.0 with 3.1? > 3.0 is reasonable, 3.1 just adds improvements in speed and architecture support. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: g++ 2.96 on debian?
On Tue, 25 Jun 2002 14:34:52 +0200 "J.H.M. Dassen (Ray)" <[EMAIL PROTECTED]> wrote: > That's because Debian tries to stick as closely as is reasonably > possible to official gcc releases. "2.96" (of which there appear to be > many versions which are difficult to distinguish) has a lot of issues; > it has e.g. been known to build gnumeric binaries which produced > extremely inaccurate results; gnumeric's CVS version (and some other > software as well AFAIK) has been changed to refuse compilation with > "2.96". > > Your best option is to go for 3.1. but 3.1 is only in unstable! In testing it only goes till 3.0. How does compare 3.0 with 3.1? TIA Marcelo -- Marcelo Chiapparini DFT-IF/UERJ [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: g++ 2.96 on debian?
On Mon, Jun 24, 2002 at 21:06:37 -0500, Arun Madhurmohan wrote: > I use debian linux at home and redhat linux (unfortunately) at work. > Redhat comes with g++ 2.96 That isn't a formal gcc release; see http://gcc.gnu.org/gcc-2.96.html . (There are dissenting opinions as to its usefulness though, like http://www.bero.org/gcc296.html) > and that's what I use at work. You have my sympathy. > I can't find an equivalent version of g++ on debian. That's because Debian tries to stick as closely as is reasonably possible to official gcc releases. "2.96" (of which there appear to be many versions which are difficult to distinguish) has a lot of issues; it has e.g. been known to build gnumeric binaries which produced extremely inaccurate results; gnumeric's CVS version (and some other software as well AFAIK) has been changed to refuse compilation with "2.96". Your best option is to go for 3.1. HTH, Ray -- Linux is many, many years away from being an enterprise-ready operating system that can compete with, and challenge, the Windows platform. There is also no vision or driving force around it. Doug Miller, Microsoft Windows Server Group, january 2001 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: g++ 2.96 on debian?
On 25-Jun-2002 Arun Madhurmohan wrote: > Hi, > > I use debian linux at home and redhat linux (unfortunately) at work. > Redhat comes with g++ 2.96 and that's what I use at work. I can't find an > equivalent version of g++ on debian. I would prefer to work with the same > version of g++ at home and work. Could someone point me to a g++ 2.96 > (x86) package if there is one? Even a source package would do. > 2.95.3 was the last real release. RH's 2.96 is almost the same as our 2.95.4 (and neither were actually released by the FSF or GCC group). You are actually better off trying to move to 3.1. It works (or soon will) on all of the architectures Linux works on. Debian is moving to this, everyone is moving. Several Linux architectures can ONLY compile binaries with 3.1. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: g++-3.0 problem (with include files?)
On 13 Feb 2002, J.H.M. Dassen (Ray) wrote: > On Wed, Feb 13, 2002 at 10:31:13 +0100, Anders Lennartsson wrote: > > But with g++3.0 it reports some errors. If I run with -v it displays all > > the paths compiled in, which do seem ok. Why doesn't it find the correct > > location of the include files (which I believe is the problem)? > > That is not the problem. Your code does not comply with the current C++ > standard. See > http://www.parashift.com/c++-faq-lite/coding-standards.html#[25.4] > for details and add "using namespace std;" after the #include-s to get it to > compile. Better is (in my opinion) using std::cout; etc. This one makes available the functions etc. you are actually using. And get yourself a good, basic, up to date (ie. standards compliant) C++ book. I recommend either (or both) "Accelerated C++" or "C++ Primer". You can also easily find out much more on this topic on any C++ newsgroup like comp.lang.c++. Sincerely, Faheem Mitha.
Re: g++-3.0 problem (with include files?)
On Wed, Feb 13, 2002 at 10:31:13 +0100, Anders Lennartsson wrote: > But with g++3.0 it reports some errors. If I run with -v it displays all > the paths compiled in, which do seem ok. Why doesn't it find the correct > location of the include files (which I believe is the problem)? That is not the problem. Your code does not comply with the current C++ standard. See http://www.parashift.com/c++-faq-lite/coding-standards.html#[25.4] for details and add "using namespace std;" after the #include-s to get it to compile. HTH, Ray -- Pinky, Are You Pondering What I'm Pondering? I think so Brain, but if they called them "sad meals", kids wouldn't buy them. Pinky and the Brain in "Brain Meets Brawn"
Re: g++
<[EMAIL PROTECTED]> writes: > I upgraded my machine to potato but in compiling a c++ > program which before used to work with > > g++ -lg++ filename.cc, > > now I need > > g++ -I/usr/include/g++-2/ -lg++ filename.cc -lg++ links libg++, which are auxiliary, non-standard convenience-classes that are no longer maintained. What you want is libstdc++, and you don't need to specify this explicitly when linking with g++ (as opposed to ld). > two questions: > > 1) WHy do I need the -I now and -I/usr/include/g++-2/ might simply include the libstdc++-headers ? but these should really be included by default. (are you using gcc 2.95.2 ?) for example, on my system using libstdc++-v3 (the latest version under development): [EMAIL PROTECTED]:~ > ls /include/g++-v3/ algorithmcfloat cstddefext istream ostreamstrstream atomicity.h ciso646 cstdio fstream iterator queue typeinfo backward climits cstdlibfstream.h limitssetutility bits clocale cstringfunctional list shadow valarray bitset cmathctime iomanip localesstreamvector bu complex cwchar ios map stack cassert csetjmp cwctypeiosfwd memorystdexcept cctype csignal deque iostreamnew streambuf cerrno cstdarg exception iostream.h numeric string (the ones for gcc 2.95.2 will look a little differently) > 2) The second command doesnt work. It complains > > /usr/bin/ld: cannot find -lg++ > collect2: ld returned 1 exit status > > though all the libraraies are in /usr/lib. Any ideas? -- Felix Natter
RE: g++
On 02-Aug-2000 [EMAIL PROTECTED] wrote: > I upgraded my machine to potato but in compiling a c++ > program which before used to work with > geisha [~/testing/filebox] $ g++ -Wall -pedantic test.cc -o test geisha [~/testing/filebox] $ ./test I equals: 0 you *MAY* need to use -lstdc++, but that is about it.
Re: g++ and netscape
On Sun, Jul 23, 2000 at 08:41:41AM -0700, Nianwei Xing wrote: > > As for the netscape, it still doesn't work. I have > check the status of bookmarks, I have write > permission. > Now I can add bookmarks when I am use the netscape, > however, when I exit my machine and login it again, > all of the bookmarks dispears. That's what I want to > know. Sorry for I didn't tell the details of my > problem. So do you know how to handle it? How are you trying to add the bookmarks, through Netscape or manually with an editor? To add a bookmark in NS use the Alt+k combination. You should be able to edit the bookmarks with the Alt+b combination. You might also check to see if you have write permission in the ~/.netscape directory. Who is the owner of that directory? If you're using an external editor to modify the bookmarks.html file, be sure NS is NOT running. It writes over the file upon exit, so you'll lose any changes. It is safe to edit it if NS is not running, however. HTH, - Nate >> -- Wireless | Amateur Radio Station N0NB | "None can love freedom Internet | [EMAIL PROTECTED] | heartily, but good Location | Wichita, Kansas USA EM17hs | men; the rest love not Wichita area exams; ham radio; Linux info @ | freedom, but license." http://www.qsl.net/n0nb/ | -- John Milton
Re: g++ and netscape
Hi, Ragga: Thanks for your information! I have make the g++ work for I forget to give the directory ./ As for the netscape, it still doesn't work. I have check the status of bookmarks, I have write permission. Now I can add bookmarks when I am use the netscape, however, when I exit my machine and login it again, all of the bookmarks dispears. That's what I want to know. Sorry for I didn't tell the details of my problem. So do you know how to handle it? Cheers Nianwei --- Ragga Muffin <[EMAIL PROTECTED]> wrote: > > Nianwei Xing <[EMAIL PROTECTED]> wrote: > > > Hi, Debians: > > I have two problem with my new debian. > > 1. Afte I compile and link my c++ code with g++ , > it > > generate a.out but I can not execute it. should I > need > > to install some packages? > > Do you get some error message ? > I can imagine 2 possibilities: > 1. You don't have execution permissions on the > file. >The remedy is 'chmod u+x a.out' > 2. You really generated an a.out but have no > support in the kernel >Hmm... somehow I doubt this... > > > 2. I can not use "add bookmark" in my netscape, > > however, there is the file bookmark.html exist > under > > the directory ./netscape under my home directory. > How > > can I handle this situation? > > Check that you have write permissions on that file > and directory. > Does netscape read the file if you point it to it ? > > HTH > Ragga > > > -- > Unsubscribe? mail -s unsubscribe > [EMAIL PROTECTED] < /dev/null > __ Do You Yahoo!? Get Yahoo! Mail Free email you can access from anywhere! http://mail.yahoo.com/
Re: g++ and netscape
Nianwei Xing <[EMAIL PROTECTED]> wrote: > Hi, Debians: > I have two problem with my new debian. > 1. Afte I compile and link my c++ code with g++ , it > generate a.out but I can not execute it. should I need > to install some packages? Do you get some error message ? I can imagine 2 possibilities: 1. You don't have execution permissions on the file. The remedy is 'chmod u+x a.out' 2. You really generated an a.out but have no support in the kernel Hmm... somehow I doubt this... > 2. I can not use "add bookmark" in my netscape, > however, there is the file bookmark.html exist under > the directory ./netscape under my home directory. How > can I handle this situation? Check that you have write permissions on that file and directory. Does netscape read the file if you point it to it ? HTH Ragga
Re: g++ ?
erasmo perez <[EMAIL PROTECTED]> writes: > hi people! > > where can i download the latest (unstable) g++ compiler package for debian ? g++ is currently in the process of a big change: gcc-2.95.2 is the stable version, but it lacks a standard-conformant c++-library. One is being developed, and should be mostly stable: http://sourceware.cygnus.com/libstdc++/ If you want to use it, you need to get source packages for binutils, gcc-core, gcc-g++ and libstdc++ (a snapshot) and follow the instructions from libstdc++-v3. If you don't need that, I suggest you use the compiler that is installed on your system. I don't think there are very many changes in 2.95.2 (except for template-support). -- Felix Natter
Re: g++ identity crisis, slink
Um... never mind... I found it. (.C, not .c ... sheesh) (thanks anyway :) From: [EMAIL PROTECTED] To: debian-user@lists.debian.org Subject:g++ identity crisis, slink Date sent: Wed, 28 Jun 2000 11:54:54 -0400 > > Hi, I'm running slink and I was trying to 'make' some c++ programs I > was messing around with the other day and discovered that even > though my Makefile says to use g++, make was using cc to compile > the programs. /usr/bin/g++ is a program, not a link to anything. If I > rename /usr/bin/cc, make refuses to run. I did do a make -v to make > sure it was GNU make, and it is. (someone mentioned to me that this > might be an issue) > > Now, I vaguely remember something in setting up my system that > might have had something to do with which compiler I liked or wanted > to be default or something... but it's really hazy and I could be wrong. > _Is_ there something like that in the debian set-up and, if so, is there a > way to change/override it? > > -Alice Alice M. Pinard Casco Indemnity Company [EMAIL PROTECTED]
Re: g++ identity crisis, slink
On Wed, Jun 28, 2000 at 11:55:04 -0400, [EMAIL PROTECTED] wrote: > Hi, I'm running slink and I was trying to 'make' some c++ programs I > was messing around with the other day and discovered that even > though my Makefile says to use g++, make was using cc to compile > the programs. This smells like a bug in your makefile. What does "make -n" say? Does "make -d" provide clues? What does your makefile look like? Ray -- UNFAIR Term applied to advantages enjoyed by other people which we tried to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY, UNDERHAND and JUST LUCKY I GUESS. - The Hipcrime Vocab by Chad C. Mulligan
Re: g++ ?
On Tue, Jun 27, 2000 at 07:31:28 +0200, erasmo perez wrote: > where can i download the latest (unstable) g++ compiler package for debian ? ftp.debian.org:/debian/dists/unstable/main/binary-i386/devel/g++*deb HTH, Ray -- UNFAIR Term applied to advantages enjoyed by other people which we tried to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY, UNDERHAND and JUST LUCKY I GUESS. - The Hipcrime Vocab by Chad C. Mulligan
Re: g++
Michiel Meeuwissen <[EMAIL PROTECTED]> writes:
> I think there is something wrong with my g++ (using the latest version of
> frozen).
>
> If I make a file only containing
>
> #include
> main(){}
>
> or
>
> $include
>
> then:
>
> ~$ g++ test.cpp
> test.cpp:1: iostream: No such file or directory
>
>
> But:
>
> ~$ g++ -I /usr/include/g++-3 test.cpp
> ~$
>
> I think it should work also without the -I option, since 'iostream' and STL
> etc are standard parts of C++, aren't they? And I am sure that it _did_ work
> without this -I option.
the latest release of gcc does not currently support the latest C++-standard
with regard to its implementation of the standard C++-library.
See my other reply (subject "Re: C and C++ library docs")
> So my question is if this happens only on my system, and if so how do I
> solve it (i supposed that there would be some environment variable with the
> include path, but I don't seem to be able to find this information).
if you want to distribute programs, you probably don't want to use the new
features of libstdc++-v3, but instead the (portable) subset included
with gcc-2.95.2.
For the headers, you can create symlinks.
try
[EMAIL PROTECTED]:~ > gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.60/specs
gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)
to find out where g++ puts its headers (in this case the prefix
is /usr, so the headers are in /usr/include/g++-version)
--
Felix Natter
Re: g++ and libstdc++2.9 circular dependence
Dear Kevin > dpkg -i foo bar seemed a little bit criptic to me. In case it was to you as > well, you can just type > > dpkg -i g++*.deb libstdc++2.9-dev*.deb > > Both packages will be installed without any problem. I know this because I > had > the same question as you had, and this was the (successful) suggestion I was > given. > Thanks for the translation. :) Chuck Kaufman [EMAIL PROTECTED]
Re: g++ and libstdc++2.9 circular dependancy
dpkg -i foo bar seemed a little bit criptic to me. In case it was to you as well, you can just type dpkg -i g++*.deb libstdc++2.9-dev*.deb Both packages will be installed without any problem. I know this because I had the same question as you had, and this was the (successful) suggestion I was given. cheers, -- kevin *** Kevin M. McLin Office: Duane C-328 [EMAIL PROTECTED] Phone: (voice) 303-492-4053 http://casa.colorado.edu/~mcl/ (fax) 303-492-7178 Snail Mail: Center for Astrophysics and Space Astronomy CB 389, University of Colorado, Boulder, CO 80309-0389 ***
Re: g++ and libstdc++2.9 circular dependancy
Quoting Charles Kaufman ([EMAIL PROTECTED]): > I am trying to install the version of g++ in stable, using > dpkg. g++ depends on libstdc++2.9-dev and libstdc++2.9-dev depends > on g++. dpkg will not allow the installation of > one without the other, as in catch-22. > Must the installation be forced? There is a bug report > about a similar problem with 2.10 but none about 2.9 that > I can find. dpkg -i foo bar Cheers, -- Email: [EMAIL PROTECTED] Tel: +44 1908 653 739 Fax: +44 1908 655 151 Snail: David Wright, Earth Science Dept., Milton Keynes, England, MK7 6AA Disclaimer: These addresses are only for reaching me, and do not signify official stationery. Views expressed here are either my own or plagiarised.
Re: g++ (egcs) and g++272
On Thu, Aug 05, 1999 at 08:01:37 -0600, Robert Kerr wrote: > can g++ (the egcs version) and g++272 coexist successfully? No; the library packages they need conflict. g++272 was a crude hack to allow package maintainers a backdoor for compiling old code. > I'm using a slink system, and think that I need to back up the g++272 > compiler for a legacy app, Are you sure you need g++272 for it? Much legacy code can still be compiled by g++ if you install the libg++ packages. HTH, Ray -- Tevens ben ik van mening dat Nederland overdekt dient te worden.
Re: g++ & -lcrypt
Hi, On Tue, 6 Jul 1999, Jaycee wrote: > linker, it says there are undefined references to char *crypt. > This same program compiles perfectly under gcc. > any suggestions? > char* crypt is not declared extern "C"? OK
Re: g++
On Sat, Apr 17, 1999 at 11:52:19 +1200, Michael Beattie wrote: > /usr/bin/ld: cannot open -lstdc++: No such file or directory > collect2: ld returned 1 exit status > just checking my libs dir... no libstdc++.so.0 : > > /usr/lib/libstdc++-2-libc6.0-1-2.9.0.a Erm, the only link that matters to the linker is `libstdc++.so' (no .a, no numbers). That link should be installed by the libstd++ -dev package. Do you have that installed? Ray -- POPULATION EXPLOSION Unique in human experience, an event which happened yesterday but which everyone swears won't happen until tomorrow. - The Hipcrime Vocab by Chad C. Mulligan
Re: g++
> just checking my libs dir... no libstdc++.so.0 : > > /usr/lib/libstdc++-2-libc6.0-1-2.9.0.a > /usr/lib/libstdc++-2-libc6.0-1-2.9.0.so > /usr/lib/libstdc++-libc6.0-1.a.2 -> libstdc++-2-libc6.0-1-2.9.0.a > /usr/lib/libstdc++-libc6.0-1.so.2 -> libstdc++-2-libc6.0-1-2.9.0.so > /usr/lib/libstdc++.so.2.7.2 -> libstdc++.so.2.7.2.8 > /usr/lib/libstdc++.so.2.7.2.8 > /usr/lib/libstdc++.so.2.8 -> libstdc++.so.2.8.0 > /usr/lib/libstdc++.so.2.8.0 > /usr/lib/libstdc++.so.2.9 > /usr/lib/libstdc++.so.272 -> libstdc++.so.2.7.2.8 Ignore this... I just realised I have no idea what I am talking about. Michael Beattie ([EMAIL PROTECTED]) PGP Key available, reply with "pgpkey" as subject. - If it can't be fixed with Vise-Grips & duct tape, it can't be fixed. - Debian GNU/Linux Ooohh You are missing out!
Re: g++
On Fri, 16 Apr 1999, J.H.M. Dassen wrote:
> On Fri, Apr 16, 1999 at 23:11:56 +1200, Michael Beattie wrote:
> > In a configure script, this is the outcome:
>
> > configure: error: installation or configuration problem: C++ compiler
> > cannot create executables.
>
> Run configure with the '-v' argument, and show us the relevant parts of the
> config.log thus generated.
configure:1275: checking for a C++-Compiler
configure:1281: checking for g++
configure:1393: checking whether the C++ compiler (g++ -s) works
configure:1407: g++ -o conftest -s conftest.C 1>&5
/usr/bin/ld: cannot open -lstdc++: No such file or directory
collect2: ld returned 1 exit status
configure: failed program was:
#line 1403 "configure"
#include "confdefs.h"
main(){return(0);}
just checking my libs dir... no libstdc++.so.0 :
/usr/lib/libstdc++-2-libc6.0-1-2.9.0.a
/usr/lib/libstdc++-2-libc6.0-1-2.9.0.so
/usr/lib/libstdc++-libc6.0-1.a.2 -> libstdc++-2-libc6.0-1-2.9.0.a
/usr/lib/libstdc++-libc6.0-1.so.2 -> libstdc++-2-libc6.0-1-2.9.0.so
/usr/lib/libstdc++.so.2.7.2 -> libstdc++.so.2.7.2.8
/usr/lib/libstdc++.so.2.7.2.8
/usr/lib/libstdc++.so.2.8 -> libstdc++.so.2.8.0
/usr/lib/libstdc++.so.2.8.0
/usr/lib/libstdc++.so.2.9
/usr/lib/libstdc++.so.272 -> libstdc++.so.2.7.2.8
Michael Beattie ([EMAIL PROTECTED])
PGP Key available, reply with "pgpkey" as subject.
-
"42? 7 and a half million years and all you can come up with is 42?!"
-
Debian GNU/Linux Ooohh You are missing out!
Re: g++
On Fri, Apr 16, 1999 at 23:11:56 +1200, Michael Beattie wrote: > In a configure script, this is the outcome: > configure: error: installation or configuration problem: C++ compiler > cannot create executables. Run configure with the '-v' argument, and show us the relevant parts of the config.log thus generated. Ray -- Obsig: developing a new sig
Re: g++ -- installation difficulties
Jonathan Hayward <[EMAIL PROTECTED]> writes: > I have had some difficulties with g++. When I run it, I get the > following error message: > > /usr/lib/crt1.o(.text+0x36): undefined reference to `main' > collect2: ld returned 1 exit status Are you sure you have a main() function in the program you're trying to compile? If so, see if you can reproduce your error with a small hello-worldish example and post your example code along with the exact command line you use to invoke g++ -- Henning Makholm http://www.diku.dk/students/makholm
Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
Hello, > >I left the source as it was, but added some softlinks, like > >/usr/include/X11/GL -> /usr/include/GL > > Me to, but I had to edit out some refs. to a /GL/GLw/ directory included > file - the header file was actually under /GL, and Glw doesn't exist on > my system. I used softlinks throughout, but I don't remember them all... /usr/include/X11/GLw -> GL > But try compiling the vopengl stuff - all the makefiles are set up for > windows, even though I downloaded the X version of V. I didn't have any other problems - it might have helped that I used Mesa, from a Debian package, so I didn't have to compile OpenGL myself. mesag2 2.6-3 A 3-D graphics library which uses the OpenGL mesag2-dev 2.6-3 Development library for Mesa [libc6]. > Do you know what's happened to the V mailing list? It just says it's > moving on the V site. No idea. Didn't try it (I was after compiling FREEdraft, and V was just a step on the way). > >slink isn't released yet, anyway. > > Indeed, but it is clear from this list that many people with time to > spare are upgrading anyway... With emphasis on "time to spare" :-) > I think I've got what's up with the different compilers now, but since > compiling free source is such a typical Unix tradition, I feel that the > documentation on what's going on should be more widely publcicised, Hmm, perhaps a tutorial kind of thing. * download file into a subdir * tar xvzf file.tgz (if your tar can handle that) * read README, INSTALL etc * basic make usage, common make targets, editing makefiles * understanding error messages * ... Especially the error messages can often be very obscure-looking and still tell you exactly what's wrong! Jiri <[EMAIL PROTECTED]>
Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
>Subject: Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused* >To: [EMAIL PROTECTED] (Martin Waller) >Date: Tue, 8 Dec 1998 16:30:50 +1100 (EST) >Cc: debian-user@lists.debian.org >From: Jiri Baum <[EMAIL PROTECTED]> > >Hello, > >> Over the weekend, I downlaoded V 1.20 onto /usr/local/. > >Did the same last night. > >> I tried compiling it and after finding out that I needed all the OpenGl >> stuff and isntalling that to (V. annoying by the way - had even to edit some >> of the source code to get rid of those probelms) > >I left the source as it was, but added some softlinks, like >/usr/include/X11/GL -> /usr/include/GL > Me to, but I had to edit out some refs. to a /GL/GLw/ directory included file - the header file was actually under /GL, and Glw doesn't exist on my system. >> But then I got the make error message: >> >> In vbglcnv.h:51:Invalid storage class specifiers decalared in friend >> functions > >Get rid of the word "static" on that line. > This is what i eventually did, after finally gettinbg a clue as to what it meant. >> I didn't have a clue what this meant even after viewing the two friend >> functions alluded to. > >"storage class" means auto, static, register or extern; there are two >modifiers, const and volatile. > >In this case, there's only one storage specifier on the whole line (unless >there's something in macros), so that had to be what it was complaining about >:-) > >Getting rid of it fixed the problem. I hope it didn't break anything (but >FREEdraft compiled and ran okay, so I guess not). > But try compiling the vopengl stuff - all the makefiles are set up for windows, even though I downloaded the X version of V. Do you know what's happened to the V mailing list? It just says it's moving on the V site. >> Being naive enough to try anything, and having heard of all sorts of >> problems with egcs and g++, I decided to scrap g++2.8 and put g++2.7.2 on. >> (I had egcs 2.90.29, dated 19980515). Eeventually, I did get it to compile with egcc and g++ (2.8). I had to edit the Config.mk to use CC=egcc instead of CC=gcc so as not to mix and match g++2.8 and GCC2.7.2. > >I didn't want to do that, because FREEdraft claimed to use fancy >exception-handling that 2.7.x doesn't grok - and that's why I was getting V. There's also a way on the ftp site a way to compile V without the OpenGL stuff. But hell - if it's there why not play. > >> (I'm on a HAMM systen still - it took me 4 goes to get a successful upgrade >> from bo to that, so I'm not ready to slink it yet). > >slink isn't released yet, anyway. Indeed, but it is clear from this list that many people with time to spare are upgrading anyway... I think I've got what's up with the different compilers now, but since compiling free source is such a typical Unix tradition, I feel that the documentation on what's going on should be more widely publcicised, like in the general info about installing/upgrading to HAMM. > > >Jiri <[EMAIL PROTECTED]> > __ Get Your Private, Free Email at http://www.hotmail.com
Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
On Wed, Dec 09, 1998 at 00:13:16 -0500, Ed Cogburn wrote: > > >Read /usr/doc/gcc/README.Debian . > It didn't say *why* we have an apparent fork in compiler development. It doesn't contain a full history of the free software movement either, as that's out of scope for that document too. > Since the gcc compiler is at the core of Linux (behind only the kernel > itself in importance), having a semi-permanent fork in development, ala > emacs/xemacs, is the last thing we need. First, forks aren't necessarily bad. Read e.g. http://www.chiark.greenend.org.uk/~ijackson/sane98-talk.ps or ESR's writings. The EGCS project has brought nearly all of gcc's lost children together again. That's progress. Second, de facto there is no fork. The FSF gcc development is dead (or at least smelling /very/ funny), though the FSF doesn't admit it yet. EGCS is alive and well. [As a small example, FSF gcc 2.8.1's C++ handling is more or less the same as EGCS 1.0.x's. Of the C++ bugs reported against Debian's EGCS 1.0.3 g++ package, half were fixed in EGCS 1.1, in a period shorter than a Debian release cycle. 2.8.1 is still the latest FSF gcc.] Ray -- LEADERSHIP A form of self-preservation exhibited by people with auto- destructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. - The Hipcrime Vocab by Chad C. Mulligan
Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
Martin Waller wrote: > > > > >Read /usr/doc/gcc/README.Debian . > > > > I did but was still confused :( > > It didn't say *why* we have an apparent fork in compiler development. Since the gcc compiler is at the core of Linux (behind only the kernel itself in importance), having a semi-permanent fork in development, ala emacs/xemacs, is the last thing we need. -- Ed C.
Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
Hello, > Over the weekend, I downlaoded V 1.20 onto /usr/local/. Did the same last night. > I tried compiling it and after finding out that I needed all the OpenGl > stuff and isntalling that to (V. annoying by the way - had even to edit some > of the source code to get rid of those probelms) I left the source as it was, but added some softlinks, like /usr/include/X11/GL -> /usr/include/GL > But then I got the make error message: > > In vbglcnv.h:51:Invalid storage class specifiers decalared in friend > functions Get rid of the word "static" on that line. > I didn't have a clue what this meant even after viewing the two friend > functions alluded to. "storage class" means auto, static, register or extern; there are two modifiers, const and volatile. In this case, there's only one storage specifier on the whole line (unless there's something in macros), so that had to be what it was complaining about :-) Getting rid of it fixed the problem. I hope it didn't break anything (but FREEdraft compiled and ran okay, so I guess not). > Being naive enough to try anything, and having heard of all sorts of > problems with egcs and g++, I decided to scrap g++2.8 and put g++2.7.2 on. > (I had egcs 2.90.29, dated 19980515). I didn't want to do that, because FREEdraft claimed to use fancy exception-handling that 2.7.x doesn't grok - and that's why I was getting V. > (I'm on a HAMM systen still - it took me 4 goes to get a successful upgrade > from bo to that, so I'm not ready to slink it yet). slink isn't released yet, anyway. Jiri <[EMAIL PROTECTED]>
Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
>
>Read /usr/doc/gcc/README.Debian .
>
I did but was still confused :(
>> Being naive enough to try anything, and having heard of all sorts of
>> problems with egcs and g++, I decided to scrap g++2.8 and put
g++2.7.2 on.
>> (I had egcs 2.90.29, dated 19980515).
>
>g++2.7.2 is intended only for compiling code that cannot be compiled
with
>EGCS gcc. It's not supposed to be easy to install or use.
>
>> is v using some
>> non-standard c++ shit that breaks on 'modern' compilers?
>
>That's more likely.
>
>> I suspect egcs
>
>EGCS has proven itself to be a very good C++ compiler so far.
>
OK - then I'd like to understand the error message that came up
('Invalid storage class specifier in friend function declarations').
Here's the code up to the friend functions decls. where the
aforementioned error message is generated:
//===
// vglcnv.h GL Canvas C++ class .h file - X11R5
//
// Copyright (C) 1995,1996 Bruce E. Wampler
//
// This file is part of the V C++ GUI Framework, and is covered
// under the terms of the GNU Library General Public License,
// Version 2. This library has NO WARRANTY. See the source file
// vapp.cxx for more complete information about license terms.
//===
#ifndef VGLCNV_H
#define VGLCNV_H
#include
#include
//
extern "C"
{
//
static void CGLKeyInEV(Widget w, XtPointer client_data, XEvent* event,
char *x);
//
// OpenGL stuff here
//
void CgraphicsInit(Widget w, XtPointer clientData, XtPointer call);
//
#include// Xt OpenGL drawing area widget.
#include
#include
#include
//
}
//
const unsigned int vGL_Default = 0;
const unsigned int vGL_RGB = 0x0001;
const unsigned int vGL_Alpha = 0x0002;
const unsigned int vGL_Indexed = 0x0004;
const unsigned int vGL_DoubleBuffer = 0x0008;
const unsigned int vGL_Stereo = 0x0010;
const unsigned int vGL_Stencil = 0x0020;
const unsigned int vGL_Accum = 0x0040;
const unsigned int vGL_Depth = 0x0080;
//
class vWindow; // we are part of a window
//
class vBaseGLCanvasPane : public vCanvasPane
{
//
friend void CgraphicsInit(Widget w, XtPointer clientData, XtPointer
call);
friend static void CGLKeyInEV(Widget w, XtPointer client_data, XEvent*
event, char *x);
//the two functions here cause the problem with egcs!
(etc.)
__
Get Your Private, Free Email at http://www.hotmail.com
Re: g++2.8, egcs, gcc 2.7.2, etc. - *very confused*
On Mon, Dec 07, 1998 at 01:50:48 -0800, Martin Waller wrote: > I am stunningly confused about the whole c and c++ suite thing that's > going on (I'm still in HAMM - it's *not * the __register_frame_info > stuff!). Read /usr/doc/gcc/README.Debian . > Being naive enough to try anything, and having heard of all sorts of > problems with egcs and g++, I decided to scrap g++2.8 and put g++2.7.2 on. > (I had egcs 2.90.29, dated 19980515). g++2.7.2 is intended only for compiling code that cannot be compiled with EGCS gcc. It's not supposed to be easy to install or use. > So, please help me - why couldn't egcs g++ compile v? Is that version > (like some others it would seem...) broken? Or is v using some > non-standard c++ shit that breaks on 'modern' compilers? That's more likely. > I suspect egcs EGCS has proven itself to be a very good C++ compiler so far. > I am afraid but understand nothing. Would upgrading to the version > referred to in the __register_frame_info FAQ work or what You'll need libc6 2.0.7u-7.1 ; older version either have the __register_frame_info problem, or conflict with essential packages. Ray -- ART A friend of mine in Tulsa, Okla., when I was about eleven years old. I'd be interested to hear from him. There are so many pseudos around taking his name in vain. - The Hipcrime Vocab by Chad C. Mulligan
Re: g++272 libs, revisited.
>
> As part of a homework assignment I've written a little program to do
> arithmetic with fractions and mixed numbers, and I wanted to benchmark the
> speed of various algorithms for finding 'gcd,' the greatest common divisor.
> Not knowing how to do the timing piece, I started playing with gettimeofday.
> Here's what I came up with:
>
> #include
> #include
>
> int main()
> {
> struct timeval *ThisTime;
^
There we have our elementary C programming error :)
> struct timezone *huh = 0;
> int i;
> long int k;
> i = gettimeofday(ThisTime, huh);
> cout << i << endl;
> k = ThisTime->tv_sec;
> cout << k;
> }
You need to provide a pointer to a struct timeval, not a struct timeval
pointer that points to some random address. The gettimeofday function
is part of the standard C library. In C, there are no reference
arguments (like in C++), so there is no way a function can write an
address into a pointer argument. Therefore you need to provide the
address of an existing variable, so
struct timeval tv;
int i;
i = gettimeofday(&tv, 0);
Then the function will write into the struct timeval tv.
The fact that the code doesn't crash under DJGPP is a coincidence. In
fact, if code crashes with one compiler and runs fine with the other,
chances are high you have a memory allocation error lurking. Your best
bet is then to check the code with the compiler that makes it crash!
Besides, the function you really need for timing CPU usage is `times'
(do a `man 2 times'). Moreover, there is the unix command time (or the
bash builtin version) that gives you the statistics you want. Just type
time myprg
where `myprg' is your program, and you get the statistics.
> Aha sez I; I'll just whip the g++272 package onto the Debian box and be home
> free. Did that, but it won't compile, complaining of many errors in the
> headers, eg:
Don't do that. The 2.7.2 compiler is not nearly as good as the standard
egcs g++ that debian2.0 has.
[...]
> Aha sez I; I don't have the libg++272-dev package on board - I'll just whip
> that onto the Debian machine and be home free. Tried that, but I can't install
> this package, just produce an dpkg error stating I already have libg++-2.8-dev
> and that there's a conflict wrt libg++-dev that's provided by the latter.
Just remove the 2.7.2 g++ stuff again. You really should only need that
if you try to compile old stuff that relies on buggy `features'.
> I am most curious about:
>
> 1) How to write a little timing routine for benchmarking.
As I said before, use times(). Make sure to #include as well
as , and divide the values from times by CLK_TCK to
convert from clock tics to seconds (don't use CLOCKS_PER_SECS as is
suggested in the libc6-doc info file, this has the wrong value (by the
way, install libc6-doc and read it with `info libc', it contains
valuable information on unix programming)).
> 2) Why egcs can't build a working version of that piece of code.
Because there was a bug in it. In general, you should suspect bugs in
your own code, before suspecting bugs in a compiler (speaking from
experience here :).
> 3) How to get g++272 happily cohabiting with egcs on my Debian installation.
This is possible, but you have no need for it. It is not very
convenient to have two compilers on your system, and you don't want to
start relying on g++272, because it is far worse than the egcs g++
compiler. In general, you want to use the compiler that gives you the
most errors, it will help you remove bugs from _your_ code.
End of lesson ;)
HTH,
Eric
--
E.L. Meijer ([EMAIL PROTECTED]) | tel. office +31 40 2472189
Eindhoven Univ. of Technology | tel. lab. +31 40 2475032
Lab. for Catalysis and Inorg. Chem. (TAK) | tel. fax+31 40 2455054
Re: g++272 libs, revisited. (This is really a C question)
Bob Bernstein wrote:
> As part of a homework assignment I've written a little program to do
> arithmetic with fractions and mixed numbers, and I wanted to benchmark the
> speed of various algorithms for finding 'gcd,' the greatest common divisor.
> Not knowing how to do the timing piece, I started playing with gettimeofday.
> Here's what I came up with:
>
> #include
> #include
>
> int main()
> {
> struct timeval *ThisTime;
> struct timezone *huh = 0;
> int i;
> long int k;
> i = gettimeofday(ThisTime, huh);
> cout << i << endl;
> k = ThisTime->tv_sec;
> cout << k;
> }
> --
> Bob Bernstein
> at
> Esmond, R.I., USA <[EMAIL PROTECTED]>
>
> --
> Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
Bob,I don't know much about linux, but I think there is a basic C programming
mistake.
I don't think gettimeofday points your pointers to some static memory, I think
it
expects you to allocate memory for them.
Specifically man for gettimeofday says
***
PROTOTYPE:
int gettimeofday( struct timeval *tv, struct timezone *tz );
DEFINITION:
...
if either tv or tz is null the corresponding structure is not set or
returned.
This means gettimeofday is expecting you to have allocated memory.
Congratulations
to gcc for linux for not letting you do so dangerous of an unitialized pointer
mistake. Since you initialized huh to 0 (better form is to init to manifest
constant
NULL) that's fine. But ThisTime is an unitialized pointer A BIG C NO-NO!
gettimeofday will initialize to whatever memory location is pointed to by
whatever is
on the stack (and interpreted as a pointer) when space is grabbed for the local
data
for main.
There are two types of solution, one is dynamic memory (more responsibility for
you
to clean up) or local (automatic) memory. I took the liberty of changing your
variable to begin with lower case, since I prefer that style.
/*local (stack space) solution:*/
struct timeval thisTime;
...
i = gettimeofday( &thisTime, NULL);
...
k = thisTime.tv_sec; /*no longer using indirection*/
/*dynamic (heap space) solution - C++*/
struct timeval *thisTime = new timeval;
...
i = gettimeofday( thisTime, NULL );
...
k = thisTime.tv_sec;
... /*assuming your program was bigger and you wanted to be frugal with memory:
when
your done using 'thisTime'*/
delete thisTime; /*Don't use thisTime anymore unless you reallocate, or you're
making a dangling pointer mistake*/
This is really a C question though, there is lots of good literature on being
VERY CAREFUL about pointers. If your not careful someday we may all be forced
to
program in JAVA so such error are no longer made ; )
-Chip Grandits
---Your year 10K consultant, someday 4 digits wont be enough, hire me today!---
Re: g++/gcc system errors
On Tue, Sep 15, 1998 at 04:29:39PM -0500, Matt Garman wrote: > > > While working on some C++ code for a programming assignment, I got the > following error: > > /usr/lib/crt1.o(.text+0x36): undefined reference to `main' > collect2: ld returned 1 exit status > > And that is simply after typing "g++ .cc" You don't have a main() function. > The other error is as follows: > > If I mistakenly type "gcc .cc" : > > gcc: installation problem, cannot exec `cc1plus': No such file or directory > > I know the correct thing to do is to call g++ explicitly when > compiling C++ code, but I'd like to fix the error. What error? gcc is for C, g++ is for C++. You can use g++ with most C programs, but not the other way round. The reason is because we use a complex setup, where gcc is actually gcc 2.7.2.3 and g++ is egcs2.9x.yy. This is all for your benefit. The drawback is that you can't compile C++ programs with gcc, but who wants to do so anyway? Marcus -- "Rhubarb is no Egyptian god."Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: g++/gcc system errors
> While working on some C++ code for a programming assignment, I got the > following error: > > /usr/lib/crt1.o(.text+0x36): undefined reference to `main' > collect2: ld returned 1 exit status > > And that is simply after typing "g++ .cc" First, make sure you have a function called main (and it's typed correctly. The first time I found this error I had a function called "mian"). Second, if you want just the object file (ie. no linking) then use "g++ -c .cc -o .o". > The other error is as follows: > > If I mistakenly type "gcc .cc" : > > gcc: installation problem, cannot exec `cc1plus': No such file or directory Can't help you there John
Re: g++ Is Fine. I Was Wrong
Yes, g++ works just fine. Please disregard my previous messages on this and sorry for the clutter. Art On Sun, Sep 06, 1998 at 04:00:04PM -0600, Art Lemasters wrote: > Thanks to Alan Su and Marcus Brinkman for correcting > me in regards to g++. I did not have it installed on this > system (only had gcc installed). What can I say, but that > I am a newbie. ;-) > > g++ is downloading here now, and the status after > the download will be reported. > > Art, who is in the corner wearing a "dunce" cap for now > > Heh, heh,... > > > > -- > Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null >
Re: g++ won't compile. How do I fix it?
> > How do I fix this? What's wrong? > > bash-2.00$ g++ --help > ld: warning: libm.so.5, needed by /usr/lib/libg++.so, may conflict with > libm.so.6 > /lib/libm.so.5: warning: erfl is not implemented and will always fail > /usr/lib/crt1.o(.text+0x36): undefined reference to `main' > /lib/libm.so.5: undefined reference to `__getfpucw' I *think* this means you've got a screwed up libc6 development stuf. My first guess would be that you've get libg++27-dev + libg++27 (the libc5 versions) installed, while you have a libc6 g++ (2.7.2.2). To correct, just remove libg++27-dev, install libg++272 and libg++272-dev The libg++272 versions can be found on master's incoming, or on it's mirror: ftp://cfni.com/pub/linux/debian/Incoming -- joost witteveen, [EMAIL PROTECTED] #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: g++ / ld / publib linking problem
In message <[EMAIL PROTECTED]>, writ
es:
>On Thu, 10 Jul 1997, Oliver Elphick wrote:
>
>> No-one has attempted an answer to this yet; if you have any ideas,
>> please let me know!
>>
>Don't know what this publib stuff is (just running dpkg -S
>/usr/include/publib [ah see, high-level functions]), but the problem is
>shining from your description. The stanza
>#ifdef __cplusplus
>extern "C" {
>#endif
> from the beginning and the one
>#ifdef __cplusplus
>}
>#endif
>from the end of include files which are only C is missing.
>As publib is a _C_ function library, I would not exactly call it as a bug.
>You can add the stanzas to your c source around the #include line.
>It is just C++ and strong type checking.
Brilliant! That was the answer, of course.
I now remember that I had put this change into publib.h before, which
was why it had worked before. When I upgraded to the new version,
I forgot about that change and thought that it had worked 'out of the box'
before.
Lars, could this be incorporated as a permanent feature in the Debian
package, please?
--
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight http://lfix.co.uk/oliver
Make it idiot-proof, and someone will breed a better idiot.
pgpqhFuPPYvnD.pgp
Description: PGP signature
Re: g++ / ld / publib linking problem
Hi
On Thu, 10 Jul 1997, Oliver Elphick wrote:
> Date: Thu, 10 Jul 1997 16:49:31 +0100
> From: Oliver Elphick
> To: debian-user@lists.DEBIAN.org
> Subject: g++ / ld / publib linking problem
> Resent-Date: Thu, 10 Jul 1997 16:47:47 +
> Resent-From: debian-user@lists.DEBIAN.org
> Resent-cc: recipient list not shown: ;
>
> No-one has attempted an answer to this yet; if you have any ideas,
hmm...
this is first time i saw this
> please let me know!
>
> --- Repeated Message
>
> Date:Fri, 04 Jul 1997 22:21:39 +0100
> From:"Oliver Elphick"
> To: debian-user@lists.debian.org
> Subject: Problem linking with publib library and g++
>
> I have a linking problem when I try to include functions from the
> publib library in a C++ program. This worked before I upgraded
> to the new releases (see below).
>
> An easy example:
> #include
> main()
> {
> char *x = "This is a string with spaces ";
> char y[256];
>
> strcpy(y, x);
> strtrim(y);
> strmtrim(y);
> printf ("%s-\n%s-\n", x, y);
> }
>
> When I try to compile this as C++:
> linda:~/cprogs$ g++ main.c -lpub
> /tmp/cca132571.o: In function `main':
> /tmp/cca132571.o(.text+0x2b): undefined reference to `strtrim(char *)'
> /tmp/cca132571.o(.text+0x3a): undefined reference to `strmtrim(char *)'
>
> but as C, it's fine:
> linda:~/cprogs$ gcc main.c -lpub
> linda:~/cprogs$
>
> I can't work out what has changed and why this no longer works.
>
> System: Pentium Pro
> Kernel: 2.0.30
> Debian: 1.3 from unstable
> gcc:2.7.2.2-4
> binutils: 2.8.1-1
> publib-dev: 0.26-1
> libc6: 2.0.3-4
>
> --- End of Repeated Message
obviously, C++ name mangling in all it's glory...
>
> Even if I include the library directly on the command line, it doesn't
> work:
>
> linda:~/cprogs$ g++ main.c /usr/lib/libpub.a
> /tmp/cca122331.o: In function `main':
> /tmp/cca122331.o(.text+0x2b): undefined reference to `strtrim(char *)'
> /tmp/cca122331.o(.text+0x3a): undefined reference to `strmtrim(char *)'
>
> but again, gcc finds it:
>
> linda:~/cprogs$ gcc main.c /usr/lib/libpub.a
> linda:~/cprogs$
>
> so it must be something different about the ways that gcc and g++ expect
> to find things in libraries???
yep...
gcc look for strtrim, while g++ looks for
something like strtrim$pc4
> Since the original message, I have tried loading the source of publib
> and recompiling it; this made no difference (there was no reason why
> it should, but I'm clutching at straws now...)
put
#ifdef __cplusplus
extern "C" {
#endif
#include
#ifdef __cplusplus
}
#endif
in your main.cc instead of #include
cheers
OK
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: g++ / ld / publib linking problem
On Thu, 10 Jul 1997, Oliver Elphick wrote:
> No-one has attempted an answer to this yet; if you have any ideas,
> please let me know!
>
Don't know what this publib stuff is (just running dpkg -S
/usr/include/publib [ah see, high-level functions]), but the problem is
shining from your description. The stanza
#ifdef __cplusplus
extern "C" {
#endif
from the beginning and the one
#ifdef __cplusplus
}
#endif
from the end of include files which are only C is missing.
As publib is a _C_ function library, I would not exactly call it as a bug.
You can add the stanzas to your c source around the #include line.
It is just C++ and strong type checking.
I hope you will go well learning those beatiful languages.
> When I try to compile this as C++:
> linda:~/cprogs$ g++ main.c -lpub
> /tmp/cca132571.o: In function `main':
> /tmp/cca132571.o(.text+0x2b): undefined reference to `strtrim(char *)'
> /tmp/cca132571.o(.text+0x3a): undefined reference to `strmtrim(char *)'
>
> but as C, it's fine:
> linda:~/cprogs$ gcc main.c -lpub
> linda:~/cprogs$
>
---
GNU GPL: csak tiszta forrásból
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: g++ targetcompali -> dos 8086 code?
If you get the GNU source you can build a cross-compiler, by specifying the right arguements to the configure script. I built a gcc that produced ELF binaries for Linux on a SprcStation that way... John Foster On Thu, 5 Jun 1997, Lars Hallberg wrote: > Hello > > Is it posably (whit debian packages) to targetcompile C++ code > for dos 8086 and 80286 targets? If not, is it posably under Linux > at all? > > I prefere g++ or a g++ relative but if that is not possably > anything goes (even commersial). > > If not again, is anyone runing an dos C++ compiler succesfully > under DOSEMU? Or just know about a dos C++ compiler that can > produce 8086 code and is more upp to date then the Borland > Turbo C++ 3.0 > > TIA /Lars > > -- >/ / _/_ _/_ Lars Hallberg IT-konsult Micro++ > /\_/\ / / www.micropp.se/lahwww.micropp.se > / Micro++OOP C++ WWW-Design Utbildning LINUX FreeWare > > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . > > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: g++ file doesn't run
Jeff Shilt wrote:
>Thanks for the help - it does compile with g++ instead of gcc, but the
>executable produced isn't d
>oing anything. Here's what i'm doing:
>
>//test.c
>#include
>
>main(){
> cout << "Hello there.";
>}
>
>The test file doesn't print out anything when I run it.
>
>Also, I was wondering if this was a descrepency in versions of gcc. The
>installaition I had befor
>e (using the main parts of the Slackware dist.) compiled both c and c++. Like
>somehow it knew whic
>h way to process it.
>
>
Don't call it "test" and don't end it in ".c". Try .cc or .CC or
even .C because the compiler will look at the extension.
g++ -o filename filename.cc
will name the exec. the same as the input w/o the .cc extension.
[EMAIL PROTECTED]/GNU--1.2---Linux--2.1.25---
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
A computer lets you make more mistakes faster than any other
invention, with the possible exceptions of handguns and Tequilla.
-- Mitch Ratcliffe
Re: g++ file doesn't run
>Thanks for the help - it does compile with g++ instead of gcc, but the
>executable produced isn't doing anything. Here's what i'm doing:
>
>//test.c
>#include
>
>main(){
> cout << "Hello there.";
>}
>
>The test file doesn't print out anything when I run it.
Append a \n to your string. Or include iomanip.h and use the "flush"
manipulator.
---
Benoit Goudreault-Emond
Reply to: [EMAIL PROTECTED]
My opinions are mine only and may not reflect those of my employer.
E-mail me to obtain my public PGP key.
Re: g++ file doesn't run
At 10:23 PM 3/21/97 -0500, Jeff Shilt wrote: >Thanks for the help - it does compile with g++ instead of gcc, but the executable produced isn't doing anything. Here's what i'm doing: > >//test.c Don't call it "test". -- Matt
Re: g++ file doesn't run
In message <[EMAIL PROTECTED]>, Hamish Moffatt writes
:
> On Mar 03, 1997 at 10:23:30PM -0500, Jeff Shilt wrote:
> > Thanks for the help - it does compile with g++ instead of gcc, but the exec
->utable produced isn't doing anything. Here's what i'm doing:
> >
> > //test.c
> > #include
> >
> > main(){
> > cout << "Hello there.";
> > }
> >
> > The test file doesn't print out anything when I run it.
>
> As I understand it, Unix terminal IO is buffered, so nothing will
> be written until a newline is sent. You never sent one, so all
> bets are off; the standards don't guarantee anything if you don't
> send at least one new line. (Similarly by default even character
> by character input won't see anything until the user presses return).
>
I think buffers are suposed to get flushed when a program terminates
normaly, but I would try this anyway if nofing else helps :) The other
sugestion on the list (another 'test' is run) is more likly. You can try
runing Your own 'test' by spesifying the path (./test).
/Lars
>
> Hamish
> --
> Hamish Moffatt, [EMAIL PROTECTED], Melbourne, Australia.
> Student, computer science & computer systems engineering. 3rd year, RMIT.
> http://yallara.cs.rmit.edu.au/~moffatt CPOM: [ ] 40%
> PGP key available from web page above.
>
Re: g++ file doesn't run
On Mar 03, 1997 at 10:23:30PM -0500, Jeff Shilt wrote:
> Thanks for the help - it does compile with g++ instead of gcc, but the
> executable produced isn't doing anything. Here's what i'm doing:
>
> //test.c
> #include
>
> main(){
> cout << "Hello there.";
> }
>
> The test file doesn't print out anything when I run it.
As I understand it, Unix terminal IO is buffered, so nothing will
be written until a newline is sent. You never sent one, so all
bets are off; the standards don't guarantee anything if you don't
send at least one new line. (Similarly by default even character
by character input won't see anything until the user presses return).
Try
#include
main()
{
cout << "Hello there." << endl;
}
You would theoretically get no output from
#include
main()
{
printf("Hello there.");
}
either. I haven't checked though.
Hamish
--
Hamish Moffatt, [EMAIL PROTECTED], Melbourne, Australia.
Student, computer science & computer systems engineering. 3rd year, RMIT.
http://yallara.cs.rmit.edu.au/~moffatt CPOM: [ ] 40%
PGP key available from web page above.
Re: g++ file doesn't run
On Fri, 21 Mar 1997, Jeff Shilt wrote: > //test.c > > The test file doesn't print out anything when I run it. try typing 'which test' and find out what program your really running then type 'man test' to see what it does. Then give your program a new name. Time flies like arrows, but fruit flies like bananas Perry Piplanihttp://perrypip.netservers.com [EMAIL PROTECTED] http://www.netservers.com
Re: g++ undefined reference to '__getfpucw'
> > Hello, > > > I am still Debian1.1 - compiling a C++ program, which used to > compile cleanly only a few weeks ago, gives me the following > error message: > /lib/libm.so.5: undefined reference to '__getfpucw' Well, if you are pure Debian-1.1, and didn't upgrade anything between "a few weeks ago" and now, then you clearly need to check your computer. But, if you did upgrade gcc/libc5_5.4.13, then, yes, you should install the new libg++ libs (although I've never heard of the trouble you are refering to). > > Do I need to upgrade any libraries ? > Can anybody help me sort this out please ? Not without a (small) sample of the code that doens't link -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: g
This may be way off, but some of us have trouble loading Linux from floppy if the cache is turned on. Try turning off cache and see if the problem goes away. Typically, the cache issue shows up while the kernel is being decompressed, not during the initial boot. The solution given below by Heiko is more likely the correct one. Chris -)- On Sep 26, 10:51am, Heiko Schlittermann wrote: > Subject: g : d. mashao wrote: : : : : I am trying to upgrade from linux kernel 1.2.1 (Unifix 1.6) to : : either Debian or Slackware. I have been persuaded by all this talk : : about Debian system. : : nice. : : : I followed the instructions on making floppies but unfortunately the : : process stops after reading the boot disk with the error message: : : Loading ... Boot failed: Change disks and press any key : : Reads as if your floppy disk is demaged. Make a _new_ boot floppy. >-- End of excerpt from Heiko Schlittermann -- Christopher R. Hertel -)- University of Minnesota [EMAIL PROTECTED] Networking and Telecommunications Services
