RE: Re: Changing symlinks from
>On Tue, Feb 11, 2003 at 01:05:06PM -0000, Christopher January wrote:
>> How can I automatically convert all symlinks on my Cygwin filesystem
from
>> the "!" format to windows shortcuts? Samba doesn't seem to
>> maintain the correct permissions for the Cygwin DLL to detect the
>> "!" files as symlinks, so they are treated as regular files
>> (hence the errors with gcc, etc. I was seeing). Thanks Chris and others
>> for pointing me in the right direction to diagnose this. I now need a
way
>> of converting all those symlink files to windows shortcuts so I can use
>> Cygwin at college.
>> Chris
>
>Write a script which reads the content of the symlink, then removes the
>old one and eventually recreates it. The resulting symlink will have the
>appropriate format according to the CYGWIN env. var. Sth like this
>
> for i in `find / -type l`
> do
>TARGET=`ls -l $i | awk '{print $NF;}'`
>rm $i
>ln -s $TARGET $i
> done
For the record, the script I used was:
#!/usr/bin/env bash
here=$PWD
echo "here=$PWD"
IFS=$'\n'
grep -r -l '^\!\(.*\)\x00' / | while read -r file;
do
dir="`dirname "$file"`"
file="`basename "$file"`"
cd $dir
dest="`sed 's/\!\(.*\)\x00/\1/g' "$file"`"
rm $file
ln -s $dest $file
cd $here
done
Now I can run gcc hopefully I can patch Cygwin to run at a tolerable speed
on this setup!
Chris
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Changing symlinks from "magic" format to windows shortcuts.
How can I automatically convert all symlinks on my Cygwin filesystem from the "!" format to windows shortcuts? Samba doesn't seem to maintain the correct permissions for the Cygwin DLL to detect the "!" files as symlinks, so they are treated as regular files (hence the errors with gcc, etc. I was seeing). Thanks Chris and others for pointing me in the right direction to diagnose this. I now need a way of converting all those symlink files to windows shortcuts so I can use Cygwin at college. Chris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problems compiling trivial C program.
I'm having trouble compiling this test program:
void f(){}
using the command line:
gcc test.c -c -o test.o
using 1.3.19 or latest Cygwin snapshot (2003-Feb-07) (same error with
both) and gcc-3.2-3.
The error I see is:
16 bit MS-DOS Subsystem
/usr/src/cygwin-cvs/obj
The NTVDM CPU has encountered an illegal instruction.
CS: IP:0077 OP:f0 37 05 0e 02 Choose 'Close' to terminate the
application.
Close | Ignore
AFAICT the command that is failing is:
/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwin/bin/as.exe,
P:\ccj00\cygwin\usr\i686-pc-cygwin\bin\as.exe --traditional-format -o
test.o /cygdrive/c/DOCUME~1/ccj00/LOCALS~1/Temp/cc50BUPU.s
See the following strace portion:
39542 4773296 [main] gcc 1428 spawn_guts: 1428 = spawn_guts
(/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwin/bin/as.exe,
P:\ccj00\cygwin\usr\i686-pc-cygwin\bin\as.exe --traditional-format -o
test.o /cygdrive/c/DOCUME~1/ccj00/LOCALS~1/Temp/cc50BUPU.s)
710 4774006 [main] gcc 1428! fhandler_base::close: closing
'/usr/src/cygwin-cvs/obj/strace.log' handle 0xD0
520 4774526 [main] gcc 1428! spawn_guts: spawned windows pid 1740
4070800 8655535 [sig] gcc 1780 wait_sig: awake
652 8656187 [sig] gcc 1780 wait_sig: processing signal 0
1287 8657474 [sig] gcc 1780 pinfo::init: execed process windows pid 1952,
cygwin pid 1620
889 8658363 [sig] gcc 1780 wait_sig: looping
3887914 8662440 [sig] gcc 1428! wait_sig: awake
616 8663056 [sig] gcc 1428! wait_sig: processing signal 0
1420 8664476 [sig] gcc 1428! pinfo::init: execed process windows pid
1952, cygwin pid 1620
939 8665415 [sig] gcc 1428! wait_sig: looping
The dialog box appears at this point.
procps shows the offending command running with the command line:
ccj00 1864 0.7 0.6 405536 1592 tty0S13:20 0:00 gcc test.c
-c -o
however ps shows it running with the command line:
1864 480 480 1864 con 22083 13:20:49
/usr/i686-pc-cygwin/bin/as
(The above output is from a different run to the strace)
The new windows process doesn't seem to reach the Cygwin initialisation
stage.
I have tried reinstalling the gcc package. I also tried setting the TMP
and TEMP environment variables to /tmp.
None of the above solved the problem.
The command:
gcc test.c -o test
also shows the same dialog box as above and then fails with the following
error:
$ gcc test.c -o test
/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwin/bin/ld:
installat
ion problem, cannot exec
`/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-p
c-cygwin/bin/ld': Invalid argument
collect2: ld returned 255 exit status
Cygcheck output and strace attached.
I don't have many debugging facilities available to me here at college,
but I can try to provide more information if necessary.
Chris
strace.log.gz
Description: application/gunzip
cygcheck_output
Description: Binary data
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: 1.1.3 and upwards: apparent bug with pthread_cond_wait() and/or signal()
> Between 1.1.3 and 1.3.0 a huge change occurred in the pthreads code > base, so this assumption is not safe. (It's not necessarily wrong > either.) I'd definitely be using 1.3.10 though. > > > #include > > #include > > The cygwin c++ libgcc, stdlibc++ and gcc are not built with thread > support, so C++ and threads may not work well together. C should work > fine, and if anyone convinces Chris to release a thread-enabled gcc, C++ > should get better. Arrrgh - so that explains why so much of my source crashes randomly every now and again.. (!) Please, please release thread-enabled C++ libs. Chris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: /cygdrive wierdness
> > > > > Using Cygwin DLL 1.3.10. > > > > > > > > Likewise. (On Win2K.) > > > > > > > > > 1. Close all Cygwin programs > > > > > 2. Open bash > > > > > 3. Type: cd /cygdrive > > > > > 4. Type ls > > > > > I get a listing of C:\ instead > > > > > 5. Type bash > > > > > 6. Type: cd /cygdrive > > > > > 7. Type ls > > > > > I get a listing of available drives as I should. > > > > > > > > > > Can someone else confirm this is a problem? > > > > > > > > Not here. I get the list of drives always. > > > > > > Are you sure you closed all Cygwin programs? > > > >Yes. I just tried it again after rebooting to make sure. > >(My drive prefix is /win instead of /cygdrive, but I don't > >suppose that would make any difference.) > > Sorry to belabor the point but do you run any Cygwin services? If so, did > you shut them down? Have you tried this yourself Larry? What do you get? Chris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin website
The news items on http://www.cygwin.com have a closing tag, but are missing the opening tag. Regards Chris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: A real fork() on NT
> >I've got the book; I have a DLL that exports a function called fork and > >I'm seeing what can be done to get it to work with kdeinit. A lot of > >programs do: if (fork() == 0) exec(...) and this could be replaced by > >spawn(...) anyway, but kdeinit does a bit more work. > > So, use vfork(). We already have an implementation that does the right > thing in that case. That wouldn't work. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: A real fork() on NT
> When looking at XP's CreateProcessW (or rather, CreateProcessInternalW) I > noticed something strange about the way it creates a process. It seems > that NT is sort of capable of a fork() command. The function > NtCreateProcess appears to create a "blank" process, into which you can put > anything you want. After NtCreateProcess, kernel32 maps the EXE into that > new process's memory space, creates a thread, and finally calls > NtResumeThread to start its execution. > > If this long, nasty, scattered function could be reverse engineered, it > should be possible to create a true fork() for NT, instead of doing the > normal cygwin "hack" method. Coincidentally, I was looking into a similar thing myself. Windows NT has a POSIX subsystem that's capable of doing fork()'s so it is obviously possible. Have you any ideas of the arguments passed to the function or what it returns? Chris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
