Re: linux->cygwin cross build environment

[Chiheng Xu]

On Thu, Aug 26, 2010 at 2:24 PM, Chiheng Xu  wrote:
> I attached the scripts I used in December, 2009, trying to build a
> Cygwin cross toolchain.
>

Also attcach the MinGW scripts.





-- 
Chiheng Xu
Wuhan,China


gcc_mingw.tar.bz2
Description: BZip2 compressed data
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: linux->cygwin cross build environment

[Chiheng Xu]

On Thu, Aug 26, 2010 at 10:53 AM, Charles Wilson
 wrote:
> Last weekend I attempted to setup a linux->cygwin cross compiler (and
> basic sysroot).  However, it didn't work: while a simple C 'Hello World'
> app could be compiled, copied over to a win32 system and executed, a C++
> 'Hello World' did not:
>

I attached the scripts I used in December, 2009, trying to build a
Cygwin cross toolchain.

This is much like the MinGW cross toolchain build scripts.

The scripts seem not to be able complete the build procdure of gcc.

The Chinese characters in the scripts is encoded as gb2312.





-- 
Chiheng Xu
Wuhan,China


gcc_cygwin.tar.bz2
Description: BZip2 compressed data
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: associating device names with cygdrive directories

[Christopher Faylor]

On Wed, Aug 25, 2010 at 04:32:49PM -0500, Jeremy Bopp wrote:
>On 8/25/2010 3:42 PM, Charles D. Russell wrote:
>>  Maybe it won't always work, but with debian "mount" I get the following
>> line of output, which tells me what I want to know (and more):
>> 
>> /dev/sda1 on /live/image type vfat
>> (rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8)
>> 
>> 
>> I infer from the replies that in Cygwin there is no easier way to find
>> my way around in /dev than the way I was doing it, though I realize
>> "strings" is a better choice than "od".  With dd
>> if=/dev/sda|strings|less I discovered that /dev/sda is actually my hard
>> drive.
>
>How would you handle the case where you have more than a single mount
>which looks like that?  e.g.)
>
>/dev/sda1 on /live/image1 type vfat
>(rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8)
>/dev/sdb1 on /live/image2 type vfat
>(rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8)
>
>I think part of what Chris is saying is that you typically don't know
>for sure how Linux will associate a particular hardware device with a
>particular node in the device filesystem.

No, actually what I was saying is that the mount command doesn't know
which device is associated with a CD or disk.  Something had to
*generate* a command like:

mount -t vfat /dev/sda1 /live/image

That information usually comes from /etc/fstab and /etc/fstab would
probably be generated by something which scanned the available devices
to produce the file.

Sure, when you type "mount" you will see mounted directories but
cygdrive directories aren't really mounted in the strictest sense.  The
mount table is one place where Cygwin and Linux are quite different.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Possible tar version 1.23-1 --remove-files bug.

[Jeremy Warren]

I have duplicated the following behavior on 2 different machines
CYGWIN_NT-5.2 1.7.6(0.230/5/3) 2010-08-16 16:06 i686  (Windows 2003 R2 Server)
CYGWIN_NT-5.1 1.7.5(0.225/5/3) 2010-04-12 19:07 i686  (Windows XP Desktop)
Both are running tar version 1.23-1 and the problem is 100%
reproducible in my environment.

*Some editing has been made to the output to protect the innocent.
Any discrepancies in the output are unlikely related to the problem
itself and more likely caused by my sausage shaped fingers.

Scenario:
Given a directory with sample contents:
$ ls
file1.asc  file2.asc  file3.asc  file4.asc

the following command:
$ tar --remove-files -cvf test.tar *.asc
file1.asc
file2.asc
file3.asc
file4.asc

Produces the expected result of a single test.tar, with the 4 asc files removed.

$ ls
test.tar

And the tarball correctly contains all 4 files.

$ tar -tvf test.tar
-rw-r--r-- XX/None 22 2010-08-26 00:07 file1.asc
-rw-r--r-- XX/None 22 2010-08-26 00:07 file2.asc
-rw-r--r-- XX/None 22 2010-08-26 00:07 file3.asc
-rw-r--r-- XX/None 22 2010-08-26 00:07 file4.asc


*** PROBLEM STARTS HERE ***

The following command, using the -r (append -vs- create) switch,
correctly produces a test.tar file with all 4 files but fails to
delete the files.
$ tar --remove-files -rvf test.tar *.asc
file1.asc
file2.asc
file3.asc
file4.asc

$ ls
file1.asc  file2.asc  file3.asc  file4.asc  test.tar

$ tar -tvf test.tar
-rw-r--r-- XX/None 22 2010-08-26 00:11 file1.asc
-rw-r--r-- XX/None 22 2010-08-26 00:11 file2.asc
-rw-r--r-- XX/None 22 2010-08-26 00:11 file3.asc
-rw-r--r-- XX/None 22 2010-08-26 00:11 file4.asc

A return code of zero is produced in either instance, and the tarballs
created are both fully usable.  There is a second scenario where all
asc files are deleted except the last one (so test.tar and file4 would
be left in the directory at completion) but as of yet I cannot
reproduce that scenario at will, so I'm uncertain as to the exact
startup conditions that cause it.

In my situation using -c is not a solution since this command is
embedded within a large loop.   Each file is being processed and
appended to the archive one at a time.  The processing script worked
without issue prior to upgrading to the 1.23-1 version tar within the
last week or so.

*** Other possibly relevant pieces of information: ***

