| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
Interix, Windows and Pipes....
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 Interix, Windows and Pipes.... - Dec. 13, '05, 9:15:02 AM
|
|
|
mduft
Posts: 14
Joined: Nov. 16, '05,
Status: offline
|
Hey there!
I found a post on this, but my problem wasn't solved there, nor have i gotten some hint in which direction to look for solutions.
The problem is the following: I'm compiling native Windows executables with a self-modified interix cc version, which works perfectly. Now i'm (better: i'm forced to) doing something like this.
CC=natcc CXX=natcc LD=natcc ../something/configure --prefix=... | tee my_log.log
And here the Problems come along ;o//. Everything works fine, until the configure script tries to call one of the exes the script itself compiled as configure check. (and it's more than just one configure script... i have to do this for about 100 packages in an automated build process...)
Since the tried exe is native windows, there seem to be some pipe problems. I have no influence on using the pipe (i have to, since our build system does this), nor can i redirect the output to a file, and display it after execution has finished (would take years to long). I tried with cat32, which didn't work. Redirection of the native exe to a file, or elswhere (where else can i redirect it) seems to solve to problem, but the configure scripts (and other scripts on other places) use the ouptut of some of those exes, so i need it on stdout (maybe there is some possibility to create a sort of loop, which uses a file to just tempirarily save stdout and stderr?? But this would have to display every character (or line) on the screen immediatly...)
Anyone any thoughts??
Thanks in advance!
Regards, Markus!
|
|
|
|
|
RE: Interix, Windows and Pipes.... - Dec. 13, '05, 11:51:05 AM
|
|
|
Rodney
Posts: 3142
Joined: Jul. 9, '02,
From: /Tools lab
Status: online
|
You may want to take a look at the wcc script (it's a package to install from /Tools).
Compare it to the modified cc that you have made. There might be something that helps
in a sideways/indirect sort-of way.
For the piping thing you could try, as you have already, having the Win32 EXE direct it's output
into a file directly, then use the Unix "tail -f" to pickup that file's content to keep the pipeline going.
Often when doing an install I'll do "make install > op.install & ; tail -f op.install".
The '-f' option will camp on the file and output changes immediately.
|
|
|
|
|
RE: Interix, Windows and Pipes.... - Dec. 14, '05, 2:13:18 AM
|
|
|
mduft
Posts: 14
Joined: Nov. 16, '05,
Status: offline
|
Thanks for the fast answer!
tailing the file seems to work fine now, thanks! But is there a way to automatically stop the tail command, when configure (or make, etc.) has finished? i simply can't keep spawning tail processes for every of the hundreds of scripts without ever exiting one of them. Would be really great if this works!
Regards, Markus
|
|
|
|
|
RE: Interix, Windows and Pipes.... - Dec. 14, '05, 3:11:44 AM
|
|
|
Rodney
Posts: 3142
Joined: Jul. 9, '02,
From: /Tools lab
Status: online
|
Yes, that's a good point. The nature of '-f' is to hang around forever.
Well, off the top of my head (i.e. untried) each of these tail commands will be a child
of the running script. Before exiting the script could, knowing it's own PID, look for all
processes that have it's PID as the Parent PID (PPID) and send a kill -TERM at them.
So use the "-o" option with ps and use grep and awk to pull out PID's.
|
|
|
|
|
RE: Interix, Windows and Pipes.... - Dec. 14, '05, 3:18:17 AM
|
|
|
mduft
Posts: 14
Joined: Nov. 16, '05,
Status: offline
|
Hmmm, that'd meen i'd have to change all the scripts again, and this is not one of the most easy solutions ;o). Anyway, i'll have to take a deeper look on that!
Thanks, Markus
|
|
|
|
|
RE: Interix, Windows and Pipes.... - Dec. 15, '05, 2:50:37 AM
|
|
|
jon493
Posts: 56
Joined: Oct. 14, '05,
Status: offline
|
Although I have a separate thread running on this I think it better to merge them here as mduft is actually doing what I merely want to do. So...
Another problem(?) is uname. GNU configure scripts invariably check the host system. On interix this normally comes out to i586-pc-interix3 or something similar. However, this could trigger some OS specific #define's which should be enabled only for Interix (and not Win32) builds. Any views on this?
|
|
|
|
|
RE: Interix, Windows and Pipes.... - Dec. 15, '05, 2:57:54 AM
|
|
|
mduft
Posts: 14
Joined: Nov. 16, '05,
Status: offline
|
I haven't had such problems by now...
Which #def's do you meen?? I modified cc so that it does define _WIN32 and __INTERIX, but not unix. If you want to compile native for windows, you'll need _WIN32 anyway, because the windows headers won't work otherwise...
Do you want to compile for Interix, or native for Windows?
I have made the experience, that most packages need just little patches to make them work (about 5k or something).
Regards, Markus
|
|
|
|
|
RE: Interix, Windows and Pipes.... - Dec. 15, '05, 3:21:08 AM
|
|
|
jon493
Posts: 56
Joined: Oct. 14, '05,
Status: offline
|
I was talking about just that. Why are you defining __INTERIX ? It should not be defined for any Win32 application. Also, regular applications (I mean well behaved ones) should 'just work' as you have seen. But terrible applications (or fancy ones -- depends whether you are an emacsite or not) like emacs actually use the system 'i586-pc-*' line to decide how to build. If you don't believe me, try compiling FSF emacs from source on interix. It's a miracle someone at /tools built it for Interix at all. It does work on Interix, but the configure script doesn't know that. This will be a problem with even Win32-aware programs (like groff) which can be built both for Interix and for MinGW. You can 'fix' the _WIN32 in cc script, but how do you know what the he** the configure script 'configures' into header files?
However, as an aside, uname should also be patched so that it returns a proper value (like i586-pc-mingw is returned on MinGW systems) when compiling native for Win32. Or a substitute uname shell script can be used for any Win32 builds and the actual uname used for Interix builds.
UPDATE: Just to clarify the terminology.
'compiling on Interix': means using Interix shells as developement environments (mainly to run configure scripts)
'compiling for Interix': means using the POSIX subsystem as the build target, i.e., the executables will be linked using /subsystem:POSIX (or with the Interix gcc). This is the way all /tools packages have been built. It is rather like a native UNIX build.
'compiling for Win32': means using the /subsystem:console or /subsystem:windows linkage to build 'native' Win32 executables
< Message edited by jon493 -- Dec. 15, '05, 3:33:46 AM >
|
|
|
|
|
RE: Interix, Windows and Pipes.... - Dec. 15, '05, 4:00:00 AM
|
|
|
mduft
Posts: 14
Joined: Nov. 16, '05,
Status: offline
|
Hmm... i never ran into any problems with __INTERIX, since nobody seems to use it anyway ;o) I do not need it, so i could kick it out as well...
unmae is fine on interix, it behaves as it should, i think ... the host triplet comes (normally) from config.guess (which i had to edit for most older packages to know interix). I haven't found a package yet which made problems because of the host triplet line, but you could just overwrite it in the config.guess file by doing something like this:
Replace this:
x86:Interix*:3*)
echo i386-pc-interix
exit 0 ;;
With something like this:
x86:Interix*:*)
echo i386-pc-mingw
exit 0;;
or whatever platform you like ;o) (maybe win32)
Regards, Markus
|
|
|
|
|
RE: Interix, Windows and Pipes.... - Dec. 15, '05, 4:21:04 AM
|
|
|
jon493
Posts: 56
Joined: Oct. 14, '05,
Status: offline
|
Good Idea. However, the question is not how this should be done, rather what system string should be used. i586-pc-mingw will most certainly fail as it expects gcc which, of course, is out of the question. The main reason we are going through this grind is that we want to use cl.exe (mainly the /arch:SSE and /GL options). Also, the mingw headers have their own idiosyncrasies which will be acounted for in the source code (which we do not want).
|
|
|
|
|
RE: Interix, Windows and Pipes.... - Dec. 15, '05, 4:22:38 AM
|
|
|
jon493
Posts: 56
Joined: Oct. 14, '05,
Status: offline
|
I have just downloaded wcc. I am going to try this out so my next post will be after some time.
|
|
|
|
|
RE: Interix, Windows and Pipes.... - Dec. 15, '05, 4:25:42 AM
|
|
|
mduft
Posts: 14
Joined: Nov. 16, '05,
Status: offline
|
if you want (or wcc doesn't work for you) you might want to give my modified cc a try, i can give it to you. This worked perfectly for most packages.
For modifying the config.guess: i never needed anything other than i386-pc-interix, this worked so far for all packages. The only thing is, that for older config.guess versions you might need to add interix to the file.
Regards, markus
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
