Re: Configure error while installing musrfit ('C compiler cannot create executables')
On 12/08/2014 08:41, Philipp wrote:
I'm trying to install 'musrfit' on cygwin following these
(http://lmu.web.psi.ch/musrfit/user/MUSR/MusrFitSetup.html#A_4_MS_Windows)
instructions. When it comes to
./configure --prefix=$ROOTSYS
however, I get following error message:
configure:3985: error: C compiler cannot create executables
See `config.log' for more details
I guess you have a wrong or broken assembler on the path
configure:3914: checking whether the C compiler works
configure:3936: gccconftest.c >&5
/tmp/ccx4LEUS.s: Assembler messages:
/tmp/ccx4LEUS.s:8: Error: bad register name `%rbp'
/tmp/ccx4LEUS.s:9: Warning: .seh_pushreg ignored for this target
/tmp/ccx4LEUS.s:10: Error: bad register name `%rsp'
/tmp/ccx4LEUS.s:11: Warning: .seh_setframe ignored for this target
/tmp/ccx4LEUS.s:12: Error: bad register name `%rsp'
/tmp/ccx4LEUS.s:13: Warning: .seh_stackalloc ignored for this target
/tmp/ccx4LEUS.s:17: Error: bad register name `%rsp'
/tmp/ccx4LEUS.s:18: Error: bad register name `%rbp'
/tmp/ccx4LEUS.s:20: Warning: zero assumed for missing expression
/tmp/ccx4LEUS.s:20: Warning: zero assumed for missing expression
configure:3940: $? = 1
configure:3978: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "musrfit"
| #define PACKAGE_TARNAME "musrfit"
| #define PACKAGE_VERSION "0.11.0"
| #define PACKAGE_STRING "musrfit 0.11.0"
| #define PACKAGE_BUGREPORT "andreas.su...@psi.ch"
| #define PACKAGE_URL ""
| #define PACKAGE "musrfit"
| #define VERSION "0.11.0"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
--
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: Missing Dependency
On Aug 11 13:56, Karl M wrote: > Hi All... > > > I just did two 32 bit Cygwin + OpenSSH installs on brand new machines > (Win 64), and received an error message that cyggmp3.dll could not be > found. I installed libgmp3 and that resolved the issue. That's a bit low on information. What application did you get the error message from? Neither ssh nor sshd depend on libgmp. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpuATktZbazO.pgp Description: PGP signature
Re: Impending ITP of Sendmail
On Aug 12 08:41, D. Boland wrote: > Jason Tishler wrote: > > > > Daniel, > > > > On Mon, Aug 11, 2014 at 12:46:54PM +0200, Corinna Vinschen wrote: > > > On Aug 9 22:41, D. Boland wrote: > > > > [snip] > > > > To accomplished this, procmail would have to be modified slightly. > > > > From the Cygwin website, I can see that procmail is maintained bij > > > > Jason Tishler. > > > > > > > > I need these modifications for Sendmail to work. I remember Corinna > > > > mentioning that the package is old and needs to be updated. Maybe it > > > > is orphaned? In that case I'd be happy to adopt it. > > > > > > Jason, ping? > > > > > > I already built procmail for x86_64 becasue Jason hadn't much time way > > > back when. Dependent on his current workload he might be glad to hand > > > over procmail. > > > > Yes, you are welcome to adopt procmail. > > > > Thanks, > > Jason > > Thank you, Jason. Now I can unleash the ancient, though awesome power > of Sendmail onto the Cygwin world. ;-) You forgot the evil laughter: Muhahaha! There, fixed it for you. :) Now, if somebody would take a stab at postfix, too :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpAkAd_EzyaA.pgp Description: PGP signature
Re: New Git v2.0.4 build to test
Adam Dinwoodie dinwoodie.org> writes: > If anyone's really interested in following my progress at home, or > building for themselves based of my latest code, you can follow along at > my GitHub repository at https://github.com/me-and/Cygwin-Git. I've been using this for about a week now and have not hit upon any snags so far. Regards, Achim. -- 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: Security Settings for directories created in Cygwin (+ executable bit on files)
Sebastien Vauban writes: > Currently, whenever I create new files from Windows 8 executables (such > as Notepad), they're often flagged as "executable", even for text files! > > I've noticed that such a behavior happens when I create a new file in > a directory that has been made FROM CYGWIN (`mkdir ~/test/', for > example). > > Indeed, the permissions of CYGWIN-CREATED DIRECTORIES seem very weird: > > - "Inherited from"... "None"! > > - "All Users" having "Read & Execute" permission on "this folder, > subfolders and FILES"... > > IIUC, when creating a new file from Cygwin, the `umask' (022, in my > case) is respected and new files are not executables then, except if > I require it explicitly (via `chmod'). > > Though, when creating a new file from a Windows executable, Windows > inherits permissions from the folder where my file gets created -- > hence, an executable permission if the directory was created from > Cygwin... > > How to correct that? > > Asking Cygwin to stop playing with the Windows ACL, by mounting my > personal directories as "noacl"? Well, that means I won't be able to > use `chmod' anymore, for setting a script file as "executable", then. > And I'll have to use a Windows tool to do so, such as `cacls'. ... Hello, there is a possibility to get bettter permission settings on files created by a windows program inside a directory created by cygwin. you must create special ACE's on this directory like in the following example with german names used in one of my scripts: icacls "$dir" /remove ERSTELLER-BESITZER icacls "$dir" /grant 'ERSTELLER-BESITZER:(OI)(IO)(R,W,D,WDAC,WO)' icacls "$dir" /grant 'ERSTELLER-BESITZER:(CI)(IO)(F)' icacls "$dir" /remove ERSTELLERGRUPPE icacls "$dir" /grant 'ERSTELLERGRUPPE:(OI)(IO)(R,W)' icacls "$dir" /grant 'ERSTELLERGRUPPE:(CI)(IO)(RX,W,DC)' icacls "$dir" /remove Jeder icacls "$dir" /grant 'Jeder:(RX)' icacls "$dir" /grant 'Jeder:(OI)(IO)(R)' icacls "$dir" /grant 'Jeder:(CI)(IO)(RX)' It creates different Default ACE's for files an directories and these will be inherited correctly when using non-cygwin-windows programs. For dirctories the execute permission is inherited b ut for files it is not inherited. In cygwin-programs the umask is used and executable flags are not requested for files which are not executables where the compiler wil do this. All works correctly in both windows-only programs and cygwin programs unless creating a subdirectory by cygwin - this will not inherit those special default ACE's to apply only to directories or only to files and thus this behaviour is lost in a subdirectory created via cygwin. On the other hand, in cygwin directory creation simple default ACE's which are to be applied on all directories and files are inhereted to subdirectories. Thus personally I use those special ACE's on directories only in the SVN (windows program) tree created by checkout to avoid execute permissions on files. when creating a new directory there which is generally done via cygwin I add the listed ACE's via script. To have those DEFAULT ACE's of general use for integration of cygwin and windows without always executing a script after creating a new directory in cygwin it would be necessary to inherit those none-simple DEFAULT ACE's in cygwin directory creation also, not onle the simple ones. A drawback for this may be the fact the gefacl/setfacl utilities does not understand those ACE's and thus don't show / don't set it. regards kf -- 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: Security Settings for directories created in Cygwin (+ executable bit on files)
On Aug 12 10:51, Kurt Franke wrote: > Sebastien Vauban writes: > > [...] > > Asking Cygwin to stop playing with the Windows ACL, by mounting my > > personal directories as "noacl"? Well, that means I won't be able to > > use `chmod' anymore, for setting a script file as "executable", then. > > And I'll have to use a Windows tool to do so, such as `cacls'. > ... > > Hello, > > there is a possibility to get bettter permission settings on files created > by a windows program inside a directory created by cygwin. > you must create special ACE's on this directory like in the following > example with german names used in one of my scripts: > > icacls "$dir" /remove ERSTELLER-BESITZER > icacls "$dir" /grant 'ERSTELLER-BESITZER:(OI)(IO)(R,W,D,WDAC,WO)' > icacls "$dir" /grant 'ERSTELLER-BESITZER:(CI)(IO)(F)' That's "CREATOR OWNER" in english systems. > icacls "$dir" /remove ERSTELLERGRUPPE > icacls "$dir" /grant 'ERSTELLERGRUPPE:(OI)(IO)(R,W)' > icacls "$dir" /grant 'ERSTELLERGRUPPE:(CI)(IO)(RX,W,DC)' > icacls "$dir" /remove Jeder > icacls "$dir" /grant 'Jeder:(RX)' > icacls "$dir" /grant 'Jeder:(OI)(IO)(R)' > icacls "$dir" /grant 'Jeder:(CI)(IO)(RX)' "CREATOR GROUP" > It creates different Default ACE's for files an directories and these will > be inherited correctly when using non-cygwin-windows programs. For > dirctories the execute permission is inherited b ut for files it is not > inherited. > [...] > To have those DEFAULT ACE's of general use for integration of cygwin and > windows without always executing a script after creating a new directory in > cygwin it would be necessary to inherit those none-simple DEFAULT ACE's in > cygwin directory creation also, not onle the simple ones. > A drawback for this may be the fact the gefacl/setfacl utilities does not > understand those ACE's and thus don't show / don't set it. It complicates handling of default permissions in the acl system calls a lot. You'd have to handle two CREATOR OWNER ACEs as a single "default:user" entry. Same for "CREATOR GROUP". I'm not saying this is impossible to implement, just that it's a good amount of work. http://cygwin.com/acronyms/#PGA Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgploBVLdWOZW.pgp Description: PGP signature
Re: [ANNOUNCEMENT] New package: rng-tools-5-1
On 2014-08-09 16:37, Corinna Vinschen wrote:
> I just uploaded rng-tools-5-1.
>
> The Cygwin release only comes with the rngtest tool for now.
>
> The rngd daemon requires porting assembler code to COFF and the
> Microsoft calling convention. Any help porting this code would
> be greatly appreciated.
Ok, I took a stab at it. The problems I identified in the assembly
are ELF debug info, different register use for the x86-64 calls and
a missing underscore prefix for the i686 symbols.
I'm unsure if used registers (and which) have to be saved in the
MS x86-64 ABI, but that shouldn't be too hard to fix if that's the
case.
I also moved up the AC_SEARCH_LIBS hunk in configure.ac since
the existing AC_CHECK_LIB is buried inside some other construct
(AC_CHECK_HEADER is possibly the culprit) which causes this:
checking for library containing argp_parse...
/usr/src/rng-tools-5-1.src/rng-tools-5-1.i686/src/rng-tools-5/configure: line
4335: ac_fn_c_try_link: command not found
/usr/src/rng-tools-5-1.src/rng-tools-5-1.i686/src/rng-tools-5/configure: line
4335: ac_fn_c_try_link: command not found
no
Anyway, with the attached patch instead of the one included in the
src package, it builds for both arches, but my cpu appears to lack
the rdrand instruction, so I have a hard time taking this any
further. Bummer.
Cheers,
Peter
diff -rup origsrc/rng-tools-5/configure.ac src/rng-tools-5/configure.ac
--- origsrc/rng-tools-5/configure.ac 2014-08-12 10:33:32.064585400 +0200
+++ src/rng-tools-5/configure.ac 2014-08-12 11:18:44.431782000 +0200
@@ -56,6 +56,8 @@ dnl
dnl Checks for optional library functions
dnl -
+AC_SEARCH_LIBS([argp_parse],[argp])
+
dnl -
dnl Check for libgcrypt support
dnl -
diff -rup origsrc/rng-tools-5/rdrand_asm.S src/rng-tools-5/rdrand_asm.S
--- origsrc/rng-tools-5/rdrand_asm.S 2014-08-12 10:33:32.066585400 +0200
+++ src/rng-tools-5/rdrand_asm.S 2014-08-12 11:26:27.429381800 +0200
@@ -20,20 +20,41 @@
#if defined(__i386__) || defined(__x86_64__)
-#define ENTRY(x) \
- .balign 64 ; \
- .globl x ; \
-x:
+#if defined __CYGWIN__
+# if defined __x86_64__
+# define MS_x86_64_ABI
+# else
+# define SYMBOL(name) _ ## name
+# endif
+#else
+# define ELF_DEBUG_INFO
+#endif
+#if !defined SYMBOL
+# define SYMBOL(name) name
+#endif
+
+#define ENTRY(x) \
+ .balign 64 ; \
+ .globl SYMBOL(x) ; \
+SYMBOL(x):
+#if defined ELF_DEBUG_INFO
#define ENDPROC(x) \
.size x, .-x ; \
.type x, @function
+#else
+#define ENDPROC(x)
+#endif
#define RDRAND_RETRY_LIMIT 10
#ifdef __x86_64__
ENTRY(x86_rdrand_bytes)
+#if defined MS_x86_64_ABI
+ mov %rcx, %rdi
+ mov %rdx, %rsi
+#endif
mov %esi, %eax
1:
mov $RDRAND_RETRY_LIMIT, %ecx
@@ -55,6 +76,12 @@
ENDPROC(x86_rdrand_bytes)
ENTRY(x86_rdseed_or_rdrand_bytes)
+#if defined MS_x86_64_ABI
+ mov %rcx, %rdi
+ mov %rdx, %rsi
+ mov %r8, %rdx
+ mov %r9, %rcx
+#endif
mov (%rsi), %r8d /* RDSEED count */
mov (%rcx), %r9d /* RDRAND count */
1:
@@ -191,6 +218,10 @@
movl 12(%ebp), %edx
push %esi
#endif
+#if defined MS_x86_64_ABI
+ mov %rcx, %rdi
+ mov %rdx, %rsi
+#endif
movl $512, CTR3 /* Number of rounds */
movdqa (0*16)(PTR1), %xmm0
@@ -295,6 +326,9 @@
mov %esp, %ebp
movl 8(%ebp), %eax
#endif
+#if defined MS_x86_64_ABI
+ mov %rcx, %rdi
+#endif
SETPTR(aes_round_keys, PTR1)
movdqu (PTR0), %xmm0
@@ -347,12 +381,16 @@
.balign 64
aes_round_keys:
.space 11*16
+#if defined ELF_DEBUG_INFO
.size aes_round_keys, .-aes_round_keys
+#endif /* ELF_DEBUG_INFO */
#endif /* i386 or x86_64 */
+#if defined ELF_DEBUG_INFO
/*
* This is necessary to keep the whole executable
* from needing a writable stack.
*/
.section.note.GNU-stack,"",%progbits
+#endif /* ELF_DEBUG_INFO */
diff -rup origsrc/rng-tools-5/rngd_linux.c src/rng-tools-5/rngd_linux.c
--- origsrc/rng-tools-5/rngd_linux.c 2012-08-06 19:04:12.0 +0200
+++ src/rng-tools-5/rngd_linux.c 2014-08-09 15:09:21.081616358 +0200
@@ -39,8 +39,10 @@
#include
#include
#include
+#ifndef __CYGWIN__
#include
#include
+#endif
#include
#include "rngd.h"
@@ -130,11 +132,19 @@ void random_add_entropy(void *buf, size_
entropy.size = size;
memcpy(entropy.data, buf, size);
+#ifdef __CYGWIN__
+ if (write(random_fd, entropy.data, size) != size) {
+ message(LOG_DAEMON|LOG_ERR, "Add Entropy failed: %s\n",
+ strerror(errno));
+ exit(1);
+ }
+#else
if (ioctl(random_fd, RNDADDENTROPY, &entropy) != 0) {
message(LOG_DAEMON|LOG_ERR, "RNDADDENTROPY failed: %s\n",
strerror(errno));
exit(1);
}
+#endif
}
void random_sleep(void)
--
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 package: rng-tools-5-1
Hi Peter, On Aug 12 15:29, Peter Rosin wrote: > On 2014-08-09 16:37, Corinna Vinschen wrote: > > I just uploaded rng-tools-5-1. > > > > The Cygwin release only comes with the rngtest tool for now. > > > > The rngd daemon requires porting assembler code to COFF and the > > Microsoft calling convention. Any help porting this code would > > be greatly appreciated. > > Ok, I took a stab at it. The problems I identified in the assembly > are ELF debug info, different register use for the x86-64 calls and > a missing underscore prefix for the i686 symbols. > > I'm unsure if used registers (and which) have to be saved in the > MS x86-64 ABI, but that shouldn't be too hard to fix if that's the > case. > > I also moved up the AC_SEARCH_LIBS hunk in configure.ac since > the existing AC_CHECK_LIB is buried inside some other construct > (AC_CHECK_HEADER is possibly the culprit) which causes this: > > checking for library containing argp_parse... > /usr/src/rng-tools-5-1.src/rng-tools-5-1.i686/src/rng-tools-5/configure: line > 4335: ac_fn_c_try_link: command not found > /usr/src/rng-tools-5-1.src/rng-tools-5-1.i686/src/rng-tools-5/configure: line > 4335: ac_fn_c_try_link: command not found > no > > Anyway, with the attached patch instead of the one included in the > src package, it builds for both arches, but my cpu appears to lack > the rdrand instruction, so I have a hard time taking this any > further. Bummer. Thanks for your efforts! Over the weekend I tried my own port. I opted for creating a new file, rdrand_win_asm.S (attached for reference) to keep the code a bit cleaner. I have a machine which supports the rdrand call, but you need at least an Ivy Bridge CPU, For rdseed you need at least Haswell. Ultimately I gave up on rngd for now, for four reasons: - rngd uses poll(2) on /dev/random to wait until /dev/random becomes writable. /dev/random on Cygwin is always writable (we're not controlling the entropy pool, the OS does, and the RtlGenRandom call never blocks). This results in 100% CPU usage. - Even then, using rngd on /dev/random gave *worse* results when testing /dev/random with rngtest :-P I'm not sure why. - Cygwin does not support any of the other three hardware entropy sources /dev/hwrng or /dev/tpm0. For Intel/AMD hwrng you'd need access to the PCI bus and certain chipsets. For tpm0 you'd need a TPM chip and a description how to access the chip for producing random numbers. The chip is supposedly available as cryptographic provider under Windows, but on the only machine in our home with a TPM chip *and* a functional Windows driver, there was no matching cryptographic provider returned by the call to CryptEnumProviders. - Given that, and given the hardware constraints for the rdrand and rdseed calls, I decided that it's not worth to follow through with this stuff. Still, thanks a lot for working on that. I appreciate it. If you have any idea how Cygwin could provide /dev/hwrng or /dev/tpm0 to have at least two HW entropy sources, please feel free to discuss this on the cygwin-developer's list. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat /* * Copyright (c) 2011-2014, Intel Corporation * Authors: Fenghua Yu , * H. Peter Anvin * * This program is free software; you can redistribute it and/or modify it * under the terms and conditions of the GNU General Public License, * version 2, as published by the Free Software Foundation. * * This program is distributed in the hope it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for * more details. * * You should have received a copy of the GNU General Public License along with * this program; if not, write to the Free Software Foundation, Inc., * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. * */ /* * This is the Windows version of the file. It's equivalent to the original * code from Intel, just replacing ELF with COFF pseudo code expressions * where necessary and using Windows ABI rather than System V ABI on x86_64. * Additionally it utilizes the fact that recent versions of gas know the * rdrand, rdseed, and aes opcodes to avoid opaque .byte expression. */ #if defined(__i386__) || defined(__x86_64__) #ifdef __x86_64__ #define LBL(x) x #else #define LBL(x) _##x #endif #define ENTRY(x) \ .align 8 ; \ .globl LBL(x) ; \ .defLBL(x) ; \ .scl2 ; \ .type 32 ; \ .endef ; \ LBL(x): #define ENDPROC(x) #define RDRAND_RETRY_LIMIT 10 #ifdef __x86_64__ ENTRY(x86_rdrand_bytes) mov %edx, %eax 1: mov $RDRAND_RETRY_LIMIT, %r9d 2: rdrand %r10 jnc 3f mov %r10, (%rcx)
Re: [ANNOUNCEMENT] New package: rng-tools-5-1
On Aug 12 16:11, Corinna Vinschen wrote: > I have a machine which supports the rdrand call, but you need at least > an Ivy Bridge CPU, For rdseed you need at least Haswell. s/Haswell/Broadwell/ Sorry, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpgn1mA2aosK.pgp Description: PGP signature
RE: Missing Dependency
> Date: Tue, 12 Aug 2014 10:08:48 +0200 > From: corinna-cygwin > To: cygwin > Subject: Re: Missing Dependency > > On Aug 11 13:56, Karl M wrote: >> Hi All... >> >> >> I just did two 32 bit Cygwin + OpenSSH installs on brand new machines >> (Win 64), and received an error message that cyggmp3.dll could not be >> found. I installed libgmp3 and that resolved the issue. > > That's a bit low on information. What application did you get the error > message from? Neither ssh nor sshd depend on libgmp. > Well...I'm not quite sure. It comes from within csih when doing a test. After I unstalled libgmp3 and ran ssh-host-config I get the following: $ ssh-host-config /usr/bin/expr.exe: error while loading shared libraries: cyggmp-3.dll: cannot open shared object file: No such file or directory /usr/share/csih/cygwin-service-installation-helper.sh: line 694: [: -gt: unary operator expected /usr/share/csih/cygwin-service-installation-helper.sh: line 718: test: -gt: unary operator expected *** ERROR: ssh-host-config is using csih-0.9.7. *** ERROR: csih-0.9.7 requires WinNT or above. *** ERROR: The current operating system is: *** ERROR: Microsoft Windows 7 Professional, 64-bit Service Pack 1 (build 7601). But test does not depend in it. Thanks, ...Karl -- 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: Missing Dependency
> From: karlm > To: cygwin > Subject: RE: Missing Dependency > Date: Tue, 12 Aug 2014 09:18:48 -0700 > > >> Date: Tue, 12 Aug 2014 10:08:48 +0200 >> From: corinna-cygwin >> To: cygwin >> Subject: Re: Missing Dependency >> >> On Aug 11 13:56, Karl M wrote: >>> Hi All... >>> >>> >>> I just did two 32 bit Cygwin + OpenSSH installs on brand new machines >>> (Win 64), and received an error message that cyggmp3.dll could not be >>> found. I installed libgmp3 and that resolved the issue. >> >> That's a bit low on information. What application did you get the error >> message from? Neither ssh nor sshd depend on libgmp. >> > > Well...I'm not quite sure. It comes from within csih when doing a test. After > I unstalled libgmp3 and ran ssh-host-config I get the following: > > $ ssh-host-config > /usr/bin/expr.exe: error while loading shared libraries: cyggmp-3.dll: cannot > open shared object file: No such file or directory > /usr/share/csih/cygwin-service-installation-helper.sh: line 694: [: -gt: > unary operator expected > /usr/share/csih/cygwin-service-installation-helper.sh: line 718: test: -gt: > unary operator expected > *** ERROR: ssh-host-config is using csih-0.9.7. > *** ERROR: csih-0.9.7 requires WinNT or above. > *** ERROR: The current operating system is: > *** ERROR: Microsoft Windows 7 Professional, 64-bit Service Pack 1 (build > 7601). > > But test does not depend in it. > But expr does, and that seems rather low level to not have been seen so far. So I am puzzled. Thanks, ...Karl -- 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: Missing Dependency
On Aug 12 09:18, Karl M wrote: > > From: corinna-cygwin > > On Aug 11 13:56, Karl M wrote: > >> Hi All... > >> > >> > >> I just did two 32 bit Cygwin + OpenSSH installs on brand new machines > >> (Win 64), and received an error message that cyggmp3.dll could not be > >> found. I installed libgmp3 and that resolved the issue. > > > > That's a bit low on information. What application did you get the error > > message from? Neither ssh nor sshd depend on libgmp. > > Well...I'm not quite sure. It comes from within csih when doing a test. After > I unstalled libgmp3 and ran ssh-host-config I get the following: > > $ ssh-host-config > /usr/bin/expr.exe: error while loading shared libraries: cyggmp-3.dll: cannot > open shared object file: No such file or directory That explains it. It's a fallout from the new coreutils test package which changed the setup.hint dependencies to libgmp10. This will be fixed soon when Eric uploads the new coreutils 8.23 as "curr" package. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpbIkk73XgRl.pgp Description: PGP signature
Re: Same mirror data with both Cygwin setup.exe?
Thank you Warren and David for your commentaries about my question. Well, I use Seismic Unix and have installed before in cygwin 32-bit without problems. I tried it a couple of days in my Cygwin 64-bit and it crashed or gave strange data outputs. This seismic unix also uses x11 programs, they did not worked properly either. Why? I have no clue. That's why I'll try cygwin32 now. I'll download everything again, so I can test this from a fresh installation. Thank again for your answers, Cheers, Gery Sent from my iRon On Aug 11, 2014, at 23:54, David Stacey wrote: On 11/08/14 21:57, Gery . wrote: > Is it advisable to run both Cygwin 32- and 64-bit setup installers with the > same downloaded set of packages from a unique mirror? I have 6GB data > downloaded from a mirror, I downloaded that while running step 64-bit > installer. If you used setup-x86_64.exe to do the downloading then that will have downloaded 64-bit packages only. If this is the case then you will have some more downloading to do to get the 32-bit packages. However, you don't have to do a full install - if you select only those packages you need during the installation process then that will reduce the amount you need to download. But otherwise, you can install 32-bit and 64-bit Cygwin side-by-side, and from the same mirror. Cheers, Dave. -- 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: xmlstarlet-1.6.1-1
Version 1.6.1-1 of xmlstarlet has been updated. ANNOUNCEMENT http://sourceforge.net/p/xmlstar/news/2014/08/xmlstarlet-161-released/ CHANGE LOG == 1.6.1: August 9, 2014 - handle unicode arguments under Windows DESCRIPTION === XMLStarlet is a set of command line utilities (tools) which can be used to transform, query, validate, and edit XML documents and files using simple set of shell commands in similar way it is done for plain text files using UNIX grep, sed, awk, diff, patch, join, etc. commands. This set of command line utilities can be used by those who deal with many XML documents on UNIX shell command prompt as well as for automated XML processing with shell scripts. WEBSITE === http://xmlstar.sourceforge.net/ Cheers, Dave. 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: yasm-1.3.0-1
Version 1.3.0-1 of yasm has been updated. RELEASE NOTES = http://yasm.tortall.net/releases/Release1.3.0.html CHANGE LOG == Changes from 1.2.0 to 1.3.0: - Add AMD TBM instructions. - Add HSW TSX instructions. - Fix “pmulhrw”, “vphaddudq”, and “vpbroadcastq” instructions. - Add Intel SHA, ADX, RDSEED, and SMAP instructions. - Use a larger hash table size in NASM macro handling. - Add support for x32 ABI (called “elfx32”). - Add support for “function” decorator in win32/win64 object files. - In Mach-O, only warn on repeated flags if the new flags are different. DESCRIPTION === Yasm is a complete rewrite of the NASM assembler under the “new” BSD License (some portions are under other licenses, see COPYING for details). Yasm currently supports the x86 and AMD64 instruction sets, accepts NASM and GAS assembler syntaxes, outputs binary, ELF32, ELF64, 32 and 64-bit Mach-O, RDOFF2, COFF, Win32, and Win64 object formats, and generates source debugging information in STABS, DWARF 2, and CodeView 8 formats. WEBSITE === http://yasm.tortall.net/ Cheers, Dave. 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: Configure error while installing musrfit ('C compiler cannot create executables')
On 12/08/2014 07:41, Philipp wrote: When it comes to ./configure --prefix=$ROOTSYS however, I get following error message: configure:3985: error: C compiler cannot create executables See `config.log' for more details This is a complete shot in the dark, but are you perchance using Norton Anti-Virus? I came across a similar problem configuring xmlstarlet a couple of days ago. When it came to the configure line 'checking whether we are cross compiling...' Norton blocked 'conftest.exe' claiming it contained a trojan, and the configure exited in a similar fashion to what you described. I managed to dodge the problem with an autoreconf; if that doesn't work, try disabling your anti-virus just while './configure' is running. Dave. -- 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: lnn, a native symlink wrapper script (Was: fstab not automounting...)
[reviewing old threads that mentioned me, now that I've released
coreutils 8.23...]
On 10/18/2013 11:55 AM, Warren Young wrote:
> On 10/18/2013 01:47, Corinna Vinschen wrote:
>>$ CYGWIN=winsymlinks:native ln -s /path/to/your/fstab /etc/fstab
>
> I've wrapped that in a shell script called lnn ("link native"):
>
> #!/bin/sh
> CYGWIN=winsymlinks:native ln "$@"
>
> Perhaps Eric Blake will add this to coreutils so we can use the shortcut
> in replies to list questions.
No, I won't add this to the coreutils package proper (at least, not if
upstream coreutils isn't likely to have it), but it's easy enough for
you to put the script in your own /bin.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
