This is the mail archive of the email@example.com mailing list for the gas2 project.
|Index Nav:||[Date Index] [Subject Index] [Author Index] [Thread Index]|
|Message Nav:||[Date Prev] [Date Next]||[Thread Prev] [Thread Next]|
Date: Tue, 9 Jul 1996 09:04:04 -0500 (CDT) From: Joel Sherrill <firstname.lastname@example.org> 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