public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: gcc problem
@ 2001-09-21 12:10 mike stump
  0 siblings, 0 replies; 18+ messages in thread
From: mike stump @ 2001-09-21 12:10 UTC (permalink / raw)
  To: gcc, lmskhout

> From: mouhcin chergou <lmskhout@caramail.com>
> To: gcc-help@gcc.gnu.org, gcc@gcc.gnu.org
> Date: Fri, 21 Sep 2001 03:01:44 GMT+1

> My problem is that everytime I want to run my program, it gives a
> segmentation fault message...  Would you please help me ASAP!!

gcc is the wrong list for such questions.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: gcc problem
  2001-10-22  3:03 Bernd Stuby
@ 2001-11-01  5:58 ` Alexandre Oliva
  0 siblings, 0 replies; 18+ messages in thread
From: Alexandre Oliva @ 2001-11-01  5:58 UTC (permalink / raw)
  To: Bernd Stuby; +Cc: gcc

On Oct 22, 2001, Bernd Stuby <stuby@danet.de> wrote:

> Is it possible that I need a GAS and Gnu Linker on the Digital System,
> too ?

Yup.  You're running into a limitation of the bundled assembler.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

^ permalink raw reply	[flat|nested] 18+ messages in thread

* gcc problem
@ 2001-10-22  3:03 Bernd Stuby
  2001-11-01  5:58 ` Alexandre Oliva
  0 siblings, 1 reply; 18+ messages in thread
From: Bernd Stuby @ 2001-10-22  3:03 UTC (permalink / raw)
  To: gcc

Hello, 

I tried to compile some C++ Code on a Digital Unix v4.0f alpha System
with gcc 2.95

The compilation of the same code went right on a Linux System using gcc
2.95.2 gas 2.95 and gnu ld 2.95

On the Digital Unix System the compilation fails and produces something
like that in the attached output.

Is it possible that I need a GAS and Gnu Linker on the Digital System,
too ?
Or can this have other reasons. Please help me because it is very
urgent.

Thanks and best regards,

-- Bernd
 
------------------------------------------------------------------------------
Bernd Stuby                     Phone: +49-711/13353-46
D A N E T - IS GmbH             FAX:+49-711/13353-53
Waldburgstrasse 17 - 19         Email: stuby@danet.de

D-70563 Stuttgart               http://www.danet.de
g++ -Iinc/ -Isrc/ -Wall  -DARRAY_FETCH   -c -g src/main.cc -o obj/main.o
mips-tfile, /tmp/cc6oAgbT.s:371 String too big (4309 bytes)
line:	 #.stabs "end::1626:t8_Rb_tree5Z9IpAddressZt4pair2ZC9IpAddressZt3map4ZUlZt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1ZUlZt9allocator1Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt10_Select1st1Zt4pair2ZC9IpAddressZt3map4ZUlZt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1ZUlZt9allocator1Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1Z9IpAddressZt9allocator1Zt3map4ZUlZt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1ZUlZt9allocator1Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0;2A.1627:t8_Rb_tree5Z9IpAddressZt4pair2ZC9IpAddressZt3map4ZUlZt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1ZUlZt9allocator1Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt10_Select1st1Zt4pair2ZC9IpAddressZt3map4ZUlZt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1ZUlZt9allocator1Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1Z9IpAddressZt9allocator1Zt3map4ZUlZt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1ZUlZt9allocator1Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0;2B.;rbegin::1629=##1630=xsreverse_iterator<_Rb_tree_iterator<pair<const IpAddress,map<long unsigned int,basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> >,less<long unsigned int>,allocator<basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> > > > >,pair<const IpAddress,map<long unsigned int,basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> >,less<long unsigned int>,allocator<basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> > > > > &,pair<const IpAddress,map<long unsigned int,basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> >,less<long unsigned int>,allocator<basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> > > > > *> >:;:t8_Rb_tree5Z9IpAddressZt4pair2ZC9IpAddressZt3map4ZUlZt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1ZUlZt9allocator1Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt10_Select1st1Zt4pair2ZC9IpAddressZt3map4ZUlZt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1ZUlZt9allocator1Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1Z9IpAddressZt9allocator1Zt3map4ZUlZt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1ZUlZt9allocator1Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0;2A.1631=##1632=xsreverse_iterator<_Rb_tree_iterator<pair<const IpAddress,map<long unsigned int,basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> >,less<long unsigned int>,allocator<basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> > > > >,const pair<const IpAddress,map<long unsigned int,basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> >,less<long unsigned int>,allocator<basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> > > > > &,const pair<const IpAddress,map<long unsigned int,basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> >,less<long unsigned int>,allocator<basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> > > > > *> >:;:t8_Rb_tree5Z9IpAddressZt4pair2ZC9IpAddressZt3map4ZUlZt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1ZUlZt9allocator1Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt10_Select1st1Zt4pair2ZC9IpAddressZt3map4ZUlZt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1ZUlZt9allocator1Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1Z9IpAddressZt9allocator1Zt3map4ZUlZt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1ZUlZt9allocator1Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0;2B.;\\",128,0,0,0

make: *** [obj/main.o] Fehler 1

^ permalink raw reply	[flat|nested] 18+ messages in thread

* gcc problem
@ 2001-09-20 18:01 mouhcin chergou
  0 siblings, 0 replies; 18+ messages in thread
From: mouhcin chergou @ 2001-09-20 18:01 UTC (permalink / raw)
  To: gcc-help, gcc

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 264 bytes --]

Hi there,
My problem is that everytime I want to run my program, it
gives a segmentation fault message...
Would you please help me ASAP!!
Thanks
_________________________________________________________
Le journal des abonnés Caramail - http://www.carazine.com

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: gcc problem
  2001-07-09  5:23 Rick Roland
  2001-07-09  5:38 ` Andreas Jaeger
@ 2001-07-09  5:41 ` Erik Mouw
  1 sibling, 0 replies; 18+ messages in thread