I verified using a Linux box (2.6.18-164.9.1.el5.centos.plus) running
tar (GNU tar) 1.15.1 to verify that my expectations of the command
were correct.

$ ls
file1.asc  file2.asc  file3.asc  file4.asc

$ tar --remove-files -rvf test.tar *.asc
file1.asc
file2.asc
file3.asc
file4.asc

$ ls
test.tar

$ tar -tvf test.tar
-rw-r--r-- XX/XX 22 2010-08-26 00:15:28 file1.asc
-rw-r--r-- XX/XX 22 2010-08-26 00:15:28 file2.asc
-rw-r--r-- XX/XX 22 2010-08-26 00:15:28 file3.asc
-rw-r--r-- XX/XX 22 2010-08-26 00:15:28 file4.asc

Cygwin was installed from different mirrors at different times on each machine.

It appears from the release notes that some changes were made in
1.23-1 related to the --remove-files argument
"** The --remove-files option removes files only if they were
succesfully stored in the archive."

I was unable to find any related issues in the archive but was having
trouble making the archive search match the '--remove-files' switch in
the query.  Apologies in advance if I duped.

Thanks,
Jeremy

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Emacs and DBUS

[Michael Albinus]

Ken Brown  writes:

>> The blocking you observed when dbus.el is loaded doesn't occur with a
>> build from the Emacs trunk (r101187).
>
> Correction: It occurs if and only if the system messagebus service is
> running.

I'm confused: do you mean, the problem is happening when the system bus
is running, or when it is *not* running? I suspect the latter case.

> Ken

Best regards, Michael.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Emacs and DBUS

[Michael Albinus]

Ken Brown  writes:

> Hi Michael,

Hi Ken,

> The blocking you observed when dbus.el is loaded doesn't occur with a
> build from the Emacs trunk (r101187).  But I don't know how to test
> the dbus functionality after loading dbus.el.

There is a manual, open it with (info "(dbus)")

You could check your own D-Bus name:

  (dbus-get-unique-name :system)
  (dbus-get-unique-name :session)

You could register for signals sent by the D-Bus:

  (defun my-dbus-signal-handler (&rest args)
(message "Signal from bus %s received: %s"
 (dbus-event-bus-name last-input-event) args))

  (dbus-register-signal
   :system dbus-service-dbus dbus-path-dbus dbus-interface-dbus
   "NameOwnerChanged" 'my-dbus-signal-handler)
  (dbus-register-signal
   :session dbus-service-dbus dbus-path-dbus dbus-interface-dbus
   "NameOwnerChanged" 'my-dbus-signal-handler)

Now you could open any other D-Bus application, and you shall be
notified in Emacs. Let's use dbus-monitor, started in a shell:

  # dbus-monitor --session
  # dbus-monitor --system

> If we find it works there, maybe the problem is just a matter of
> backporting some patch to Emacs 23.2.

In Emacs' trunk, there are changes how D-Bus buses are initialized for
polling of pending messages. The intention was to access non-default
buses as well, but it seems to help also for the system and session
buses on cygwin. Backporting would include both dbusbind.c and dbus.el,
because there are dependent changes. I havent't planned it yet for the
Emacs 23 branch, but why not.

> Can you tell me how to test dbus in emacs?  Or do you want me to send
> you the executable and let you test it?

Unfortunately, the next 10 days or so I won't have access to a machine
running Windows+Cygwin (I'll be on the road); accessing my email shall
be possible. I'ld like to test it when I'm back.

Thinking about, I prefer an unstripped version of emacs-x11 instead of
emacs-nox for testing.

> Ken

Best regards, Michael.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1

[Charles Wilson]

On 8/21/2010 4:54 AM, Corinna Vinschen wrote:
> On Aug 20 21:07, Charles Wilson wrote:
>> If you concur, I'll post a patch to that effect to cygwin-patches (we
>> use our own header, not newlib's, for netinet/in.h).
> 
> This is not the right solution.

OK.

> First, we don't support _BSD_SOURCE and _GNU_SOURCE, yet, since, as you
> can see in the comment in /usr/include/features.h, the groundwork is
> entirely missing.  The _POSIX_SOURCE is used in newlib in the first
> place and we can and do use it as well.  _XOPEN_SOURCE is only barely
> available for a few months now, but it's not actually used anywhere.

I see.

> On Linux, bindresvport and bindresvport6 are available by default,
> *unless* you define something like _POSIX_SOURCE. 

Right...as you pointed out below, you get the same warning on linux.

> Since newlib/Cygwin
> is missing the groundwork for a full-fledged features.h, your above
> suggestion would result in declaring bindresvport/bindresvport_sa *only
> if*  the user explicitely defines _BSD_SOURCE or _GNU_SOURCE on the
> command line.  That's not feasible.

Yes, you are correct. :-(

> The question is, why does libtirpc declare the functions at all?  Does
> it come with its own implementation? 

Yes, it does.  And, that implementation is used by the upstream source
for linux, in preference to the glibc-provided version.  I followed that
pattern in libtirpc, as well: the libtirpc version is used in preference
to cygwin's.

Not because I think there is a problem with cygwin's, but simply because
I followed the linux pattern.

Given that, I think something similar to the krb5 solution could be used
here, as well.

Unfortunately, the current cygtirpc-1.dll exports its version of
bindresvport and bindresvport_sa. That is a *problem* because anything
built against it will expect to use ITS version from now on.

Unless I rebuild with renamed versions, and bump the API number.

Or, don't bump the API number and break stuff. Since it is a new
package, and so far only Erick's private libvirt seems to use it, I'm
actually leaning that way.

Eric, any thoughts?

> Whether or not, I think the
> problem are the libtirpc headers in the first place.

OK.

> But note that this only occurs with -Wredundant-decls, which is not one
> of the default warnings.

right, but this problem did lead to the discovery of a real issue in
cygtirpc-1.dll...

I wonder if there are more issues lurking here:

The following are exported by both cygtirpc-1.dll and cygwin1.dll:
bindresvport
bindresvport_sa
getpeereid (*)

(*) implemented using
error = getsockopt(s, SOL_SOCKET, SO_PEERCRED, &uc, &uclen);
and then picking uc.uid and uc.gid (after error checking, etc).


Note that there are a number of functions declared by cygwin's 
header, but are provided by cygtirpc:

voidendrpcent  (void);
struct rpcent   *getrpcent (void);
struct rpcent   *getrpcbyname (const char *);
struct rpcent   *getrpcbynumber (int);
voidsetrpcent (int);

Interestingly, many of these apparently HAD been declared in
tirpc/rpc/rpcent.h, but were commented out (using C++ comment markers, I
might add).  But, at least that means there is no conflict with these
symbols.

--
Chuck


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

linux->cygwin cross build environment

[Charles Wilson]

Last weekend I attempted to setup a linux->cygwin cross compiler (and
basic sysroot).  However, it didn't work: while a simple C 'Hello World'
app could be compiled, copied over to a win32 system and executed, a C++
'Hello World' did not:

1) using the cygwin-provided cygstdc++-6.dll and cyggcc_s-1.dll, it
segfaulted.

2) copying over to the win32 system ALSO the cygstdc++-6.dll and
cyggcc_s-1.dll built as part of the cross toolchain, and running the C++
hello world app -- it didn't segfault. But it didn't print anything to
stdout (std::cout), either.

Now, I've build linux-hosted cross compilers before -- and I'm very
familiar with cygwin, too -- so I'm not exactly a novice here. But...I
wonder if I'm just doing something silly, and need another pair (or
hundred) of eyes to point out the obvious.

so, I've attached my build procedure (WARNING, for the archvies: the
compiler produced using this procedure is BROKEN. DO NOT USE).

