| |
Hi all,
We are persisting with our build on solaris for legOS 0.2.2 things are getting
closer. We have sorted out the getopt.h problems by just copying the getopt.c
and getopt.h into the dll-src directory (because it is a known path for the
Makefile for dll-src). We will talk more with the sys admin at a later date
about where our copy of getopt.* has gone from /usr/include or wether Solaris
ever had it.
Anyhow we are now up against another problem. This time the culprit is
O_ASYNC. It seems that this is an undeclared identifier. What file does this
usually reside in from the bunch of .h includes in loader.c?? Here are two
Solaris captures to illustrate the problem
The first capture was taken using the original, "out of the box" loader.c the
second capture was taken after the following lines were added to loader.c at
line 48
#ifndef O_ASYNC
#define O_ASYNC FASYNC
#endif
---- Solaris capture (before redefinition) ----
frost-dll-src: ls
CVS convert.c keepalive.c loader.c rcxtty.c srec.h
Makefile getopt.c keepalive.h lx.c rcxtty.h srecload.c
config.h getopt.h lnp.c lx.h srec.c srecload.h
frost-dll-src: gmake
gcc -o loader.o -c loader.c -O2 -Wall -I/usr/include -I. -I../../include
loader.c: In function `LNPinit':
loader.c:224: `O_ASYNC' undeclared (first use in this function)
loader.c:224: (Each undeclared identifier is reported only once
loader.c:224: for each function it appears in.)
gmake: *** [loader.o] Error 1
---- end solaris capture ----
---- Solaris capture (after redefinition) ----
frost-dll-src: ls
CVS convert.c keepalive.c loader.c rcxtty.c srec.h
Makefile getopt.c keepalive.h lx.c rcxtty.h srecload.c
config.h getopt.h lnp.c lx.h srec.c srecload.h
frost-dll-src: make
gcc -o loader.o -c loader.c -O2 -Wall -I/usr/include -I. -I../../include
loader.c: In function `LNPinit':
loader.c:224: `FASYNC' undeclared (first use in this function)
loader.c:224: (Each undeclared identifier is reported only once
loader.c:224: for each function it appears in.)
*** Error code 1
make: Fatal error: Command failed for target `loader.o'
------ end capture ---
as you can see redefining O_ASYNC to FASYNC does not help the situation at all
as it appears under Solaris FASYNC is also somethnig which is not known. :(.
This was tried because of another older post in lugnet/legoS (can't remember
the number but just do a search for O_ASYNC and it pops up)
Anyone have any ideas?
cheers and thanks again for the help
michael
|
|
| |
On Fri, 19 Nov 1999, michael yates wrote:
> We are persisting with our build on solaris for legOS 0.2.2 things are getting
> closer. We have sorted out the getopt.h problems by just copying the getopt.c
> and getopt.h into the dll-src directory (because it is a known path for the
> Makefile for dll-src). We will talk more with the sys admin at a later date
> about where our copy of getopt.* has gone from /usr/include or wether Solaris
> ever had it.
I think it is quite likely that Solaris does not have it- neither Solaris
i386 or Solaris Sparc (at least the versions that I have access to) have it.
> Anyhow we are now up against another problem. This time the culprit is
> O_ASYNC. It seems that this is an undeclared identifier. What file does this
> usually reside in from the bunch of .h includes in loader.c?? Here are two
> Solaris captures to illustrate the problem
> <snip much compiler output>
> as you can see redefining O_ASYNC to FASYNC does not help the situation at all
> as it appears under Solaris FASYNC is also somethnig which is not known. :(.
> This was tried because of another older post in lugnet/legoS (can't remember
> the number but just do a search for O_ASYNC and it pops up)
>
> Anyone have any ideas?
Hmm. O_ASYNC is defined in /usr/include/bits/fcntl.h under Linux. The
equivalent file in Solaris is /usr/include/sys/fcntl.h. Unfortunately,
there is no easy replacement.
O_ASYNC is not POSIX compliant in any way, in fact (AFAICT) it has no
simple equivalent in a POSIX system like Solaris. What O_ASYNC does is
makes the file access asynchronous, and sends a signal (SIGIO) when the
file is available for writing or reading.
So... no simple #define is going to do it (I don't think.) I've asked some
local programmers for help with it, but no responses yet. In the meantime,
you'll probably want to look at man -s5 aio, which is a start on the
description of the Solaris way to handle asynchronous i/o events.
On the other hand, it is not clear from the code (and my total lack of
experience with this kind of thing) that aio is needed anyway. You may
want to try something like O_SYNC or O_RSYNC to replace O_ASYNC, and just
call the sigio_handler once (since it appears to me that it should be
called immediately after the first fcntl call, anyway.)
Anyway- that's about all I can think of for now. Markus may be able to
fill you in on more details about the role of aio and the sigio_handler
in the code- I'm not sure why it's there, so I'm afraid I've probably
reached the end of my usefulness.
Good luck- please keep updating us with your progress-
Luis
#######################################################################
Profanity is the one language that all programmers understand.
-Anonymous
#######################################################################
|
|
| |
BTW, a really good article on Solaris aio is here:
http://www.sunworld.com/sunworldonline/swol-03-1996/swol-03-aio.html
-Luis
On Fri, 19 Nov 1999, michael yates wrote:
> Date: Fri, 19 Nov 1999 02:14:51 GMT
> From: michael yates <michael.yates@studentmail.newcastle.edu.au>
> To: lugnet.robotics.rcx.legos@lugnet.com
> Subject: O_ASYNC problem (Solaris again)
>
> Hi all,
> We are persisting with our build on solaris for legOS 0.2.2 things are getting
> closer. We have sorted out the getopt.h problems by just copying the getopt.c
> and getopt.h into the dll-src directory (because it is a known path for the
> Makefile for dll-src). We will talk more with the sys admin at a later date
> about where our copy of getopt.* has gone from /usr/include or wether Solaris
> ever had it.
>
> Anyhow we are now up against another problem. This time the culprit is
> O_ASYNC. It seems that this is an undeclared identifier. What file does this
> usually reside in from the bunch of .h includes in loader.c?? Here are two
> Solaris captures to illustrate the problem
>
>
> The first capture was taken using the original, "out of the box" loader.c the
> second capture was taken after the following lines were added to loader.c at
> line 48
>
> #ifndef O_ASYNC
> #define O_ASYNC FASYNC
> #endif
>
>
> ---- Solaris capture (before redefinition) ----
> frost-dll-src: ls
> CVS convert.c keepalive.c loader.c rcxtty.c srec.h
> Makefile getopt.c keepalive.h lx.c rcxtty.h srecload.c
> config.h getopt.h lnp.c lx.h srec.c srecload.h
> frost-dll-src: gmake
> gcc -o loader.o -c loader.c -O2 -Wall -I/usr/include -I. -I../../include
> loader.c: In function `LNPinit':
> loader.c:224: `O_ASYNC' undeclared (first use in this function)
> loader.c:224: (Each undeclared identifier is reported only once
> loader.c:224: for each function it appears in.)
> gmake: *** [loader.o] Error 1
> ---- end solaris capture ----
>
>
>
>
> ---- Solaris capture (after redefinition) ----
> frost-dll-src: ls
> CVS convert.c keepalive.c loader.c rcxtty.c srec.h
> Makefile getopt.c keepalive.h lx.c rcxtty.h srecload.c
> config.h getopt.h lnp.c lx.h srec.c srecload.h
> frost-dll-src: make
> gcc -o loader.o -c loader.c -O2 -Wall -I/usr/include -I. -I../../include
> loader.c: In function `LNPinit':
> loader.c:224: `FASYNC' undeclared (first use in this function)
> loader.c:224: (Each undeclared identifier is reported only once
> loader.c:224: for each function it appears in.)
> *** Error code 1
> make: Fatal error: Command failed for target `loader.o'
> ------ end capture ---
>
> as you can see redefining O_ASYNC to FASYNC does not help the situation at all
> as it appears under Solaris FASYNC is also somethnig which is not known. :(.
> This was tried because of another older post in lugnet/legoS (can't remember
> the number but just do a search for O_ASYNC and it pops up)
>
> Anyone have any ideas?
>
> cheers and thanks again for the help
> michael
>
>
#######################################################################
Profanity is the one language that all programmers understand.
-Anonymous
#######################################################################
|
|
|
