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?
|
|
Re: compiling elog 2.6.1 on solaris platform, posted by Steve Jones on Mon Feb 20 17:52:06 2006
|
[quote="Steve Jones"][quote="Stefan Ritt"][quote="Steve Jones"]BTW, Stefan, this code in Makefile does not work on Solaris
[code]
OSTYPE = $(shell uname)
|
SVN1714 will not run in 'daemon" mode on Solaris8, posted by Steve Jones on Mon Sep 18 20:35:44 2006 
|
On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system call) and shows precisely
where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively". Both runs are as root,
simply one with and one without the "-D" |
|
Re: SVN1714 will not run in 'daemon" mode on Solaris8, posted by Steve Jones on Mon Sep 18 22:09:23 2006
|
[quote="Steve Jones"]On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system
call) and shows precisely where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively".
Both runs are as root, simply one with and one without the "-D"[/quote]
|