I based my compiler on Dave's recent 4.5.0-1 release, and the current
cygwin binutils packages.

Anybody have a suggestion?  What am I doing wrong?

--
Chuck
HOST_TRIPLE=i686-pc-linux-gnu
HOST_PREFIX=/opt/devel/cygwin

TARGET_TRIPLE=i686-pc-cygwin
TARGET_PREFIX=/usr

SYSROOT=${HOST_PREFIX}/${TARGET_TRIPLE}/sys-root
BUILDTOP=/mnt/junk
GCCVER=4.5.0
PKGREL=1


DOWNLOADS=/opt/devel/cygwin/src/downloads
MIRROR=http://mirrors.kernel.org/sourceware/cygwin/release
export PATH=${HOST_PREFIX}/bin:/opt/devel/cygwin/src/private/bin:${PATH}

do_get () {
  pushd ${DOWNLOADS} >/dev/null
  wget ${MIRROR}/$1
  popd >/dev/null 
}


mkdir -p ${DOWNLOADS}
do_get w32api/w32api-3.14-1.tar.bz2
do_get cygwin/cygwin-1.7.6-1.tar.bz2
do_get binutils/binutils-2.20.51-2-src.tar.bz2
do_get gcc4/gcc4-4.5.0-1-src.tar.bz2

mkdir -p ${SYSROOT}
(cd ${SYSROOT} && tar xvjf ${DOWNLOADS)/w32api-3.14-1.tar.bz2)
(cd ${SYSROOT} && tar xvjf ${DOWNLOADS}/cygwin-1.7.6-1.tar.bz2)

# not sure if sysroot support extends to the w32api stuff, so
# make sure the libs that appear in the specs file exist in the
# main lib dir, and not just in the w32api subdir.  In any case,
# this is *absolutely* necessary during the build of the language
# runtime libraries...
(cd ${SYSROOT}${TARGET_PREFIX}/lib && ln -fs w32api/libkernel.a   .)
(cd ${SYSROOT}${TARGET_PREFIX}/lib && ln -fs w32api/libuser32.a   .)
(cd ${SYSROOT}${TARGET_PREFIX}/lib && ln -fs w32api/libadvapi32.a .)
(cd ${SYSROOT}${TARGET_PREFIX}/lib && ln -fs w32api/libshell32.a  .)
(cd ${SYSROOT}${TARGET_PREFIX}/lib && ln -fs w32api/libgdi32.a.)
(cd ${SYSROOT}${TARGET_PREFIX}/lib && ln -fs w32api/libcomdlg32.a .)

# ensure linux package installed: libgmp-devel, libgmp10
# ensure linux package installed: mpfr-devel, libmpfr1
# ensure linux package installed: libmpc-devel, libmpc2
# ensure linux package installed: libcloog-devel, libcloog0
# ensure linux package installed: libppl-devel, libppl7


## binutils

cd $BUILDTOP
mkdir binutils
cd binutils
tar xvjf ${DOWNLOADS}/binutils-2.20.51-2-src.tar.bz2
mkdir _build
cd _build
${BUILDTOP}/binutils/binutils-2.20.51-2/configure \
--prefix=${HOST_PREFIX} \
--host=${HOST_TRIPLE} \
--build=${HOST_TRIPLE} \
--target=${TARGET_TRIPLE} \
--with-build-sysroot=${SYSROOT} \
--with-sysroot=${SYSROOT}
make
make install DESTDIR=${BUILDTOP}/binutils/_inst
cd ${BUILDTOP}/binutils/_inst
tar cvJf ../binutils-2.20.51-2-cygwin.tar.xz opt
cd /
tar xvJf ${BUILDTOP}/binutils/binutils-2.20.51-2-cygwin.tar.xz



