Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG  Not logged in ELOG logo
icon4.gif   CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Tue Feb 14 16:22:56 2006 
    icon2.gif   Re: CONCERN: Cross-platform compiling at risk, posted by Stefan Ritt on Tue Feb 14 17:43:15 2006 
       icon2.gif   Re: CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Tue Feb 14 22:31:08 2006 
          icon2.gif   Re: CONCERN: Cross-platform compiling at risk, posted by Stefan Ritt on Wed Feb 15 18:25:15 2006 
             icon2.gif   Re: CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Wed Feb 15 19:02:32 2006 
                icon2.gif   Re: CONCERN: Cross-platform compiling at risk, posted by Stefan Ritt on Fri Feb 17 13:31:00 2006 
                   icon7.gif   Re: CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Mon Feb 20 17:50:33 2006 
Message ID: 1693     Entry time: Tue Feb 14 17:43:15 2006     In reply to: 1692     Reply to this: 1694
Icon: Reply  Author: Stefan Ritt  Author Email: stefan.ritt@psi.ch 
Category: Bug report  OS: Other  ELOG Version: 2.6.1 
Subject: Re: CONCERN: Cross-platform compiling at risk 

Steve Jones wrote:
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
forkpty()
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, but BSD derivatives will.

Currently we are stuck at eLog 2.5.9 because of this issue.


The whole issue with the forkpty() came from the request of the shell subsitution. I managed to compile this under Linux and under Windows, so I was under the impression that this is not too specific (although I had to use completely different approaches for Linux and Windows). Now if you tell me that this is not true, we have basically two options:

1) Make the shell substitution an option. On systems which don't have a forkpty(), don't compile it in. I guess not many people need the shell substitution. Thos people who need it have to stick to certain Unix flavours.

2) Find equivalents of forkpty() on all systems. The problem with that is that I have to rely on others like you to supply me some code for other systems and test it.

Please let me know what option you prefer. Also other users are asked for their opinion.

Best regards,

Stefan
ELOG V3.1.5-fe60aaf