libiberty question

libiberty question

[Joel Sherrill]

I think rtems needs to be treated like vxworks.  I added a 
config/mt-rtems which had the following:

 
HDEFINES = -DNO_SYS_PARAM_H -DNO_SYS_FILE_H

The config/mt-vxworks5 file had the building of a vxconfig.h.  Could
someone explain it to me well enough so I can decide if I should build
something similar.  It builds with just the above line in the mt file, I 
just wanted to know if I should be doing more.

--joel 

Re: libiberty question

[Ian Lance Taylor]

   Date: Tue, 9 Jul 1996 09:04:04 -0500 (CDT)
   From: Joel Sherrill <joel@merlin.gcs.redstone.army.mil>

   I think rtems needs to be treated like vxworks.  I added a 
   config/mt-rtems which had the following:

   HDEFINES = -DNO_SYS_PARAM_H -DNO_SYS_FILE_H

I tend to think that you will be better off providing both those
files.

   The config/mt-vxworks5 file had the building of a vxconfig.h.  Could
   someone explain it to me well enough so I can decide if I should build
   something similar.  It builds with just the above line in the mt file, I 
   just wanted to know if I should be doing more.

The way libiberty configures itself is to link programs and try to
figure out what is missing.  VxWorks, however, is unusual, in that
programs are never fully linked.  Instead, relocateable object files
are downloaded into the VxWorks system, which completes the link as it
loads the object.  VxWorks provides the basic libc functions.  The
effect of this is that the libiberty configuration method is useless,
because it is not possible to fully link a program, and thus it is not
possible to figure out what is present and what is missing.  The
special VxWorks configuration handling in libiberty is used to get
around that problem.

If RTEMS has similar characteristics, then a similar solution will be
required.  In the more normal case, however, it will not.

Ian

Re: libiberty question

[Joel Sherrill]

On Tue, 9 Jul 1996, Ian Lance Taylor wrote:

>    config/mt-rtems which had the following:
> 
>    HDEFINES = -DNO_SYS_PARAM_H -DNO_SYS_FILE_H
> 
> I tend to think that you will be better off providing both those
> files.

Right now almost every header file we have is directly from newlib.  
Looking at the Solaris versions of these two, it will be a while before 
we could do them.  I think the vxworks configuration made a good decision 
here.

> The way libiberty configures itself is to link programs and try to
> figure out what is missing.  VxWorks, however, is unusual, in that
> programs are never fully linked.  Instead, relocateable object files
> are downloaded into the VxWorks system, which completes the link as it
> loads the object.  VxWorks provides the basic libc functions.  The
> effect of this is that the libiberty configuration method is useless,
> because it is not possible to fully link a program, and thus it is not
> possible to figure out what is present and what is missing.  The
> special VxWorks configuration handling in libiberty is used to get
> around that problem.
> 
> If RTEMS has similar characteristics, then a similar solution will be
> required.  In the more normal case, however, it will not.

RTEMS applications are normally fully linked so libiberty's configuration 
method should work.

With the addition of the mt-rtems file, sparc-rtems built and installed 
successfully.  It will be used in the next RTEMS testing cycle.  I am 
building the m68k now.

--joel

Re: libiberty question

[Ian Lance Taylor]

   Date: Tue, 9 Jul 1996 09:57:02 -0500 (CDT)
   From: Joel Sherrill <joel@merlin.gcs.redstone.army.mil>

   On Tue, 9 Jul 1996, Ian Lance Taylor wrote:

   >    config/mt-rtems which had the following:
   > 
   >    HDEFINES = -DNO_SYS_PARAM_H -DNO_SYS_FILE_H
   > 
   > I tend to think that you will be better off providing both those
   > files.

   Right now almost every header file we have is directly from newlib.  
   Looking at the Solaris versions of these two, it will be a while before 
   we could do them.  I think the vxworks configuration made a good decision 
   here.

The current version of newlib provides both those files.

VxWorks has its own header files, which are controlled by WRS, so the
VxWorks configuration has no choice.

Here is <sys/file.h> from newlib:

==================================================
#include <sys/fcntl.h>
==================================================

Here is <sys/param.h> from newlib:

==================================================
/* This is a dummy <sys/param.h> file, not customized for any
   particular system.  If there is a param.h in libc/sys/SYSDIR/sys,
   it will override this one.  */

#ifndef _SYS_PARAM_H
# define _SYS_PARAM_H

# define HZ (60)
# define NOFILE	(60)
# define PATHSIZE (1024)

#endif
==================================================

Ian

Re: libiberty question

[Joel Sherrill]

On Tue, 9 Jul 1996, Ian Lance Taylor wrote:

>    >    HDEFINES = -DNO_SYS_PARAM_H -DNO_SYS_FILE_H
>    > 
>    > I tend to think that you will be better off providing both those
>    > files.

My copy of newlib 1.7.0 had the sys/param.h but not the sys/file.h.  

I added the sys/file.h and am rebuilding without mt-rtems.

--joel