## custom autoconf, automake
## gcc-4.5.0 requires ac-2.64, am-1.11.1

cd ${DOWNLOADS}
wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.64.tar.bz2
wget http://ftp.gnu.org/gnu/automake/automake-1.11.1.tar.bz2

cd ${BUILDTOP}
mkdir autoconf
cd autoconf
tar xvjf ${DOWNLOADS}/autoconf-2.64.tar.bz2
mkdir _build
cd _build
${BUILDTOP}/autoconf/autoconf-2.64/configure --prefix=${BUILDTOP}/private
make
make install

cd ${BUILDTOP}
mkdir automake
cd automake
tar xvjf ${DOWNLOADS}/automake-1.11.1.tar.bz2
mkdir _build
cd _build
${BUILDTOP}/automake/automake-1.11.1/configure --prefix=${BUILDTOP}/private
make
make install
mkdir -p ${BUILDTOP}/private/share/aclocal
echo '/usr/share/aclocal' > ${BUILDTOP}/private/share/aclocal/dirlist



## gcc

cd $BUILDTOP
mkdir gcc45
cd gcc45
tar xvjf ${DOWNLOADS}/gcc4-4.5.0-1-src.tar.bz2
tar xvjf gcc-4.5.0.tar.bz2
cd gcc-4.5.0
patch -p2 < ../classpath-0.98-FIONREAD.patch
patch -p2 < ../classpath-0.98-build.patch
patch -p2 < ../classpath-0.98-awt.patch
patch -p2 < ../gcc45-ada.diff
patch -p0 < ../gcc45-cygwin-lto.diff
patch -p2 < ../gcc45-ehdebug.diff
patch -p2 < ../gcc45-libffi.diff
patch -p2 < ../gcc45-libstdc.diff
patch -p2 < ../gcc45-misc-core.diff
patch -p2 < ../gcc45-mnocygwin.diff
patch -p0 < ../gcc45-sig-unwind.diff
pa

Re: associating device names with cygdrive directories

[Andrey Repin]

Greetings, Charles D. Russell!

>   Maybe it won't always work, but with debian "mount" I get the 
> following line of output, which tells me what I want to know (and more):

> /dev/sda1 on /live/image type vfat 
> (rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8)

> I infer from the replies that in Cygwin there is no easier way to find 
> my way around in /dev than the way I was doing it, though I realize 
> "strings" is a better choice than "od".  With dd 
> if=/dev/sda|strings|less I discovered that /dev/sda is actually my hard 
> drive.

It's a very rough guess, and only work in limited amount of instances.
You still have to check if the target device you got from mount table is
actually a block device.

And, please, use "reply" option when replying to list, instead of writing new
message.


--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 26.08.2010, <6:31>

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: associating device names with cygdrive directories

[Jeremy Bopp]

On 8/25/2010 3:42 PM, Charles D. Russell wrote:
>  Maybe it won't always work, but with debian "mount" I get the following
> line of output, which tells me what I want to know (and more):
> 
> /dev/sda1 on /live/image type vfat
> (rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8)
> 
> 
> I infer from the replies that in Cygwin there is no easier way to find
> my way around in /dev than the way I was doing it, though I realize
> "strings" is a better choice than "od".  With dd
> if=/dev/sda|strings|less I discovered that /dev/sda is actually my hard
> drive.

How would you handle the case where you have more than a single mount
which looks like that?  e.g.)

/dev/sda1 on /live/image1 type vfat
(rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8)
/dev/sdb1 on /live/image2 type vfat
(rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8)

I think part of what Chris is saying is that you typically don't know
for sure how Linux will associate a particular hardware device with a
particular node in the device filesystem.  Looking at the mount table is
only useful in extremely limited circumstances, such as when you only
have a single device that always mounts to a well-known mount point.

Since Windows handles the "automounting" for Cygwin, you have to depend
on Windows to always assign the same drive letter to the device, thus
creating your well-known mount point (/cygdrive/d, for example).
However, I don't believe there is any way to force that under Windows,
so if some other device loads first and takes the drive letter you
usually get, your second device will automatically get a different drive
letter.  This is outside of Cygwin's control in any case.

If you want to avoid the hacks you describe above, you'll need to talk
to Windows in order to locate some sort of unique identifier for your
device and use that to ultimately identify the POSIX device path,
perhaps via the drive letter and Barry's trick.  Under Linux you would
essentially use sysfs to do a similar task.  Anything less, especially
since you're talking about using dd to write to the device, will likely
lead to unhappiness.

-Jeremy

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: associating device names with cygdrive directories

[Jeremy Bopp]

On 8/25/2010 3:32 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> On Wed, Aug 25, 2010 at 02:47:21PM -0500, Charles D. Russell wrote:
>> On Linux, the mount command reveals the association between filesystem 
>> names and /dev/ names, but Cygwin mount doesn't tell.
> 
> Is this what you want?  (The multiple spaces are really tabs.)
> 
> $ for F in /dev/s* ; do echo "$F$(cygpath -w $F)" ; done
> /dev/scd0   \\.\D:
> /dev/scd1   \Device\CdRom1
> /dev/scd2   \Device\CdRom2



That's a pretty clever solution.  Too bad there is no way to use cygpath
to go the other direction.  Ideally, we could do something like:

$ cygpath -t device D:
/dev/scd0

Of course it's hard to justify adding such functionality without a good
use case.

-Jeremy


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: associating device names with cygdrive directories

[Charles D. Russell]

 Maybe it won't always work, but with debian "mount" I get the 
following line of output, which tells me what I want to know (and more):


/dev/sda1 on /live/image type vfat 
(rw,noatime,fmask=0022,dmask=0022,allow_utime=17,codepage=cp437,iocharset=utf8)


I infer from the replies that in Cygwin there is no easier way to find 
my way around in /dev than the way I was doing it, though I realize 
"strings" is a better choice than "od".  With dd 
if=/dev/sda|strings|less I discovered that /dev/sda is actually my hard 
drive.




--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: associating device names with cygdrive directories

[Larry Hall (Cygwin)]

On 8/25/2010 4:11 PM, Jeremy Bopp wrote:

On 8/25/2010 3:03 PM, Christopher Faylor wrote:

On Wed, Aug 25, 2010 at 02:47:21PM -0500, Charles D. Russell wrote:

On Linux, the mount command reveals the association between filesystem
names and /dev/ names, but Cygwin mount doesn't tell.


Sorry that's not how the mount command works on Linux.  It's not always
easy to tell the device associated on linux either.  Sometimes you need
to look at dmesg output.  Unfortunately cygwin has nothing similar.


The wodim command from the cdrtools package includes logic (-scanbus
option) which is able to identify SCSI devices under Cygwin.  It doesn't
map them to the /dev namespace, but it shows that something like you
need may be possible.  Wodim is also able to take a drive letter and
directly use that when writing an ISO file to the drive.

Maybe you could start there and craft a tool to do what you need.


That might be the easiest way to creating a tool, since you'd have
existing logic to leverage.  But to answer your original question, you
can certainly use the information from Disk Management to figure out
the mapping.



should help in that regard.  But essentially, "Disk 0" = /dev/sda, etc.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: associating device names with cygdrive directories

[Buchbinder, Barry (NIH/NIAID) [E]]

On Wed, Aug 25, 2010 at 02:47:21PM -0500, Charles D. Russell wrote:
>On Linux, the mount command reveals the association between filesystem 
>names and /dev/ names, but Cygwin mount doesn't tell.

Is this what you want?  (The multiple spaces are really tabs.)

$ for F in /dev/s* ; do echo "$F$(cygpath -w $F)" ; done
/dev/scd0   \\.\D:
/dev/scd1   \Device\CdRom1
/dev/scd2   \Device\CdRom2
/dev/sda\\.\PhysicalDrive0
/dev/sda1   \\.\Volume{39f65722-0106-11df-b1c0-806d6172696f}
/dev/sda2   \Device\Harddisk0\Partition2
/dev/sdb\Device\Harddisk1\Partition0
/dev/sdb1   \Device\Harddisk1\Partition1
/dev/sdb2   \Device\Harddisk1\Partition2
/dev/sdc\Device\Harddisk2\Partition0
/dev/sdc1   \Device\Harddisk2\Partition1
/dev/sdc2   \Device\Harddisk2\Partition2
/dev/shmC:\cygwin\dev\shm
/dev/sr0\\.\D:
/dev/sr1\Device\CdRom1
/dev/sr2\Device\CdRom2
/dev/st0\Device\Tape0
/dev/st1\Device\Tape1
/dev/st2\Device\Tape2
/dev/stderr \dev\tty
/dev/stdin  \dev\tty
/dev/stdout /proc/2476/fd/pipe:[504]

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: associating device names with cygdrive directories

[Jeremy Bopp]

On 8/25/2010 3:03 PM, Christopher Faylor wrote:
> On Wed, Aug 25, 2010 at 02:47:21PM -0500, Charles D. Russell wrote:
>> On Linux, the mount command reveals the association between filesystem
>> names and /dev/ names, but Cygwin mount doesn't tell.
> 
> Sorry that's not how the mount command works on Linux.  It's not always
> easy to tell the device associated on linux either.  Sometimes you need
> to look at dmesg output.  Unfortunately cygwin has nothing similar.

The wodim command from the cdrtools package includes logic (-scanbus
option) which is able to identify SCSI devices under Cygwin.  It doesn't
map them to the /dev namespace, but it shows that something like you
need may be possible.  Wodim is also able to take a drive letter and
directly use that when writing an ISO file to the drive.

Maybe you could start there and craft a tool to do what you need.

-Jeremy

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: associating device names with cygdrive directories

[Christopher Faylor]

On Wed, Aug 25, 2010 at 02:47:21PM -0500, Charles D. Russell wrote:
>On Linux, the mount command reveals the association between filesystem
>names and /dev/ names, but Cygwin mount doesn't tell.

Sorry that's not how the mount command works on Linux.  It's not always
easy to tell the device associated on linux either.  Sometimes you need
to look at dmesg output.  Unfortunately cygwin has nothing similar.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: associating device names with cygdrive directories

[Charles D. Russell]

 On 8/25/2010 2:49 PM, Charles D. Russell wrote:

What is the best way to find or predict the association of a given 
/dev/sd?

with the corresponding /cygdrive/?. Is there a good way to verify the
assignment before writing to the device with dd?


I think this link should help a little:



The POSIX device names are generated from the Windows information/layout
of these devices.  So your best bet is to look to Windows to get the
device number <-> drive letter association and then fill in the rest
from there.


