Re: Numbered lists get closed by </ul>, posted by Stefan Ritt on Tue Feb 7 12:58:10 2006
|
[quote="T. Ribbrock"]I just ran into the following problem (and was able to reproduce it in the "demo" logbook on this site):
[LIST]
|
CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Tue Feb 14 16:22:56 2006
|
Stefan, I am concerned that there are becoming too many Linux dependencies in terms of required libraries and header files. Although we have a replacement
for the [code]forkpty()[/code] routine, I am running into many other dependencies, the latest of which is pty.h. Aren't there guidelines in GCC that point
out what is available cross-platform and what is not? For example, any SVR# (System Five, Release XX) based Unix will not include the forkpty() function, |
|
Re: CONCERN: Cross-platform compiling at risk, posted by Stefan Ritt on Tue Feb 14 17:43:15 2006
|
[quote="Steve Jones"]Stefan, I am concerned that there are becoming too many Linux dependencies in terms of required libraries and header files. Although
we have a replacement for the [code]forkpty()[/code] routine, I am running into many other dependencies, the latest of which is pty.h. Aren't there guidelines
in GCC that point out what is available cross-platform and what is not? For example, any SVR# (System Five, Release XX) based Unix will not include the |
|
Re: CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Tue Feb 14 22:31:08 2006
|
[quote="Steve Jones"][quote="Stefan Ritt"][quote="Steve Jones"]Stefan, I am concerned that there are becoming too many Linux dependencies in terms of required
libraries and header files. Although we have a replacement for the [code]forkpty()[/code] routine, I am running into many other dependencies, the latest
of which is pty.h. Aren't there guidelines in GCC that point out what is available cross-platform and what is not? For example, any SVR# (System Five, |
|
Re: CONCERN: Cross-platform compiling at risk, posted by Stefan Ritt on Wed Feb 15 18:25:15 2006
|
[quote="Steve Jones"]Question: Is the functionality really just to issue an arbitrary command-string to a "shell" and have the result stuffed back into
an eLog variable? I'm not an expert but it would seem that such a feature would be universally available or could be used to construct a suitable routine.
|
|
Re: CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Wed Feb 15 19:02:32 2006
|
[quote="Steve Jones"][quote="Stefan Ritt"][quote="Steve Jones"]Question: Is the functionality really just to issue an arbitrary command-string to a "shell"
and have the result stuffed back into an eLog variable? I'm not an expert but it would seem that such a feature would be universally available or could
be used to construct a suitable routine.
|
|
Re: CONCERN: Cross-platform compiling at risk, posted by Stefan Ritt on Fri Feb 17 13:31:00 2006
|
[quote="Steve Jones"]If possible, could one use the [code]int system(const char *s);[/code] function in conjunction with a filei/o function as the means
for getting the results of a system call back into a var. Perhaps [code]char *tmpnam(char *s);[/code], running a command via [code]int system(const char
*s);[/code], then opening that file for a read would accomplish what is being desired?
|
Re: CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Mon Feb 20 17:50:33 2006
|
[quote="Stefan Ritt"][quote="Steve Jones"]If possible, could one use the [code]int system(const char *s);[/code] function in conjunction with a filei/o
function as the means for getting the results of a system call back into a var. Perhaps [code]char *tmpnam(char *s);[/code], running a command via [code]int
system(const char *s);[/code], then opening that file for a read would accomplish what is being desired?
|