From: Erik Mouw @ 2001-07-09  5:41 UTC (permalink / raw)
  To: Rick Roland; +Cc: 'gcc@gcc.gnu.org'

On Mon, Jul 09, 2001 at 02:23:29PM +0200, Rick Roland wrote:
> Compiling the very simple attached test.c using gcc generates the error
> message below, where g++ does not, what I do really not understand.
>  
> $ gcc test.c
> Undefined                       first referenced
>  symbol                             in file
> atan                                /var/tmp/cc2qkIFV.o
> ld: fatal: Symbol referencing errors. No output written to a.out
> collect2: ld returned 1 exit status
>  
> Here my LD_LIBRARY_PATH and PATH:
>  
> $ echo $LD_LIBRARY_PATH
> /usr/local/lib:/usr/lib/:/usr/dt/lib:/usr/openwin/lib:/usr/ucblib:/opt/gnu/l
> ib:/opt/SUNWspro/lib:/usr/
> local/include
>  
> $ echo $PATH
> /usr/local/bin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/ucb:/usr/openwin/bin:/usr/
> dt/bin:/opt/SUNWspro/bin:/
> usr/ccs/bin:/opt/SUNWfw/clients/bin:.:/opt/netscape:/opt/appl/bin
>  
> Quite interessting: The gcc compiles the attached bonnie.c without any
> errors or warnings.
>  
> Please can you help, explain or give any hint?

Link with the math library, so use "gcc test.c -lm". G++ links with -lm
by default.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: gcc problem
  2001-07-09  5:23 Rick Roland
@ 2001-07-09  5:38 ` Andreas Jaeger
  2001-07-09  5:41 ` Erik Mouw
  1 sibling, 0 replies; 18+ messages in thread
From: Andreas Jaeger @ 2001-07-09  5:38 UTC (permalink / raw)
  To: Rick Roland; +Cc: 'gcc@gcc.gnu.org'

Rick Roland <roland.rick@lgt.com> writes:

> Hi GCC team
>  
> Compiling the very simple attached test.c using gcc generates the error
> message below, where g++ does not, what I do really not understand.
>  
> $ gcc test.c
> Undefined                       first referenced
>  symbol                             in file
> atan                                /var/tmp/cc2qkIFV.o
> ld: fatal: Symbol referencing errors. No output written to a.out
> collect2: ld returned 1 exit status

This is not a bug in GCC but in your usage of GCC.

You have to add -lm, atan is part of libm.

Btw. please don't send html enhanced emails,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

^ permalink raw reply	[flat|nested] 18+ messages in thread

* gcc problem
@ 2001-07-09  5:23 Rick Roland
  2001-07-09  5:38 ` Andreas Jaeger
  2001-07-09  5:41 ` Erik Mouw
  0 siblings, 2 replies; 18+ messages in thread
From: Rick Roland @ 2001-07-09  5:23 UTC (permalink / raw)
  To: 'gcc@gcc.gnu.org'

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

Title: 



----------------------------------------------------------------------
LGT Bank in Liechtenstein    Tel.: ++423 235 11 22
Aktiengesellschaft           Fax : ++423 235 15 22
Herrengasse 12               Mail: mailto:info@lgt.com
FL-9490 Vaduz                Web : http://www.lgt.com
Fuerstentum Liechtenstein
----------------------------------------------------------------------
Privileged/Confidential Information may be contained in this message.
If you are not the addressee indicated in this message (or responsible
for delivery of the message to such person), you may not copy or
deliver this message to anyone. In such case, you should destroy this
message and kindly notify the sender by reply email. Please advise
immediately if you or your employer does not consent to Internet email
for messages of this kind. Opinions, conclusions and other information
in this message that do not relate to the official business of my firm
shall be understood as neither given nor endorsed by it.
-----------------------------------------------------------------------




test.c
bonnie.c