I had read that reference, but don't see how it helps to find whether a 
given USB storage
device is sda, sdb, or whatever. I found that a flash drive was /dev/sdc 
by unplugging all other
USB devices and trial-and-error with dd if=/dev/sdc |od|less, but there 
must be a better way. I want to use multiple USB devices at the same 
time, and they don't all have stuff on them that I can recognize in 
binary. On Linux, the mount command reveals the association between 
filesystem names and /dev/ names, but Cygwin mount doesn't tell.


The cited reference mentions "NT internal device" names, but I don't 
know what those are or how to
find them. Is there some connection with the device numbers revealed by 
the Control Panel under "Windows Computer Management/Storage/Disk 
Management"?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: associating device names with cygdrive directories

[Larry Hall (Cygwin)]

On 8/25/2010 2:49 PM, Charles D. Russell wrote:

What is the best way to find or predict the association of a given /dev/sd?
with the corresponding /cygdrive/?. Is there a good way to verify the
assignment before writing to the device with dd?


I think this link should help a little:



The POSIX device names are generated from the Windows information/layout
of these devices.  So your best bet is to look to Windows to get the
device number <-> drive letter association and then fill in the rest
from there.  There is no "one-stop shopping" utility that I know of
that will do all that for you.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

associating device names with cygdrive directories

[Charles D. Russell]

 What is the best way to find or predict the association of a given 
/dev/sd? with the corresponding /cygdrive/?.  Is there a good way to 
verify the assignment before writing to the device with dd?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Build S-Lang Fail

[Larry Hall (Cygwin)]

On 8/25/2010 8:58 AM, Csaba Raduly wrote:

On Sun, Aug 22, 2010 at 8:15 PM, Steven Woody  wrote:


$ ldd /usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1.exe
ntdll.dll =>  /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7c92)
kernel32.dll =>  /cygdrive/c/WINDOWS/system32/kernel32.dll (0x7c80)
cyggcc_s-1.dll =>  /usr/bin/cyggcc_s-1.dll (0x67f0)
cygwin1.dll =>  /usr/bin/cygwin1.dll (0x6100)
ADVAPI32.DLL =>  /cygdrive/c/WINDOWS/system32/ADVAPI32.DLL (0x77da)
RPCRT4.dll =>  /cygdrive/c/WINDOWS/system32/RPCRT4.dll (0x77e5)
Secur32.dll =>  /cygdrive/c/WINDOWS/system32/Secur32.dll (0x77fc)
cyggmp-3.dll =>  /usr/bin/cyggmp-3.dll (0x63f4)
cygmpfr-1.dll =>  /usr/bin/cygmpfr-1.dll (0x6cd8)



You could either run ldd on the DLLs (cyggcc_s-1.dll, cyggmp-3.dll and
cygmpfr-1.dll) or use depends.exe (http://www.dependencywalker.com/)
to try to identify the missing DLL.


'cygcheck' is also an option as well.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Emacs and DBUS

[Ken Brown]

On 8/25/2010 10:37 AM, Ken Brown wrote:

On 8/25/2010 10:02 AM, Ken Brown wrote:



On 8/24/2010 11:28 PM, Michael Albinus wrote:

Ken Brown  writes:


After installing that library, Emacs did start. How ever, it blocks
when loading dbus.el.


Don't you normally have to start a D-BUS session before loading
dbus.el? Maybe one of the Cygwin people who uses D-BUS can tell us how
to do that.


I've started the session bus via dbus-launch in advance, of course. I
have no idea, how to start the system bus in cygwin, 'though.


Run /usr/bin/messagebus-config and follow the instructions for
installing messagebus as a service.  You will need to be logged in as a
user with administrator privileges for this.


Emacs' D-Bus code shall be resistent in case of absence of a bus, but
who knows ... how could I debug it via gdb?


The executable /usr/bin/emacs-nox.exe is stripped; that's why you
couldn't debug it.  Here's a link to the unstripped version, with debug
symbols:

 http://www.math.cornell.edu/~kbrown/emacs-nox.exe.bz2


Hi Michael,

The blocking you observed when dbus.el is loaded doesn't occur with a
build from the Emacs trunk (r101187).


Correction: It occurs if and only if the system messagebus service is 
running.


Ken

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Emacs and DBUS

[Ken Brown]

On 8/25/2010 10:02 AM, Ken Brown wrote:



On 8/24/2010 11:28 PM, Michael Albinus wrote:

Ken Brown  writes:


After installing that library, Emacs did start. How ever, it blocks
when loading dbus.el.


Don't you normally have to start a D-BUS session before loading
dbus.el? Maybe one of the Cygwin people who uses D-BUS can tell us how
to do that.


I've started the session bus via dbus-launch in advance, of course. I
have no idea, how to start the system bus in cygwin, 'though.


Run /usr/bin/messagebus-config and follow the instructions for
installing messagebus as a service.  You will need to be logged in as a
user with administrator privileges for this.


Emacs' D-Bus code shall be resistent in case of absence of a bus, but
who knows ... how could I debug it via gdb?


The executable /usr/bin/emacs-nox.exe is stripped; that's why you
couldn't debug it.  Here's a link to the unstripped version, with debug
symbols:

http://www.math.cornell.edu/~kbrown/emacs-nox.exe.bz2


Hi Michael,

The blocking you observed when dbus.el is loaded doesn't occur with a 
build from the Emacs trunk (r101187).  But I don't know how to test the 
dbus functionality after loading dbus.el.  If we find it works there, 
maybe the problem is just a matter of backporting some patch to Emacs 
23.2.  Can you tell me how to test dbus in emacs?  Or do you want me to 
send you the executable and let you test it?


Ken

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: gcc-4.5 notes

[Reini Urban]

Hi Dave,

Aside from Yaakov's notes I have nothing to fix.
Just to add that it is working fine for me. I've rebuilt
some of my perls with extensive testsuites and everything
so far was fine.
Yaakov's tests are obviously better than mine.

May I ask when can we expect gcc-4.5.0 going stable?

Because I want the pending perl-5.10.1-4 update which changes
cc from gcc to gcc-4 and fixes some more minor stuff to be done
with the new gcc-4.5.x.
But if it's more than one week I'll revert to the old compiler.


2010/8/16 Yaakov (Cygwin/X):
> Dave,
> Several notes about gcc-4.5.0:
>
> 1) I'm using a new FIONREAD patch for Classpath which solves several
> issues.  Matching patch for gcc-4.5 attached.
>
> 2) fix-libtool-scripts-for-latest-gcc-runtimes.sh doesn't actually do
> anything; 's|echo sed|sed|g' fixes that.
>
> 3) libgnat import libs are missing:
>
> $ gnatmake hello.adb -bargs -shared
> gcc -c hello.adb
> gnatbind -shared -x hello.ali
> gnatlink hello.ali -shared-libgcc
> /usr/lib/gcc/i686-pc-cygwin/4.5.0/../../../../i686-pc-cygwin/bin/ld:
> cannot find -lgnat-4.5
> collect2: ld returned 1 exit status
> gnatlink: error when calling /usr/bin/gcc.exe
> gnatmake: *** link failed.
>
> Looking at gcc/ada/gcc-interface/Makefile.in, it looks like there is
> supposed to be a adalib/libgnat-4.5.dll.a symlink, but it's not quite
> right.  Patch for 4.5.1 attached.
>
> 4) After creating said symlink, the resulting binary outputs "Hello,
> world!" but does not exit, and requires kill -f to terminate.  The same
> code linked statically (IOW w/o "-bargs -shared") runs and exits
> correctly.
>
> 5) Several -4-suffixed programs have no unversioned alternatives; this
> includes: aot-compile, gccbug, jcf-dump, rebuild-gcj-db.  (Of course, if
> we drop gcc3, or at least its alternatives, then gcc4 can be
> unversioned, making this point moot.)
>
> 6) Are the gcj tools working?  If not, perhaps they should just be
> dropped until they get figured out.  An alternative would be for me to
> ITP my Classpath-based stack.
>
> 7) jni.h and jni_md.h should probably be shipped with gcc4-java instead
> of gcc4-core.
>
> 8) It would be helpful if gcc4-core would provide a libffi.pc pkg-config
> file, since for us this is *the* libffi.
-- 
Reini Urban
http://phpwiki.org/           http://murbreak.at/

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Emacs and DBUS

