Hey Cygwin users,
I'm having problems compiling lyx using g++ version 3.3.1 (more
specifically during the linking of various objects). I've attached a clip of
the final build log. Please have a look at this. Any help or pointers on
this will be much appreciated at this time as I'm blank on
Hi,
I've installed Cygwin on a Windows computer and my Java application load
a dll (which use cygwin1.dll) .
When i log on a Linux and open a connection to a Windows computer via
ssh, the following exception is launched if i execute my application :
java.lang.UnsatisfiedLinkError: Invalid access
Christopher Faylor wrote:
On Sun, Jan 04, 2004 at 04:30:56PM +0100, Theo Verelst wrote:
Anyone know wether cygwin can pass file descriptors over unix sockets
(streams) so that a process can share its file descriptors with
another?
Nope. Sorry.
--
Is it not an option because of windows streams
On Thu, Dec 25, 2003 at 12:35:01PM +0200, Miki Tebeka wrote:
> Hello All,
>
> I've written a little page on my experience with cygwin + mutt + laptops
> (reading/sending mail offline).
>
> I'd be glad to hear any comments.
>
> http://www.cs.bgu.ac.il/~tebeka/Geek/HowTo/mutt-cygwin.html
Here are
Hi all,
I've been having massive trouble getting the simplest of multithreaded
code to run successfully under cygwin without crashing and memory
corruption. I've now got a cut down testcase that as far as I can see shows
the problem to be in cygwin / stdlib / libpthread rather than in my c
koorapati wrote:
> Hey Cygwin users,
> I'm having problems compiling lyx using g++ version 3.3.1 (more
> specifically during the linking of various objects). I've attached a clip of
> the final build log. Please have a look at this. Any help or pointers on
> this will be much appreciated a
It appears that TeX does not support UNC paths while ls does.
This is strange (I expected that to be handled transparently by the dll)
$ TEXINPUTS=//host/path:.: pdflatex gdm.tex
! LaTeX Error: File `oubraces.sty' not found.
...
$ TEXINPUTS=/cygdrive/x/path:.: pdflatex gdm.tex
fine
$ ls //hos
On Mon, 5 Jan 2004, Sam Steingold wrote:
> It appears that TeX does not support UNC paths while ls does.
Which TeX?
> This is strange (I expected that to be handled transparently by the dll)
Some applications "optimize" two leading slashes into one slash. This
happens before the Cygwin DLL has
On Mon, Jan 05, 2004 at 04:10:02PM -0500, Sam Steingold wrote:
>It appears that TeX does not support UNC paths while ls does.
>This is strange (I expected that to be handled transparently by the dll)
>
>$ TEXINPUTS=//host/path:.: pdflatex gdm.tex
>
>! LaTeX Error: File `oubraces.sty' not found.
Igor Pechtchanski writes:
>> It appears that TeX does not support UNC paths while ls does.
>> This is strange (I expected that to be handled transparently by the dll)
This was disabled by default, as it clashes with the usage of '//' by
kpathsea, and you can easily work around it, as you show.
Y
> * Igor Pechtchanski <[EMAIL PROTECTED]> [2004-01-05 16:28:16 -0500]:
>
> On Mon, 5 Jan 2004, Sam Steingold wrote:
>
>> It appears that TeX does not support UNC paths while ls does.
> Which TeX?
tetex-2.0.2-13.
>> This is strange (I expected that to be handled transparently by the dll)
>
> Some
Please try running this diagnostic script
to see if it can help identify the cause
of your problem:
http://sources.redhat.com/ml/cygwin/2003-12/msg00711.html
> -Original Message-
> From: Alan London [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 01, 2004 11:38 PM
> To: [EMAIL PROTECT
Jan already answered this question (and provided a pointer to the
documentation), but for completeness' sake...
On Mon, 5 Jan 2004, Sam Steingold wrote:
> > * Igor Pechtchanski <[EMAIL PROTECTED]> [2004-01-05 16:28:16 -0500]:
> >
> > On Mon, 5 Jan 2004, Sam Steingold wrote:
> >
> >> It appears th
I was having a problem with mkcramfs on cygwin creating symbolic links
for the compressed linux filesystem.
mkcramfs uses malloc to allocate a buffer that it sends to the readlink function in
cygwin path.cc
That function uses memcpy to do a copy of the link into a buffer.
Neither mkcramfs or rea
On Tue, Jan 06, 2004 at 08:17:14AM +0800, peter garrone wrote:
>I was having a problem with mkcramfs on cygwin creating symbolic links
>for the compressed linux filesystem.
>
>mkcramfs uses malloc to allocate a buffer that it sends to the readlink function in
>cygwin path.cc
>That function uses m
lstat returns an incorrect symbolic link size, with size 11 bytes too large.
This causes mkcramfs to fail.
CYGWIN variable is set to nowinsymlinks. Set to winsymlinks, the size is about 80
bytes too large.
This is for a cygwin snapshot from September.
This program generates the error for me. Creat
On Tue, Jan 06, 2004 at 09:30:26AM +0800, peter garrone wrote:
>lstat returns an incorrect symbolic link size, with size 11 bytes too large.
lstat reports the actual size of the symlink file. Unless you can point
to a standard which indicates this is incorrect, we'll be sticking with
this long st
On Mon, Jan 05, 2004 at 08:38:24PM -0500, Christopher Faylor wrote:
>On Tue, Jan 06, 2004 at 09:30:26AM +0800, peter garrone wrote:
>>lstat returns an incorrect symbolic link size, with size 11 bytes too large.
>
>lstat reports the actual size of the symlink file. Unless you can point
>to a standa
On Mon, 5 Jan 2004, Christopher Faylor wrote:
> On Tue, Jan 06, 2004 at 08:17:14AM +0800, peter garrone wrote:
> >I was having a problem with mkcramfs on cygwin creating symbolic links
> >for the compressed linux filesystem.
> >
> >mkcramfs uses malloc to allocate a buffer that it sends to the rea
19 matches
Mail list logo