[-- Attachment #2: bonnie.c --]
[-- Type: text/x-c, Size: 19974 bytes --]

/*
 * This is a file system benchmark which attempts to study bottlenecks -
 * it is named 'bonnie' for semi-obvious reasons.
 *
 * Specifically, these are the types of filesystem activity that have been
 * observed to be bottlenecks in I/O-intensive applications, in particular
 * the text database work done in connection with the New Oxford English
 * Dictionary Project at the University of Waterloo.
 * 
 * It performs a series of tests on a file of known size.  By default, that
 * size is 100 Mb (but that's not enough - see below).  For each test, bonnie 
 * reports the bytes processed per elapsed second, per CPU second, and the 
 * % CPU usage (user and system).
 * 
 * In each case, an attempt is made to keep optimizers from noticing it's 
 * all bogus.  The idea is to make sure that these are real transfers to/from
 * user space to the physical disk.  The tests are:
 * 
 * 1. Sequential Output
 * 
 * 1.1 Per-Character.  The file is written using the putc() stdio macro.
 * The loop that does the writing should be small enough to fit into any
 * reasonable I-cache.  The CPU overhead here is that required to do the
 * stdio code plus the OS file space allocation.
 * 
 * 1.2 Block.  The file is created using write(2).  The CPU overhead
 * should be just the OS file space allocation.
 * 
 * 1.3 Rewrite.  Each BUFSIZ of the file is read with read(2), dirtied, and
 * rewritten with write(2), requiring an lseek(2).  Since no space
 * allocation is done, and the I/O is well-localized, this should test the
 * effectiveness of the filesystem cache and the speed of data transfer.
 * 
 * 2. Sequential Input
 * 
 * 2.1 Per-Character.  The file is read using the getc() stdio macro.  Once
 * again, the inner loop is small.  This should exercise only stdio and
 * sequential input.
 * 
 * 2.2 Block.  The file is read using read(2).  This should be a very pure
 * test of sequential input performance.
 * 
 * 3. Random Seeks
 * 
 * This test runs SeekProcCount processes in parallel, doing a total of
 * 4000 lseek()s to locations in the file specified by random() in bsd systems,
 * drand48() on sysV systems.  In each case, the block is read with read(2).  
 * In 10% of cases, it is dirtied and written back with write(2).
 *
 * The idea behind the SeekProcCount processes is to make sure there's always 
 * a seek queued up.
 * 
 * AXIOM: For any unix filesystem, the effective number of lseek(2) calls
 * per second declines asymptotically to near 30, once the effect of
 * caching is defeated.
 * 
 * The size of the file has a strong nonlinear effect on the results of
 * this test.  Many Unix systems that have the memory available will make
 * aggressive efforts to cache the whole thing, and report random I/O rates
 * in the thousands per second, which is ridiculous.  As an extreme
 * example, an IBM RISC 6000 with 64 Mb of memory reported 3,722 per second
 * on a 50 Mb file.  Some have argued that bypassing the cache is artificial
 * since the cache is just doing what it's designed to.  True, but in any 
 * application that requires rapid random access to file(s) significantly
 * larger than main memory which is running on a system which is doing
 * significant other work, the caches will inevitably max out.  There is
 * a hard limit hiding behind the cache which has been observed by the
 * author to be of significant import in many situations - what we are trying
 * to do here is measure that number.
 *
 * COPYRIGHT NOTICE: 
 * Copyright (c) Tim Bray, 1990.
 * Everybody is hereby granted rights to use, copy, and modify this program, 
 *  provided only that this copyright notice and the disclaimer below
 *  are preserved without change.
 * DISCLAIMER:
 * This program is provided AS IS with no warranty of any kind, and
 * The author makes no representation with respect to the adequacy of this
 *  program for any particular purpose or with respect to its adequacy to 
 *  produce any particular result, and
 * The author shall not be liable for loss or damage arising out of
 *  the use of this program regardless of how sustained, and
 * In no event shall the author be liable for special, direct, indirect
 *  or consequential damage, loss, costs or fees or expenses of any
 *  nature or kind.
 */

#include <stdio.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/time.h>
#ifdef SysV
#include <limits.h>
#include <sys/times.h>
#else
#include <sys/resource.h>
#endif

#define IntSize (4)

/*
 * N.B. in seeker_reports, CPU appears and Start/End time, but not Elapsed,
 *  so position 1 is re-used; icky data coupling.
 */
#define CPU (0)
#define Elapsed (1)
#define StartTime (1)
#define EndTime (2)
#define Seeks (4000)
#define UpdateSeek (10)
#define SeekProcCount (3)
#define Chunk (8192)

static double	cpu_so_far();
static void   doseek();
static void   get_delta_t();
static void   io_error();
static void   newfile();
#ifdef SysV
static long	random();
static void   srandom();
#endif
static void   report();
static double	time_so_far();
static void   timestamp();
static void   usage();

typedef enum
{
	Putc,
	ReWrite,
	FastWrite,
	Getc,
	FastRead,
	Lseek,
	TestCount
} 


tests_t;

static int	basetime;
static double	delta[(int) TestCount][2];
static char	*machine = "";
static double	last_cpustamp = 0.0;
static double	last_timestamp = 0.0;
static int	do_kilo = 0;

main(argc, argv)
int	argc;
char	*argv[];
{
	int	buf[Chunk / IntSize];
	int	bufindex;
	int	chars[256];
	int	child;
	char	*dir;
	int	fd;
	double	first_start;
	double	last_stop;
	int	lseek_count = 0;
	char	name[Chunk];
	int	next;
	int	seek_control[2];
	int	seek_feedback[2];
	char	seek_tickets[Seeks + SeekProcCount];
	double	seeker_report[3];
	int	size;
	FILE * stream;
	int	words;

	fd = -1;
	basetime = (int) time((time_t * ) NULL);
	size = 100;
	dir = ".";

	for (next = 1; next < argc - 1; next++)
	{
		if (argv[next][0] == '-') { /* option? */
			if (strcmp(argv[next] + 1, "d") == 0)
				dir = argv[next + 1];
			else if (strcmp(argv[next] + 1, "s") == 0)
				size = atoi(argv[next + 1]);
			else if (strcmp(argv[next] + 1, "m") == 0)
				machine = argv[next + 1];
			else if (strcmp(argv[next] + 1, "k") == 0)
				do_kilo = atoi(argv[next + 1]); 
			else
				usage();
			next++;
		} /* option? */
		else
			usage();
	} // for

	if (size < 1)
		usage();
	size *= (1024 * 1024);
	sprintf(name, "%s/bonnie.%d", dir, getpid());
	fprintf(stderr, "File '%s', size: %d\n", name, size);

	/* Fill up a file, writing it a char at a time with the stdio putc() call */
	fprintf(stderr, "Writing with putc()...");
	newfile(name, &fd, &stream, 1);
	timestamp();
	for (words = 0; words < size; words++)
		if (putc(words & 0x7f, stream) == EOF)
			io_error("putc");

	/*
   * note that we always close the file before measuring time, in an
   *  effort to force as much of the I/O out as we can
   */
	if (fclose(stream) == -1)
		io_error("fclose after putc");
	get_delta_t(Putc);
	fprintf(stderr, "done\n");

	/* Now read & rewrite it using block I/O.  Dirty one word in each block */
	newfile(name, &fd, &stream, 0);
	if (lseek(fd, (off_t) 0, 0) == (off_t) - 1)
		io_error("lseek(2) before rewrite");
	fprintf(stderr, "Rewriting...");
	timestamp();
	bufindex = 0;
	if ((words = read(fd, (char *) buf, Chunk)) == -1)
		io_error("rewrite read");
	while (words == Chunk) { /* while we can read a block */
		if (bufindex == Chunk / IntSize)
			bufindex = 0;
		buf[bufindex++]++;
		if (lseek(fd, (off_t) - words, 1) == -1)
			io_error("relative lseek(2)");
		if (write(fd, (char *) buf, words) == -1)
			io_error("re write(2)");
		if ((words = read(fd, (char *) buf, Chunk)) == -1)
			io_error("rwrite read");
	} /* while we can read a block */
	if (close(fd) == -1)
		io_error("close after rewrite");
	get_delta_t(ReWrite);
	fprintf(stderr, "done\n");

	/* Write the whole file from scratch, again, with block I/O */
	newfile(name, &fd, &stream, 1);
	fprintf(stderr, "Writing intelligently...");
	for (words = 0; words < Chunk / IntSize; words++)
		buf[words] = 0;
	timestamp();
	for (words = bufindex = 0; words < (size / Chunk); words++) { /* for each word */
		if (bufindex == (Chunk / IntSize))
			bufindex = 0;
		buf[bufindex++]++;
		if (write(fd, (char *) buf, Chunk) == -1)
			io_error("write(2)");
	} /* for each word */
	if (close(fd) == -1)
		io_error("close after fast write");
	get_delta_t(FastWrite);
	fprintf(stderr, "done\n");

	/* read them all back with getc() */
	newfile(name, &fd, &stream, 0);
	for (words = 0; words < 256; words++)
		chars[words] = 0;
	fprintf(stderr, "Reading with getc()...");
	timestamp();
	for (words = 0; words < size; words++) { /* for each byte */
		if ((next = getc(stream)) == EOF)
			io_error("getc(3)");

		/* just to fool optimizers */
		chars[next]++;
	} /* for each byte */
	if (fclose(stream) == -1)
		io_error("fclose after getc");
	get_delta_t(Getc);
	fprintf(stderr, "done\n");

	/* use the frequency count */
	for (words = 0; words < 256; words++)
		sprintf((char *) buf, "%d", chars[words]);

	/* Now suck it in, Chunk at a time, as fast as we can */
	newfile(name, &fd, &stream, 0);
	if (lseek(fd, (off_t) 0, 0) == -1)
		io_error("lseek before read");
	fprintf(stderr, "Reading intelligently...");
	timestamp();
	do
	 { /* per block */
		if ((words = read(fd, (char *) buf, Chunk)) == -1)
			io_error("read(2)");
		chars[buf[abs(buf[0]) % (Chunk / IntSize)] & 0x7f]++;
	} /* per block */ while (words);
	if (close(fd) == -1)
		io_error("close after read");
	get_delta_t(FastRead);
	fprintf(stderr, "done\n");

	/* use the frequency count */
	for (words = 0; words < 256; words++)
		sprintf((char *) buf, "%d", chars[words]);

	/*
   * Now test random seeks; first, set up for communicating with children.
   * The object of the game is to do "Seeks" lseek() calls as quickly
   *  as possible.  So we'll farm them out among SeekProcCount processes.
   *  We'll control them by writing 1-byte tickets down a pipe which
   *  the children all read.  We write "Seeks" bytes with val 1, whichever
   *  child happens to get them does it and the right number of seeks get
   *  done.
   * The idea is that since the write() of the tickets is probably
   *  atomic, the parent process likely won't get scheduled while the
   *  children are seeking away.  If you draw a picture of the likely
   *  timelines for three children, it seems likely that the seeks will
   *  overlap very nicely with the process scheduling with the effect
   *  that there will *always* be a seek() outstanding on the file.
   * Question: should the file be opened *before* the fork, so that
   *  all the children are lseeking on the same underlying file object?
   */
	if (pipe(seek_feedback) == -1 || pipe(seek_control) == -1)
		io_error("pipe");
	for (next = 0; next < Seeks; next++)
		seek_tickets[next] = 1;
	for ( ; next < (Seeks + SeekProcCount); next++)
		seek_tickets[next] = 0;

	/* launch some parallel seek processes */
	for (next = 0; next < SeekProcCount; next++) { /* for each seek proc */
		if ((child = fork()) == -1)
			io_error("fork");
		else if (child == 0) { /* child process */

			/* set up and wait for the go-ahead */
			close(seek_feedback[0]);
			close(seek_control[1]);
			newfile(name, &fd, &stream, 0);
			srandom(getpid());
			fprintf(stderr, "Seeker %d...", next + 1);

			/* wait for the go-ahead */
			if (read(seek_control[0], seek_tickets, 1) != 1)
				io_error("read ticket");
			timestamp();
			seeker_report[StartTime] = time_so_far();

			/* loop until we read a 0 ticket back from our parent */
			while (seek_tickets[0]) { /* until Mom says stop */
				doseek((long) (random() % size), fd,
				    ((lseek_count++ % UpdateSeek) == 0));
				if (read(seek_control[0], seek_tickets, 1) != 1)
					io_error("read ticket");
			} /* until Mom says stop */
			if (close(fd) == -1)
				io_error("close after seek");

			/* report to parent */
			get_delta_t(Lseek);
			seeker_report[EndTime] = time_so_far();
			seeker_report[CPU] = delta[(int) Lseek][CPU];
			if (write(seek_feedback[1], seeker_report, sizeof(seeker_report))
			     != sizeof(seeker_report))
				io_error("pipe write");
			exit(0);
		} /* child process */
	} /* for each seek proc */

	/*
	 * Back in the parent; in an effort to ensure the children get an even
	 *  start, wait a few seconds for them to get scheduled, open their
	 *  files & so on.
	 */
	close(seek_feedback[1]);
	close(seek_control[0]);
	sleep(5);
	fprintf(stderr, "start 'em...");
	if (write(seek_control[1], seek_tickets, sizeof(seek_tickets))
	     != sizeof(seek_tickets))
		io_error("write tickets");

	/* read back from children */
	for (next = 0; next < SeekProcCount; next++) { /* for each child */
		if (read(seek_feedback[0], (char *) seeker_report, sizeof(seeker_report))
		     != sizeof(seeker_report))
			io_error("pipe read");

		/*
		 * each child writes back its CPU, start & end times.  The
		 * elapsed time to do all the seeks is the time the first child
		 * started until the time the last child stopped
		 */
		delta[(int) Lseek][CPU] += seeker_report[CPU];
		if (next == 0) { /* first time */
			first_start = seeker_report[StartTime];
			last_stop = seeker_report[EndTime];
		} /* first time */ else
		 { /* not first time */
			first_start = (first_start < seeker_report[StartTime]) ? 
			    first_start : seeker_report[StartTime];
			last_stop = (last_stop > seeker_report[EndTime]) ? 
			    last_stop : seeker_report[EndTime];
		} /* not first time */
		if (wait(&child) == -1)
			io_error("wait");
		fprintf(stderr, "done...");
	} /* for each child */
	fprintf(stderr, "\n");
	delta[(int) Lseek][Elapsed] = last_stop - first_start;

	report(size);
	unlink(name);
}


static void
report(size)
int	size;
{

	printf("              ");
	printf(
	    "-------Sequential Output-------- ---Sequential Input-- --Random--\n");
	printf("              ");
	printf(
	    "-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---\n");
	printf("Machine    MB ");

	if (do_kilo)
	{
//		printf("K/sec %%CPU K/sec %%CPU K/sec %%CPU K/sec %%CPU K/sec ");
//		printf("%%CPU  /sec %%CPU\n");
		printf("K/sec  CPU K/sec  CPU K/sec  CPU K/sec  CPU K/sec ");
		printf(" CPU  /sec  CPU\n");

		printf("%-8.8s %4d ", machine, size / (1024 * 1024));

		printf("%5d %4.1f %5d %4.1f %5d %4.1f ",
			 (int) (((double) size) / (delta[(int) Putc][Elapsed] * 1024.0)),
			 delta[(int) Putc][CPU] / delta[(int) Putc][Elapsed] * 100.0 / 100.0,
			 (int) (((double) size) / (delta[(int) FastWrite][Elapsed] * 1024.0)),
			 delta[(int) FastWrite][CPU] / delta[(int) FastWrite][Elapsed] * 100.0 / 100.0,
			 (int) (((double) size) / (delta[(int) ReWrite][Elapsed] * 1024.0)),
			 delta[(int) ReWrite][CPU] / delta[(int) ReWrite][Elapsed] * 100.0 / 100.0);
		printf("%5d %4.1f %5d %4.1f ",
			 (int) (((double) size) / (delta[(int) Getc][Elapsed] * 1024.0)),
			 delta[(int) Getc][CPU] / delta[(int) Getc][Elapsed] * 100.0 / 100.0,
			 (int) (((double) size) / (delta[(int) FastRead][Elapsed] * 1024.0)),
			 delta[(int) FastRead][CPU] / delta[(int) FastRead][Elapsed] * 100.0 / 100.0);
		printf("%5.1f %4.1f\n",
			 ((double) Seeks) / delta[(int) Lseek][Elapsed],
			 delta[(int) Lseek][CPU] / delta[(int) Lseek][Elapsed] * 100.0 / 100.0);
	}
	else
	{
//		printf("M/sec %%CPU M/sec %%CPU M/sec %%CPU M/sec %%CPU M/sec ");
//		printf("%%CPU K/sec %%CPU\n");
		printf("M/sec  CPU M/sec  CPU M/sec  CPU M/sec  CPU M/sec ");
		printf(" CPU K/sec  CPU\n");

		printf("%-8.8s %4d ", machine, size / (1024 * 1024));

		printf("%5.1f %4.2f %5.1f %4.2f %5.1f %4.2f ",
			 (((double) size) / (delta[(int) Putc][Elapsed] * 1024.0 * 1024)),
			 delta[(int) Putc][CPU] / delta[(int) Putc][Elapsed] * 100.0 / 100.0,
			 (((double) size) / (delta[(int) FastWrite][Elapsed] * 1024.0 * 1024)),
			 delta[(int) FastWrite][CPU] / delta[(int) FastWrite][Elapsed] * 100.0 / 100.0,
			 (((double) size) / (delta[(int) ReWrite][Elapsed] * 1024.0 * 1024)),
			 delta[(int) ReWrite][CPU] / delta[(int) ReWrite][Elapsed] * 100.0 / 100.0);
		printf("%5.1f %4.2f %5.1f %4.2f ",
			 (((double) size) / (delta[(int) Getc][Elapsed] * 1024.0 * 1024)),
			 delta[(int) Getc][CPU] / delta[(int) Getc][Elapsed] * 100.0 / 100.0,
			 (((double) size) / (delta[(int) FastRead][Elapsed] * 1024.0 * 1024)),
			 delta[(int) FastRead][CPU] / delta[(int) FastRead][Elapsed] * 100.0 / 100.0);
		printf("%5.1f %4.1f\n",
			 ((double) Seeks) / delta[(int) Lseek][Elapsed] / 1024,
			 delta[(int) Lseek][CPU] / delta[(int) Lseek][Elapsed] * 100.0 / 100.0);
	}

}


static void
newfile(name, fd, stream, create)
char	*  name;
int	*   fd;
FILE **stream;
int	create;
{
	if (create) { /* create from scratch */
		if (unlink(name) == -1 && *fd != -1)
			io_error("unlink");
		*fd = open(name, O_RDWR | O_CREAT | O_EXCL, 0777);
	} /* create from scratch */ else
		*fd = open(name, O_RDWR, 0777);

	if (*fd == -1)
		io_error(name);
	*stream = fdopen(*fd, "r+");
	if (*stream == NULL)
		io_error("fdopen");
}


static void
usage()
{
	fprintf(stderr,
	    "usage: bonnie [-d scratch-dir] [-s size-in-Mb] [-m machine-label]\n");
	exit(1);
}


static void
timestamp()
{
	last_timestamp = time_so_far();
	last_cpustamp = cpu_so_far();
}


static void 
get_delta_t(test)
tests_t test;
{
	int	which = (int) test;

	delta[which][Elapsed] = time_so_far() - last_timestamp;
	delta[which][CPU] = cpu_so_far() - last_cpustamp;
}


static double	
cpu_so_far()
{
#ifdef SysV
	struct tms tms;

	if (times(&tms) == -1)
		io_error("times");
	return ((double) tms.tms_utime) / ((double) CLK_TCK) + 
	    ((double) tms.tms_stime) / ((double) CLK_TCK);

#else
	struct rusage rusage;

	getrusage(RUSAGE_SELF, &rusage);
	return
	    ((double) rusage.ru_utime.tv_sec) + 
	    (((double) rusage.ru_utime.tv_usec) / 1000000.0) + 
	    ((double) rusage.ru_stime.tv_sec) + 
	    (((double) rusage.ru_stime.tv_usec) / 1000000.0);
#endif
}


static double	
time_so_far()
{
#ifdef SysV
	int	val;
	struct tms tms;

	if ((val = times(&tms)) == -1)
		io_error("times");

	return ((double) val) / ((double) CLK_TCK);

#else
	struct timeval tp;

	if (gettimeofday(&tp, (struct timezone *) NULL) == -1)
		io_error("gettimeofday");
	return ((double) (tp.tv_sec - basetime)) + 
	    (((double) tp.tv_usec) / 1000000.0);
#endif
}


static void
io_error(message)
char	*message;
{
	char	buf[Chunk];

	sprintf(buf, "bonnie: drastic I/O error (%s)", message);
	perror(buf);
	exit(1);
}


/*
 * Do a typical-of-something random I/O.  Any serious application that
 *  has a random I/O bottleneck is going to be smart enough to operate
 *  in a page mode, and not stupidly pull individual words out at
 *  odd offsets.  To keep the cache from getting too clever, some
 *  pages must be updated.  However an application that updated each of
 *  many random pages that it looked at is hard to imagine.  
 * However, it would be wrong to put the update percentage in as a
 *  parameter - the effect is too nonlinear.  Need a profile
 *  of what Oracle or Ingres or some such actually does.
 * Be warned - there is a *sharp* elbow in this curve - on a 1-Mb file,
 *  most substantial unix systems show >2000 random I/Os per second -
 *  obviously they've cached the whole thing and are just doing buffer
 *  copies.  
 */
static void 
doseek(where, fd, update)
long	where;
int	fd;
int	update;
{
	int	buf[Chunk / IntSize];
	off_t probe;
	int	size;

	probe = (where / Chunk) * Chunk;
	if (lseek(fd, probe, 0) != probe)
		io_error("lseek in doseek");
	if ((size = read(fd, (char *) buf, Chunk)) == -1)
		io_error("read in doseek");

	/* every so often, update a block */
	if (update) { /* update this block */

		/* touch a word */
		buf[((int) random() % (size/IntSize - 2)) + 1]--;
		if (lseek(fd, (long) probe, 0) != probe)
			io_error("lseek in doseek update");
		if (write(fd, (char *) buf, size) == -1)
			io_error("write in doseek");
	} /* update this block */
}



#ifdef SysV
static char	randseed[32];

static void
srandom(seed)
int	seed;
{
	sprintf(randseed, "%06d", seed);
}


static long	
random()
{
	return nrand48(randseed);
}

#endif

[-- Attachment #3: test.c --]
[-- Type: text/x-c, Size: 100 bytes --]

#include <stdio.h>
#include <math.h>

int main(void)
{

	printf("\nPI = %1.30f\n\n", 4*atan(1));

}

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: GCC problem
  2001-05-04  9:36 GCC problem Fabio Pacione
@ 2001-05-04 11:47 ` Alexandre Oliva
  0 siblings, 0 replies; 18+ messages in thread
From: Alexandre Oliva @ 2001-05-04 11:47 UTC (permalink / raw)
  To: Fabio Pacione; +Cc: gcc

On May  4, 2001, Fabio Pacione <f.pacione@mclink.it> wrote:

> I've installed the binaries from the package gcc-2.95.3-sol26-sparc-local.
> I've modified the installation directory with the pkgadd -R command.
> When I try to compile some files the error message is :
> ld: fatal: file crt1.o: open failed: No such file or directory

That's because you've modified the installation directory.  You must
not do that with GCC up to 2.95.*.  GCC 3.0 should be more tolerant to
these changes.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

^ permalink raw reply	[flat|nested] 18+ messages in thread

* GCC problem
@ 2001-05-04  9:36 Fabio Pacione
  2001-05-04 11:47 ` Alexandre Oliva
  0 siblings, 1 reply; 18+ messages in thread
From: Fabio Pacione @ 2001-05-04  9:36 UTC (permalink / raw)
  To: gcc

Sorry for the disturb,
I'm new with gcc, and I've problem with the installation (I think).
I've installed the binaries from the package gcc-2.95.3-sol26-sparc-local.
I've modified the installation directory with the pkgadd -R command.
When I try to compile some files the error message is :
ld: fatal: file crt1.o: open failed: No such file or directory

The file is existent and readable from the users. The file is also in the
PATH.
Please help me.

Thanks in advance.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* GCC problem
@ 2001-05-04  9:31 Fabio Pacione
  0 siblings, 0 replies; 18+ messages in thread
From: Fabio Pacione @ 2001-05-04  9:31 UTC (permalink / raw)
  To: gcc

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

Title: GCC problem





Sorry for the disturb,
I'm new with gcc, and I've problem with the installation (I think).
I've installed the binaries from the package gcc-2.95.3-sol26-sparc-local. I've modified the installation directory with the pkgadd -R command.

When I try to compile some files the error message is :
ld: fatal: file crt1.o: open failed: No such file or directory


The file is existent and readable from the users. The file is also in the PATH.
Please help me.


Thanks in advance.


4 Fabio Pacione
        Divisione HI-TECH
      Te chnical Account Specialist

< Business Objects Italia S.p.A.    
        Via Mario Bianchini, 51 - 00142 Roma
         Tel. :   +39.06.51869.274
        Fax :   +39.06.51964097
         fpacione@businessobjects.com
         < < http://www.italy.businessobjects.com/ >> 





^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: gcc problem
  2001-02-06  0:05 gcc problem pradit.w
  2001-02-06  0:27 ` Zack Weinberg
@ 2001-02-06  4:59 ` Tim Prince
  1 sibling, 0 replies; 18+ messages in thread
From: Tim Prince @ 2001-02-06  4:59 UTC (permalink / raw)
  To: pradit.w, gcc

I would think that the first thing you should consider is that your messages about being out of disk space may be easier for you to
correct than for us.  Next, you should consider that only the people who set up Solaris binaries, not the people who maintain source
distributions, are likely to be able to help.
----- Original Message -----
From: "pradit.w" <pradit.w@cm-mahidol.com>
To: <gcc@gcc.gnu.org>
Sent: Tuesday, February 06, 2001 12:02 AM
Subject: gcc problem


> Dear Sir,
>     I try to add package gcc-2.95.2 (Solaris 7 intel platform). I got
> this error message that show on below.
>
> # pkgadd -d gcc-2.95*
>
> The following packages are available:
>   1  SMCgcc     gcc
>                 (i86pc) 2.95.2
>
> Select package(s) you wish to process (or 'all' to process
> all packages). (default: all) [?,??,q]: q
> # pkgadd -d gcc-2.95
> pkgadd: ERROR: attempt to process datastream failed
> cpio: Cannot write "reloc/lib/gcc-lib/i386-pc-solaris2.7/2.95.2/cc1obj",
> errno 2
> 8, No space left on device
> cpio: Cannot write


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: gcc problem
  2001-02-06  0:05 gcc problem pradit.w
@ 2001-02-06  0:27 ` Zack Weinberg
  2001-02-06  4:59 ` Tim Prince
  1 sibling, 0 replies; 18+ messages in thread
From: Zack Weinberg @ 2001-02-06  0:27 UTC (permalink / raw)
  To: pradit.w; +Cc: gcc

On Tue, Feb 06, 2001 at 03:02:33PM +0700, pradit.w wrote:
> Dear Sir,
>     I try to add package gcc-2.95.2 (Solaris 7 intel platform). I got
> this error message that show on below.

You did not get this package from us; we distribute only source code.
You should take your problems to the person who gave you this package.

However:

> cpio: Cannot write "reloc/lib/gcc-lib/i386-pc-solaris2.7/2.95.2/cc1obj",
> errno 28, No space left on device

This error message looks pretty conclusive to me.  Your disk is full.

zw

^ permalink raw reply	[flat|nested] 18+ messages in thread

* gcc problem
@ 2001-02-06  0:05 pradit.w
  2001-02-06  0:27 ` Zack Weinberg
  2001-02-06  4:59 ` Tim Prince
  0 siblings, 2 replies; 18+ messages in thread
From: pradit.w @ 2001-02-06  0:05 UTC (permalink / raw)
  To: gcc

Dear Sir,
    I try to add package gcc-2.95.2 (Solaris 7 intel platform). I got
this error message that show on below.

# pkgadd -d gcc-2.95*

The following packages are available:
  1  SMCgcc     gcc
                (i86pc) 2.95.2

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: q
# pkgadd -d gcc-2.95
pkgadd: ERROR: attempt to process datastream failed
    - open of <gcc-2.95> failed, errno=2
pkgadd: ERROR: could not process datastream from <gcc-2.95>
# pkgadd -d gcc-2.95*

The following packages are available:
  1  SMCgcc     gcc
                (i86pc) 2.95.2

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]:

Processing package instance <SMCgcc> from
</export/home/local/gcc-2.95.2-sol7-in
tel-local>

gcc
(i86pc) 2.95.2
cpio: Cannot write "reloc/lib/gcc-lib/i386-pc-solaris2.7/2.95.2/cc1obj",
errno 2
8, No space left on device
cpio: Cannot write
"reloc/lib/gcc-lib/i386-pc-solaris2.7/2.95.2/cc1plus", errno
28, No space left on device
cpio: Cannot write
"reloc/lib/gcc-lib/i386-pc-solaris2.7/2.95.2/chillrt0.o", err
no 28, No space left on device
cpio: Cannot write
"reloc/lib/gcc-lib/i386-pc-solaris2.7/2.95.2/collect2", errno
 28, No space left on device
cpio: Cannot write "reloc/lib/gcc-lib/i386-pc-solaris2.7/2.95.2/cpp",
errno 28,
No space left on device
cpio: Cannot write "reloc/lib/gcc-lib/i386-pc-solaris2.7/2.95.2/f771",
errno 28,
 No space left on device
cpio: Cannot write "reloc/lib/gcc-lib/i386-pc-solaris2.7/2.95.2/gmon.o",
errno 2
8, No space left on device
cpio: Cannot write
"reloc/lib/gcc-lib/i386-pc-solaris2.7/2.95.2/include/README",
 errno 28, No space left on device
cpio: Cannot write
"reloc/lib/gcc-lib/i386-pc-solaris2.7/2.95.2/include/assert.h
", errno 28, No space left on device
cpio: Cannot write ", errno 28,
cpio:

pkgadd: ERROR: attempt to process datastream failed
    - process </usr/bin/cpio -icdumD -C 512> failed, exit code 86
pkgadd: ERROR: unable to unpack datastream

Installation of <SMCgcc> failed (internal error).
No changes were made to the system.





Can you help me solve problem?

^ permalink raw reply	[flat|nested] 18+ messages in thread

* gcc problem
@ 2000-09-27  3:08 ceritandogan
  0 siblings, 0 replies; 18+ messages in thread
From: ceritandogan @ 2000-09-27  3:08 UTC (permalink / raw)
  To: 'gcc@gcc.gnu.org'

I am using RED HAT 6.2 and as C compiler (egcs-1.1.2).
there is no existing /usr/include/sys/access.h file.
Where may i find this file?
anybody can help me?

                                                    Thanks!

^ permalink raw reply	[flat|nested] 18+ messages in thread

* gcc problem
  1999-08-19 21:06 Juha Korpela
  1999-08-20  0:01 ` Jeffrey A Law
@ 1999-08-31 23:20 ` Juha Korpela
  1 sibling, 0 replies; 18+ messages in thread
From: Juha Korpela @ 1999-08-31 23:20 UTC (permalink / raw)
  To: hpux; +Cc: gcc

I have 

uname -a
HP-UX lutikka B.10.30 A 9000/712 2002399864 two-user license

lutikka ~> which gcc
/opt/gcc/bin/gcc

lutikka ~> gcc --version
2.8.1

lutikka /tmp/jkorpela/z/disk/hello> which as
/opt/binutils/bin/as

lutikka /tmp/jkorpela/z/disk/hello> as --version
GNU assembler 2.9.1
Copyright 1997 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `hppa1.1-hp-hpux10.20'.

I try to compile

lutikka /tmp/jkorpela/z/disk/hello> cat hello.cc 
#include <iostream.h>
int main()
{
    cout << "Hello World\n";
    return (0);
}

I get

lutikka /tmp/jkorpela/z/disk/hello> gcc -o hello hello.cc
as: "/tmp/jkorpela/cca02278.s", line 101: error 1052: Directive name not
recognized - NSUBSPA

What is this "Directive name not recognized - NSUBSPA" error? How to fix
it?

Also, is g++ the same as gcc? I did not find this script wrapper from HPUX
archieve.


Regards,


Juha Korpela
Carnegie Mellon University

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: gcc problem
  1999-08-20  0:01 ` Jeffrey A Law
@ 1999-08-31 23:20   ` Jeffrey A Law
  0 siblings, 0 replies; 18+ messages in thread
From: Jeffrey A Law @ 1999-08-31 23:20 UTC (permalink / raw)
  To: Juha Korpela; +Cc: hpux, gcc

  In message < Pine.HPX.4.05.9908192300310.1458-100000@lutikka.korpela.org >you w
  > lutikka /tmp/jkorpela/z/disk/hello> gcc -o hello hello.cc
  > as: "/tmp/jkorpela/cca02278.s", line 101: error 1052: Directive name not
  > recognized - NSUBSPA
  > 
  > What is this "Directive name not recognized - NSUBSPA" error? How to fix
  > it?
GCC is finding the HP assembler before the GNU assembler.  Please see the
GCC FAQ.  It covers this issue explicitly.
jeff

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: gcc problem
  1999-08-19 21:06 Juha Korpela
@ 1999-08-20  0:01 ` Jeffrey A Law
  1999-08-31 23:20   ` Jeffrey A Law
  1999-08-31 23:20 ` Juha Korpela
  1 sibling, 1 reply; 18+ messages in thread
From: Jeffrey A Law @ 1999-08-20  0:01 UTC (permalink / raw)
  To: Juha Korpela; +Cc: hpux, gcc

  In message < Pine.HPX.4.05.9908192300310.1458-100000@lutikka.korpela.org >you w
  > lutikka /tmp/jkorpela/z/disk/hello> gcc -o hello hello.cc
  > as: "/tmp/jkorpela/cca02278.s", line 101: error 1052: Directive name not
  > recognized - NSUBSPA
  > 
  > What is this "Directive name not recognized - NSUBSPA" error? How to fix
  > it?
GCC is finding the HP assembler before the GNU assembler.  Please see the
GCC FAQ.  It covers this issue explicitly.
jeff

^ permalink raw reply	[flat|nested] 18+ messages in thread

* gcc problem
@ 1999-08-19 21:06 Juha Korpela
  1999-08-20  0:01 ` Jeffrey A Law
  1999-08-31 23:20 ` Juha Korpela
  0 siblings, 2 replies; 18+ messages in thread
From: Juha Korpela @ 1999-08-19 21:06 UTC (permalink / raw)
  To: hpux; +Cc: gcc

I have 

uname -a
HP-UX lutikka B.10.30 A 9000/712 2002399864 two-user license

lutikka ~> which gcc
/opt/gcc/bin/gcc

lutikka ~> gcc --version
2.8.1

lutikka /tmp/jkorpela/z/disk/hello> which as
/opt/binutils/bin/as

lutikka /tmp/jkorpela/z/disk/hello> as --version
GNU assembler 2.9.1
Copyright 1997 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `hppa1.1-hp-hpux10.20'.

I try to compile

lutikka /tmp/jkorpela/z/disk/hello> cat hello.cc 
#include <iostream.h>
int main()
{
    cout << "Hello World\n";
    return (0);
}

I get

lutikka /tmp/jkorpela/z/disk/hello> gcc -o hello hello.cc
as: "/tmp/jkorpela/cca02278.s", line 101: error 1052: Directive name not
recognized - NSUBSPA

What is this "Directive name not recognized - NSUBSPA" error? How to fix
it?

Also, is g++ the same as gcc? I did not find this script wrapper from HPUX
archieve.


Regards,


Juha Korpela
Carnegie Mellon University

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2001-11-12  1:13 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-09-21 12:10 gcc problem mike stump
  -- strict thread matches above, loose matches on Subject: below --
2001-10-22  3:03 Bernd Stuby
2001-11-01  5:58 ` Alexandre Oliva
2001-09-20 18:01 mouhcin chergou
2001-07-09  5:23 Rick Roland
2001-07-09  5:38 ` Andreas Jaeger
2001-07-09  5:41 ` Erik Mouw
2001-05-04  9:36 GCC problem Fabio Pacione
2001-05-04 11:47 ` Alexandre Oliva
2001-05-04  9:31 Fabio Pacione
2001-02-06  0:05 gcc problem pradit.w
2001-02-06  0:27 ` Zack Weinberg
2001-02-06  4:59 ` Tim Prince
2000-09-27  3:08 ceritandogan
1999-08-19 21:06 Juha Korpela
1999-08-20  0:01 ` Jeffrey A Law
1999-08-31 23:20   ` Jeffrey A Law
1999-08-31 23:20 ` Juha Korpela

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).