[Ken Brown]

On 8/24/2010 11:28 PM, Michael Albinus wrote:

Ken Brown  writes:


After installing that library, Emacs did start. How ever, it blocks
when loading dbus.el.


Don't you normally have to start a D-BUS session before loading
dbus.el? Maybe one of the Cygwin people who uses D-BUS can tell us how
to do that.


I've started the session bus via dbus-launch in advance, of course. I
have no idea, how to start the system bus in cygwin, 'though.


Run /usr/bin/messagebus-config and follow the instructions for 
installing messagebus as a service.  You will need to be logged in as a 
user with administrator privileges for this.



Emacs' D-Bus code shall be resistent in case of absence of a bus, but
who knows ... how could I debug it via gdb?


The executable /usr/bin/emacs-nox.exe is stripped; that's why you 
couldn't debug it.  Here's a link to the unstripped version, with debug 
symbols:


  http://www.math.cornell.edu/~kbrown/emacs-nox.exe.bz2

Ken

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] New package: ngspice-21-1

[Marco Atzeri]

Hi,
NGSPICE is now available for cygwin.
The version ngspice-21-1 has been uploaded.

DESCRIPTION
Ngspice is a mixed-level/mixed-signal circuit simulator.
Its code is based on Spice3f5. Ngspice is part of gEDA project,
a full GPL'd suite of Electronic Design Automation tools.

HOMEPAGE
http://ngspice.sourceforge.net

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.







--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Build S-Lang Fail

[Csaba Raduly]

On Sun, Aug 22, 2010 at 8:15 PM, Steven Woody  wrote:
>
> $ ldd /usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1.exe
>        ntdll.dll => /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7c92)
>        kernel32.dll => /cygdrive/c/WINDOWS/system32/kernel32.dll (0x7c80)
>        cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x67f0)
>        cygwin1.dll => /usr/bin/cygwin1.dll (0x6100)
>        ADVAPI32.DLL => /cygdrive/c/WINDOWS/system32/ADVAPI32.DLL (0x77da)
>        RPCRT4.dll => /cygdrive/c/WINDOWS/system32/RPCRT4.dll (0x77e5)
>        Secur32.dll => /cygdrive/c/WINDOWS/system32/Secur32.dll (0x77fc)
>        cyggmp-3.dll => /usr/bin/cyggmp-3.dll (0x63f4)
>        cygmpfr-1.dll => /usr/bin/cygmpfr-1.dll (0x6cd8)
>

