| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
1680
|
Fri Feb 10 20:24:56 2006 |
 | Steve Jones | steve.jones@freescale.com | Question | Other | 2.6.1 | Re: compiling elog 2.6.1 on solaris platform |
| Stefan Ritt wrote: |
| Steve Jones wrote: | Actually, what I will be delivering is a new Makefile with conditional compile statements plus the C code module since the example that I provided need some cleaning. Since I don't have a Linux system on which to test the conditional compile completely I would need you to do that. Sound ok?
|
Sure. I put already the conditional compiling into the current Makefile, so just try it. I tested the Linux part, which is ok. If you could test the Solaris part, that would be great. |
Ok, I see what you did. I took a different route since I was not sure how the gnu linker would handle the fact that there would be two declarations of the forkpty() function when compiled and linked under Linux. Instead, I created a separate forkpty.c module and compiled it separately. Then, if "solaris", link it in. Otherwise, use library "util" which already has forkpty().
So, since it seems to work under Linux, any idea which function is being used? |
|
1681
|
Fri Feb 10 20:29:12 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Other | 2.6.1 | Re: compiling elog 2.6.1 on solaris platform |
| Steve Jones wrote: | Ok, I see what you did. I took a different route since I was not sure how the gnu linker would handle the fact that there would be two declarations of the forkpty() function when compiled and linked under Linux. Instead, I created a separate forkpty.c module and compiled it separately. Then, if "solaris", link it in. Otherwise, use library "util" which already has forkpty().
So, since it seems to work under Linux, any idea which function is being used? |
No, there are no two forkpty() function, due to the
#ifdef OS_SOLARIS
forkpty(...)
{
...
}
#endif
conditional compiling. So if I compile under Linux, the variable OS_SOLARIS is not defined, and therefore the special forkpty does not get compiled. Instead the one from the library is taken, since under Linux I use the -libutil switch. Under Solaris, there is no -libutil, but the OS_SOLARIS gets set, and therefore we have the code right inside elogd.c |
|
1684
|
Fri Feb 10 21:52:35 2006 |
| Steve Jones | steve.jones@freescale.com | Question | Other | 2.6.1 | Re: compiling elog 2.6.1 on solaris platform |
| Stefan Ritt wrote: |
| Steve Jones wrote: | Ok, I see what you did. I took a different route since I was not sure how the gnu linker would handle the fact that there would be two declarations of the forkpty() function when compiled and linked under Linux. Instead, I created a separate forkpty.c module and compiled it separately. Then, if "solaris", link it in. Otherwise, use library "util" which already has forkpty().
So, since it seems to work under Linux, any idea which function is being used? |
No, there are no two forkpty() function, due to the
#ifdef OS_SOLARIS
forkpty(...)
{
...
}
#endif
conditional compiling. So if I compile under Linux, the variable OS_SOLARIS is not defined, and therefore the special forkpty does not get compiled. Instead the one from the library is taken, since under Linux I use the -libutil switch. Under Solaris, there is no -libutil, but the OS_SOLARIS gets set, and therefore we have the code right inside elogd.c
| Steve Jones wrote: |
Got it. Much easier than how I was going about it.
|
|
|
|
1685
|
Fri Feb 10 22:31:38 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: | Ok, I see what you did. I took a different route since I was not sure how the gnu linker would handle the fact that there would be two declarations of the forkpty() function when compiled and linked under Linux. Instead, I created a separate forkpty.c module and compiled it separately. Then, if "solaris", link it in. Otherwise, use library "util" which already has forkpty().
So, since it seems to work under Linux, any idea which function is being used? |
No, there are no two forkpty() function, due to the
#ifdef OS_SOLARIS
forkpty(...)
{
...
}
#endif
conditional compiling. So if I compile under Linux, the variable OS_SOLARIS is not defined, and therefore the special forkpty does not get compiled. Instead the one from the library is taken, since under Linux I use the -libutil switch. Under Solaris, there is no -libutil, but the OS_SOLARIS gets set, and therefore we have the code right inside elogd.c
| Steve Jones wrote: |
Got it. Much easier than how I was going about it.
|
|
|
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. When I run 'make -P' or 'gmake -P' the environment variable 'OSTYPE' is already set to 'solaris'. This is the reason the original Makefile did not work on our solaris systems. I'm not sure if this is universal but it applies to the systems we run (Solaris 8 and 9). |
|
1686
|
Fri Feb 10 22:35:20 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Other | 2.6.1 | Re: compiling elog 2.6.1 on solaris platform |
| 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 |
|
1687
|
Mon Feb 13 18:22:08 2006 |
| Steve Jones | steve.jones@freescale.com | Question | Other | 2.6.1 | Re: compiling elog 2.6.1 on solaris platform |
| 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.
|
|
|
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. |
|
1693
|
Tue Feb 14 17:43:15 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.6.1 | 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 |
|