| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
1692
|
Tue Feb 14 16:22:56 2006 |
 | Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.1 | CONCERN: Cross-platform compiling at risk |
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. |
|
1694
|
Tue Feb 14 22:31:08 2006 |
 | Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.1 | Re: CONCERN: Cross-platform compiling at risk |
| Steve Jones wrote: |
| Stefan Ritt wrote: |
| 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 |
Stefan et al.
I think it would be preferrable if we could find a routine that performed the same function but that was available under Windows/Linux/Unix. 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.
If possible, could one use the int system(const char *s); function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps char *tmpnam(char *s); , running a command via int system(const char *s); , then opening that file for a read would accomplish what is being desired?
|
|
|
1697
|
Wed Feb 15 19:02:32 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.1 | Re: CONCERN: Cross-platform compiling at risk |
| Steve Jones wrote: |
| Stefan Ritt wrote: |
| Steve Jones wrote: | 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.
If possible, could one use the int system(const char *s); function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps char *tmpnam(char *s); , running a command via int system(const char *s); , then opening that file for a read would accomplish what is being desired?
|
Indeed the results from the "shell" need to be stuffed back into an elog attribute, that's why you cannot use the system() function directly. The idea with the tmpnam() could however be a clever workaround. I have to see if this works under Windows. If so, it would be a much more portable alternative to forkpty(). |
Yes, these routines are from the standard C libraries. tmpname() returns a pointer to a filename guaranteed to be unique, then you can create that file. tmpfile() actually creates a temporary file and returns a pointer to the filestream, and auto cleans up upon stream termination. system() passes the command string to the shell/commandproc if available. You could wrap these into a single callable function that is called 'shell()' and accomplish your first gola plus achieve cross-platformness again ;->
My 2 cents - hope that is enough!
|
|
|
1699
|
Mon Feb 20 17:50:33 2006 |
 | Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.1 | Re: CONCERN: Cross-platform compiling at risk |
| Stefan Ritt wrote: |
| Steve Jones wrote: | If possible, could one use the int system(const char *s); function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps char *tmpnam(char *s); , running a command via int system(const char *s); , then opening that file for a read would accomplish what is being desired?
|
I implemented exprimentally such a code. Instead of tmpnam() (which the compiler claims to be obsolete), I use a hard-wired file name /tmp/elog-shell for that purpose. I put it under /tmp so that the "elog" user (under which elog should normally run) is able to write to. Can you please check if that works fine now under Solaris? |
The compiled version runs fine under Solaris9. When executing Subst Subject = $shell(uname) I got:
"SunOS" !!! ;->
So, short of the items I pointed out below I would say that you have successfully re-rendered eLog as a truly cross platform application once again! My hat is off to you!
thanks
Steve |
|
1700
|
Mon Feb 20 17:52:06 2006 |
| Steve Jones | steve.jones@freescale.com | Question | Other | 2.6.1 | Re: compiling elog 2.6.1 on solaris platform |
| Steve Jones wrote: |
| Stefan Ritt wrote: |
| Steve Jones wrote: | BTW, Stefan, this code in Makefile does not work on Solaris
OSTYPE = $(shell uname)
.
.
.
ifeq ($(OSTYPE),solaris)
At least, not on our solaris systems. 'uname' returns SunOS. |
Ok, what about adding:
ifeq ($(OSTYPE),SunOS)
OSTYPE=solaris
endif |
| Steve Jones wrote: |
That would work, but my question is "why is this statement needed at all?" In GNU-land it appears that the make utilities use the canonical names rather than the ones returned by the OS. When I simply comment out this section, the solaris compile works fine. Perhaps it does not on other platforms?
Also, I ran into another snag. The include file "pty.h" does not appear to exist in solaris-land, so I am seeing if there is one made available elsewhere.
|
|
In working with Stefan changes were made so that the latest release should once again cross-compile fine, and Makefile also works under Solaris. Great job Stefan! |
|
1701
|
Tue Feb 21 19:25:28 2006 |
 | Steve Jones | steve.jones@freescale.com | Question | All | 2.6.1 | svn revision number in the source |
There is a variable $Id$ in source that looks like it is supposed to reflect the svn revision number of the compiled code. How is this supposed to be set, manually just before compiling?
Thanks! |
|
1703
|
Tue Feb 21 21:01:22 2006 |
| Steve Jones | steve.jones@freescale.com | Question | All | 2.6.1 | Re: svn revision number in the source |
| Stefan Ritt wrote: |
| Steve Jones wrote: | | There is a variable $Id$ in source that looks like it is supposed to reflect the svn revision number of the compiled code. How is this supposed to be set, manually just before compiling? |
It gets set automatically on every commit to the Subversion repository. |
So, when we go to the download section and download directly from there, that is not "committed" source? I ask because the revision id there is not set to anything that I can see. |
|
1705
|
Tue Feb 21 21:58:16 2006 |
 | Steve Jones | steve.jones@freescale.com | Question | All | 2.6.1 | Re: svn revision number in the source |
| Stefan Ritt wrote: |
| Steve Jones wrote: | | So, when we go to the download section and download directly from there, that is not "committed" source? I ask because the revision id there is not set to anything that I can see. |
Can you be a bit more specific? What do you download? The Windows binaries, the Linux RPM? Or from the Subversion repository? The current version in the repository, which you can download here, contains in the file elogd.c following line 8:
$Id: elogd.c 1660 2006-02-17 19:48:12Z ritt $
This tells you that this is revision 1660, committed on Feb. 17 by myself. So what is the problem? |
| Steve Jones wrote: | Ok, this is really strange but just an hour ago I clicked on the http://midas.psi.ch/elog/download.html link and I was taken to a completely different webview - in fact, I am quite sure that at the bottom right corner it said "WebCVS"! Now, it says WebSVN and the revision info is in there. I've been trying to debug a problem with default.css and the elcode icons - and somewhere in there I cleared my firefox cache. Perhaps an old page was cached????
I have no idea how I got to CVS, and it make sense that CVS was not setting the SVN revision code.
Sorry to botter you on this. |
|