You could either run ldd on the DLLs (cyggcc_s-1.dll, cyggmp-3.dll and
cygmpfr-1.dll) or use depends.exe (http://www.dependencywalker.com/)
to try to identify the missing DLL.


-- 
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: SuiteSparse-3.5.0-1

[Marco Atzeri]

New versions of

SuiteSparse / libSuiteSparse-devel 3.5.0-1

for cygwin are available in the Cygwin distribution:

CHANGES
These are new upstream versions, mainly bugfix

DESCRIPTION
SuiteSparse is library for sparse matrix.
It is used to compile Octave

HOMEPAGE
http://www.cise.ufl.edu/research/sparse/SuiteSparse/

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.







--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: lapack 3.2.2-1

[Marco Atzeri]

New versions 3.2.2-1 of

lapack (source)
liblapack0
liblapack-devel

for cygwin are available in the Cygwin distribution:

CHANGES
These are new bugfix upstream versions

Full list of changes at:
http://www.netlib.org/lapack/lapack-3.2.html
http://www.netlib.org/lapack/lapack-3.2.1.html
http://www.netlib.org/lapack/lapack-3.2.2.html

xblas is NOT yet implemented for cygwin.

DESCRIPTION
Comprehensive FORTRAN library for linear algebra operations.
Includes matrix inversions, least squared solutions to
sets of equations, eigenvector analysis, singular value
decomposition, etc.

HOMEPAGE
http://www.netlib.org/lapack/

Regards
Marco Atzeri
If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.






--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: {libqhull-devel, libqhull_5, qhull}-qhull-2010.1-1

[Marco Atzeri]

Versions qhull-2010.1-1 of
libqhull-devel, libqhull_5, qhull
have been uploaded for cygwin

CHANGES
This is an upstream maintenance release

For the full changes
http://www.qhull.org/src/Changes.txt


DESCRIPTION
Qhull is a general dimension convex hull program and library
It computes volumes, surface areas, and approximations to
the convex hull.

HOMEPAGE
http://www.qhull.org/

Regards
Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.






--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: lighttpd, nano, tidy: update (ping?)

[Andy Koppe]

On 25 August 2010 10:50, Yaakov (Cygwin/X) wrote:
> Lapo,
>
> Ping on updates for lighttpd, nano and tidy?
>
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=apps/nano

Yeah, an update for nano would be really nice. Is the
2.2.4-wchar.patch still needed? 2.2.5 builds out-of-the-box for me,
with plain './configure' enabling UTF-8 and picking up ncursesw.

Andy

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

lighttpd, nano, tidy: update (ping?)

[Yaakov (Cygwin/X)]

Lapo,

Ping on updates for lighttpd, nano and tidy?

http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=apps/nano
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=libs/tidy
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ports;a=tree;f=www/lighttpd


Yaakov



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with php and/or tidy packages?

[Yaakov (Cygwin/X)]

On Wed, 2010-08-25 at 09:04 +0200, Gary wrote:
> Today I updated my cygwin installation and found that afterwards php
> (from cygwin ports) no longer worked correctly with tidy (official
> package):

Questions regarding Ports packages are off-topic on the Cygwin lists.  I
have answered this question on cygwin-ports-general, the correct forum
for these questions.


Yaakov



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: 1.7: Basic file operations fail on network shares provided by Tru64 Advanced Server

[Corinna Vinschen]

On Aug 25 08:55, Heinz Werner Kramski wrote:
> Am 24.08.2010 18:28, schrieb Corinna Vinschen:
> >I prepared another DLL, which is very close to the "real" thing.
> >There's another flag which I have to know if it's required or not.
> >
> >   http://cygwin.de/cygwin-ug-177/cygwin1-test4.dll.bz2
> >   (md5sum 889a86df2c2aafd010249b27bf10f411)
> >
> >If it works, we're finished.  If not, we probably need just one more
> >iteration.
> 
> Test4 works, great.

Cool.  Thank you.  I applied the patch to CVS.  This will be in
Cygwin 1.7.7.

> $ mount
> //dlanserv/kramski$ on /mnt type cifs (binary,notexec,ihash,user)
> C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
> C:/cygwin on / type ntfs (binary,auto)
> C:/bin32 on /usr/local/bin type ntfs (binary)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
> E: on /cygdrive/e type cifs (binary,posix=0,user,noumount,auto)
> [...]
> 
> >As for the ihash issue, after giving this some thought I tend to keep it
> >as it is, so you will have to use it on your Tru64 drives.  At least for
> >the next Cygwin release 1.7.7.  If it's getting too awkward at some
> >point, we can discuss this again.
> 
> As you see, I have quite a lot of network drives, so I'm considering
> putting the ihash option globally to the uncommented /cygdrive
> mountpoint in /etc/fstab to cure all drives altogether. Will that
> cause any disadvantages for the real hardware NTFS drives C: and D:?
> (Doesn't look so at a first glance.)

As you can see in the User's Guide
(http://cygwin.com/cygwin-ug-net/using.html#mount-table)
the ihash mount option results in ignoring the real inode numbers and
just fake them by computing a hash value from the full pathname of the
file.  The disadvantage is that you can't recognize hardlinks.  That's
the reason I don't want to enforce the option on all NTFS-faking file
systems (== "cifs").  If you think that's not a problem for you, you're
all set.  Otherwise, just add explicit mount points for your two local
NTFS drives with different mount options.

> Please note the nice effect that ihashing /cygdrive/e also cures
> //dlanserv/KRAMSKI$, my Cygwin $HOME, which - apart from this
> testing - is not explicitly listed by mount. (My home share
> //dlanserv/KRAMSKI$ is mapped to E: on Windows).

Yep, that's noted in the news for 1.7.2:
http://cygwin.com/cygwin-ug-net/ov-new1.7.html#ov-new1.7.2
UNC paths now default to the same mount options as the cygdrive prefix.


Thanks again for testing,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple