How to install the finger print module on cygwin
Hello I am using Timesys Cygwin distribution 1.5 build 050,dll version is --- 1.5.17 and Gcc version 3.4.4 Can anyone help me wheteher cygwin supports PAM and how to install finger print module on cygwin. regards sailaja -- View this message in context: http://www.nabble.com/How-to-install-the-finger-print-module-on-cygwin-tf4134362.html#a11758570 Sent from the Cygwin Users mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: How to install the finger print module on cygwin
sailaja wrote: Hello I am using Timesys Cygwin distribution 1.5 build 050,dll version is --- 1.5.17 and Gcc version 3.4.4 Can anyone help me wheteher cygwin supports PAM and how to install finger print module on cygwin. Sailaja, AFAICS, there is no PAM for Cygwin. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: How to install the finger print module on cygwin
thanks Carlo. Then what is the solution for installing bioapi to enable finger print reader regards sailaja Carlo Florendo-2 wrote: > > sailaja wrote: >> Hello >> >> I am using Timesys Cygwin distribution 1.5 build 050,dll version is --- >> 1.5.17 >> and Gcc version 3.4.4 >>Can anyone help me wheteher cygwin supports PAM and how to install >>finger print module on cygwin. > > Sailaja, > > AFAICS, there is no PAM for Cygwin. > > Thank you very much. > > Best Regards, > > Carlo > > -- > Carlo Florendo > Softare Engineer/Network Co-Administrator > Astra Philippines Inc. > UP-Ayala Technopark, Diliman 1101, Quezon City > Philippines > http://www.astra.ph > > -- > The Astra Group of Companies > 5-3-11 Sekido, Tama City > Tokyo 206-0011, Japan > http://www.astra.co.jp > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > > -- View this message in context: http://www.nabble.com/How-to-install-the-finger-print-module-on-cygwin-tf4134362.html#a11760215 Sent from the Cygwin Users mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: How to install the finger print module on cygwin
On Tue, Jul 24, 2007 at 03:36:12AM -0700, sailaja wrote: >Then what is the solution for installing bioapi to enable finger print >reader Cygwin doesn't have a solution. However, if you have installed a commercial distribution of Cygwin you should look to your supplier for help. We don't support TimeSys products here. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Trying to build (perl) Inline::CPP-0.25.
Hi,
I'm running Windows Vista Business 64 on an AMD64 box. See below my sig for
'perl -V'.
I've built Inline::CPP on previous Cygwin installations (on Windows 2000)
and on "native" Win32 builds of perl , but attempts to build this module
under Cygwin are now failing under 'make test' with the following errors:
-
gcc -shared -o
_01basic_t_5cd2.dll -Wl,--out-implib=lib_01basic_t_5cd2.dll.a -Wl,--export-all-symbols
-Wl,--enable-auto-import -Wl,--stack,8388608 -Wl,--enable-auto-image-base \
-s -L/usr/local/lib _01basic_t_5cd2.o
/usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a
_01basic_t_5cd2.o:_01basic_t_5cd2.c:(.text+0x2a5): undefined reference to
`operator new(unsigned int)'
_01basic_t_5cd2.o:_01basic_t_5cd2.c:(.text+0x1345): undefined reference to
`operator delete(void*)'
_01basic_t_5cd2.o:_01basic_t_5cd2.c:(.text+0x19cc): undefined reference to
`std::ios_base::Init::Init()'
_01basic_t_5cd2.o:_01basic_t_5cd2.c:(.text+0x19e8): undefined reference to
`std::ios_base::Init::~Init()'
Creating library file: lib_01basic_t_5cd2.dll.a
collect2: ld returned 1 exit status
perlld: *** system() failed to execute
-
My immediate thought is that the problem arises because, as is evident from
the above copy'n'paste, 'gcc' is being invoked instead of 'g++'.
Is there some %Config::Config{} key that contains an inappropriate value, or
does the bug lie within the Inline::CPP-0.25 source ?
Cheers,
Rob
[EMAIL PROTECTED] ~/comp/Inline-CPP-0.25
$ perl -V:cc
cc='gcc';
[EMAIL PROTECTED] ~/comp/Inline-CPP-0.25
$ perl -V
Summary of my perl5 (revision 5 version 8 subversion 7) configuration:
Platform:
osname=cygwin, osvers=1.5.18(0.13242),
archname=cygwin-thread-multi-64int
uname='cygwin_nt-5.1 inspiron 1.5.18(0.13242) 2005-07-02 20:30 i686
unknown
unknown cygwin '
config_args='-de -Dmksymlinks -Duse64bitint -Dusethreads -Uusemymalloc -Dopt
imize=-O3 -Dman3ext=3pm -Dusesitecustomize'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=de
fine
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags
='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr
/local/include',
optimize='-O3',
cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -I/usr/local/inc
lude'
ccversion='', gccversion='3.4.4 (cygming special) (gdc 0.12, using dmd
0.125
)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lsee
ksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='ld2', ldflags =' -s -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -ldb -lcrypt -lgdbm_compat
perllibs=-lcrypt -lgdbm_compat
libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s'
cccdlflags=' ', lddlflags=' -s -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_64_BIT_INT
USE_LARGE_FILES USE_SITECUSTOMIZE
PERL_IMPLICIT_CONTEXT
Locally applied patches:
SPRINTF0 - fixes for sprintf formatting issues - CVE-2005-3962
Built under cygwin
Compiled at Dec 30 2005 02:44:25
%ENV:
CYGWIN=""
@INC:
/usr/lib/perl5/5.8/cygwin
/usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/cygwin
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/site_perl/5.8/cygwin
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8
/usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8
.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Trying to build (perl) Inline::CPP-0.25.
On 24 July 2007 13:42, Sisyphus wrote:
> I've built Inline::CPP on previous Cygwin installations (on Windows 2000)
> and on "native" Win32 builds of perl , but attempts to build this module
> under Cygwin are now failing under 'make test' with the following errors:
>
> -
> gcc -shared -o
> _01basic_t_5cd2.dll -Wl,--out-implib=lib_01basic_t_5cd2.dll.a
> -Wl,--export-all-symbols
> -Wl,--enable-auto-import -Wl,--stack,8388608 -Wl,--enable-auto-image-base \
> -s -L/usr/local/lib _01basic_t_5cd2.o
> /usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a
> _01basic_t_5cd2.o:_01basic_t_5cd2.c:(.text+0x2a5): undefined reference to
> `operator new(unsigned int)'
> _01basic_t_5cd2.o:_01basic_t_5cd2.c:(.text+0x1345): undefined reference to
> `operator delete(void*)'
> _01basic_t_5cd2.o:_01basic_t_5cd2.c:(.text+0x19cc): undefined reference to
> `std::ios_base::Init::Init()'
> _01basic_t_5cd2.o:_01basic_t_5cd2.c:(.text+0x19e8): undefined reference to
> `std::ios_base::Init::~Init()'
> Creating library file: lib_01basic_t_5cd2.dll.a
> collect2: ld returned 1 exit status
> perlld: *** system() failed to execute
> -
>
> My immediate thought is that the problem arises because, as is evident from
> the above copy'n'paste, 'gcc' is being invoked instead of 'g++'.
Almost certainly, using the wrong driver means the c++ libraries won't be
included on the linker command line.
> Is there some %Config::Config{} key that contains an inappropriate value, or
> does the bug lie within the Inline::CPP-0.25 source ?
That I can't say. But assuming the build uses proper dependencies in the
makefile, you should be able to workaround it by cutting and pasting that line
into your shell, replacing 'gcc' by 'g++' as you go, and once you've got past
that manually the rest of the build should run to completion.
cheers,
DaveK
--
Can't think of a witty .sigline today
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Trying to build (perl) Inline::CPP-0.25.
Dave Korn wrote: > That I can't say. But assuming the build uses proper dependencies in the > makefile, you should be able to workaround it by cutting and pasting that line > into your shell, replacing 'gcc' by 'g++' as you go, and once you've got past > that manually the rest of the build should run to completion. Normally that might work but in this case it misses the point, as the whole purpose of this perl module is to dynamically invoke the C++ compiler at runtime to compile the inline C++ bits in the script. And if it's invoking the compiler wrong it makes this essentially useless as all the stuff it feeds the compiler is dynamically generated. But I agree that this is a bug somewhere in the module, and is not related to Cygwin or gcc. Looking at its sources it seems to have the proper logic to use g++ for linking and/or adding -lstdc++ so I would suggest you need to contact the module's author. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Trying to build (perl) Inline::CPP-0.25.
On 24 July 2007 14:49, Brian Dessent wrote: > Dave Korn wrote: > >> That I can't say. But assuming the build uses proper dependencies in the >> makefile, you should be able to workaround it by cutting and pasting that >> line into your shell, replacing 'gcc' by 'g++' as you go, and once you've >> got past that manually the rest of the build should run to completion. > > Normally that might work but in this case it misses the point, as the > whole purpose of this perl module is to dynamically invoke the C++ > compiler at runtime to compile the inline C++ bits in the script. And > if it's invoking the compiler wrong it makes this essentially useless as > all the stuff it feeds the compiler is dynamically generated. Oh, yes, I missed that this was happening during "make check" and thought it was just part of the module build. A 'workaround' for a testsuite failure is indeed pretty damn useless! cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Trying to build (perl) Inline::CPP-0.25.
I ran into a similar problem recently - the standard sort of c++
references were not being found. It turns out that the linker I was
calling was ld2, a script that called another script perlld (in
/usr/bin), where I found this:
# these are pretty mandatory
my $CC = 'gcc';
my $EXPORT_ALL = 1;
I edited this script and replaced gcc with g++. I don't know if this was
a good idea or not, but it seemed to fix the problem.
Sisyphus wrote:
Hi,
I'm running Windows Vista Business 64 on an AMD64 box. See below my sig
for 'perl -V'.
I've built Inline::CPP on previous Cygwin installations (on Windows
2000) and on "native" Win32 builds of perl , but attempts to build this
module under Cygwin are now failing under 'make test' with the following
errors:
-
gcc -shared -o _01basic_t_5cd2.dll
-Wl,--out-implib=lib_01basic_t_5cd2.dll.a -Wl,--export-all-symbols
-Wl,--enable-auto-import -Wl,--stack,8388608 -Wl,--enable-auto-image-base \
-s -L/usr/local/lib _01basic_t_5cd2.o
/usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a
_01basic_t_5cd2.o:_01basic_t_5cd2.c:(.text+0x2a5): undefined reference
to `operator new(unsigned int)'
_01basic_t_5cd2.o:_01basic_t_5cd2.c:(.text+0x1345): undefined reference
to `operator delete(void*)'
_01basic_t_5cd2.o:_01basic_t_5cd2.c:(.text+0x19cc): undefined reference
to `std::ios_base::Init::Init()'
_01basic_t_5cd2.o:_01basic_t_5cd2.c:(.text+0x19e8): undefined reference
to `std::ios_base::Init::~Init()'
Creating library file: lib_01basic_t_5cd2.dll.a
collect2: ld returned 1 exit status
perlld: *** system() failed to execute
-
My immediate thought is that the problem arises because, as is evident
from the above copy'n'paste, 'gcc' is being invoked instead of 'g++'.
Is there some %Config::Config{} key that contains an inappropriate
value, or does the bug lie within the Inline::CPP-0.25 source ?
Cheers,
Rob
[EMAIL PROTECTED] ~/comp/Inline-CPP-0.25
$ perl -V:cc
cc='gcc';
[EMAIL PROTECTED] ~/comp/Inline-CPP-0.25
$ perl -V
Summary of my perl5 (revision 5 version 8 subversion 7) configuration:
Platform:
osname=cygwin, osvers=1.5.18(0.13242),
archname=cygwin-thread-multi-64int
uname='cygwin_nt-5.1 inspiron 1.5.18(0.13242) 2005-07-02 20:30 i686
unknown
unknown cygwin '
config_args='-de -Dmksymlinks -Duse64bitint -Dusethreads
-Uusemymalloc -Dopt
imize=-O3 -Dman3ext=3pm -Dusesitecustomize'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=de
fine
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe
-I/usr
/local/include',
optimize='-O3',
cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe
-I/usr/local/inc
lude'
ccversion='', gccversion='3.4.4 (cygming special) (gdc 0.12, using
dmd 0.125
)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8,
Off_t='off_t', lsee
ksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='ld2', ldflags =' -s -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -ldb -lcrypt -lgdbm_compat
perllibs=-lcrypt -lgdbm_compat
libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s'
cccdlflags=' ', lddlflags=' -s -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_64_BIT_INT
USE_LARGE_FILES USE_SITECUSTOMIZE
PERL_IMPLICIT_CONTEXT
Locally applied patches:
SPRINTF0 - fixes for sprintf formatting issues - CVE-2005-3962
Built under cygwin
Compiled at Dec 30 2005 02:44:25
%ENV:
CYGWIN=""
@INC:
/usr/lib/perl5/5.8/cygwin
/usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/cygwin
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/site_perl/5.8/cygwin
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8
/usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8
.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Trying to build (perl) Inline::CPP-0.25.
- Original Message - From: "Brian Dessent" <[EMAIL PROTECTED]> To: Sent: Tuesday, July 24, 2007 11:48 PM Subject: Re: Trying to build (perl) Inline::CPP-0.25. Dave Korn wrote: That I can't say. But assuming the build uses proper dependencies in the makefile, you should be able to workaround it by cutting and pasting that line into your shell, replacing 'gcc' by 'g++' as you go, and once you've got past that manually the rest of the build should run to completion. Normally that might work but in this case it misses the point, as the whole purpose of this perl module is to dynamically invoke the C++ compiler at runtime to compile the inline C++ bits in the script. And if it's invoking the compiler wrong it makes this essentially useless as all the stuff it feeds the compiler is dynamically generated. Yes - the makefile in question is generated on the fly. I could modify it as Dave suggested, but the next time the test script is run, the modified makefile is going to be overwritten by the same original (incorrect) makefile. But I agree that this is a bug somewhere in the module, and is not related to Cygwin or gcc. Looking at its sources it seems to have the proper logic to use g++ for linking and/or adding -lstdc++ so I would suggest you need to contact the module's author. Not much point. In his own words he's got "too much on his plate" to be bothered with Inline::CPP. (I don't think it has been updated since about 2001.) In fairness, he did offer me the opportunity to take over maintenance of the module. I've left my options open on that one ie, I haven't replied :-) Anyway, since it's not a Cygwin issue, then it's probably not all that difficult to track down the problem if I set my mind to it. Thanks Dave, Brian. Cheers, Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Trying to build (perl) Inline::CPP-0.25.
- Original Message - From: "Paul Mallas" <[EMAIL PROTECTED]> To: Sent: Wednesday, July 25, 2007 12:05 AM Subject: Re: Trying to build (perl) Inline::CPP-0.25. I ran into a similar problem recently - the standard sort of c++ references were not being found. It turns out that the linker I was calling was ld2, a script that called another script perlld (in /usr/bin), where I found this: # these are pretty mandatory my $CC = 'gcc'; my $EXPORT_ALL = 1; I edited this script and replaced gcc with g++. I don't know if this was a good idea or not, but it seemed to fix the problem. I personally think this was an *excellent* idea. It certainly works for me, too. I had run: - [EMAIL PROTECTED] ~/comp/Inline-CPP-0.25 $ perl -V:ld ld='ld2'; - and wondered about that. You're suggested amendment (apart from fixing the problem) is also in keeping with my "native" (MinGW) build of Windows perl 5.8 which reports: -- C:\>perl -V:ld ld='g++'; -- Dammit ... I should've known ... I've struck similar problems with MinGW builds of perl that want to set 'ld' to 'gcc' instead of 'g++'. So ... it *is* a Cygwin Perl bug after all ? (That's a question, not an assertion :-) Thanks Paul. Cheers, Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
1.5.24: incorrect default behavior of dd in popen context on text-mounted filesystem
Firstly, a thank you to Eric Blake for his quick response to the dd
problem we uncovered yesterday. As of coreutils 6.9-4, dd honors the
oflag=binary option in the popen() context in which I've been having
trouble. This test case now works as expected:
$ cat popenbug.c
#include
int main() {
FILE * const out = popen("gzip | dd oflag=binary > popenbug.out.gz", "w");
int i;
for( i = 0; i < 25; ++i )
fprintf(out, "line %d: * ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO \n", i);
fclose(out);
return 0;
}
$
$ gcc popenbug.c -o popenbug.exe && rm -f popenbug.out.gz && ./popenbug.exe &&
sleep 1 && gzip -d -t popenbug.out.gz
0+1 records in
0+1 records out
172 bytes (172 B) copied, 0 s, Infinity B/s
$
However, in the discussion and the updated coreutils announcement
http://cygwin.com/ml/cygwin/2007-07/msg00610.html
http://cygwin.com/ml/cygwin/2007-07/msg00617.html
the behavior of dd is specified as defaulting to binary in the absence
of an [io]flag=text option. This spec is in agreement with the Cygwin
documenation. Bug, as of coreutils 6.9-4, this default behavior is
not honored in the popen() context:
$ cat popenbug.c
#include
int main() {
FILE * const out = popen("gzip | dd > popenbug.out.gz", "w");
int i;
for( i = 0; i < 25; ++i )
fprintf(out, "line %d: * ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO \n", i);
fclose(out);
return 0;
}
$
$ set|fgrep -i cygwin
BASH_VERSINFO=([0]="3" [1]="2" [2]="17" [3]="15" [4]="release"
[5]="i686-pc-cygwin")
CYGWIN=binmode
MACHTYPE=i686-pc-cygwin
OSTYPE=cygwin
$
$ gcc popenbug.c -o popenbug.exe && rm -f popenbug.out.gz && ./popenbug.exe &&
sleep 1 && gzip -d -t popenbug.out.gz
0+1 records in
0+1 records out
172 bytes (172 B) copied, 0.015 s, 11.5 kB/s
gzip: popenbug.out.gz: invalid compressed data--crc error
gzip: popenbug.out.gz: invalid compressed data--length error
$
Notice that dd processes the same number of bytes in both cases, so
the problem is somewhere in the stdout handling when the oflag=binary
argument isn't provided
Regards,
-Hugh
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: 1.5.24: incorrect default behavior of dd in popen context on text-mounted filesystem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Hugh Secker-Walker on 7/24/2007 9:48 AM:
> Firstly, a thank you to Eric Blake for his quick response to the dd
> problem we uncovered yesterday. As of coreutils 6.9-4, dd honors the
> oflag=binary option in the popen() context in which I've been having
> trouble.
Before you thank me too much, remember that oflag=binary already worked
even in coreutils 6.9-3; it was the absence of any oflag= that was
incorrectly obeying mount points instead of defaulting to binary.
> FILE * const out = popen("gzip | dd oflag=binary > popenbug.out.gz", "w");
Why not also thank cgf, who uploaded a fixed gzip yesterday? Because of
his fix, this should now work:
popen("gzip > popenbug.out.gz", "w")
> However, in the discussion and the updated coreutils announcement
> http://cygwin.com/ml/cygwin/2007-07/msg00610.html
> http://cygwin.com/ml/cygwin/2007-07/msg00617.html
Did you not read my statement that:
[io]f= unspecified - no change to existing mode of std{in,out}
I did not change that behavior, nor did I claim to change it in 6.9-4. I
am still open to the idea of changing it. For 6.9-4, I only changed the
behavior for when of= but not oflag= was specified.
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGpk8O84KuGfSFAYARAhmXAJ0cT5tSsSBRN75k3O+tBeKhcW6YCwCg2a5Y
ohzcbe+hm6dMlh/v5m5Gld4=
=C5o9
-END PGP SIGNATURE-
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Trying to build (perl) Inline::CPP-0.25.
Sisyphus schrieb:
-
[EMAIL PROTECTED] ~/comp/Inline-CPP-0.25
$ perl -V:ld
ld='ld2';
-
and wondered about that. You're suggested amendment (apart from fixing
the problem) is also in keeping with my "native" (MinGW) build of
Windows perl 5.8 which reports:
--
C:\>perl -V:ld
ld='g++';
Interesting. We should definitely ask p5p if we shouldn't switch back to
normal behaviour without the ld2 wrapper, but first I must study history
on this issue, why we introduced that at all.
Switching to g++ probably has other issues. Most XS modules are pretty
fine with gcc, but I wouldn't be sure if all of them are C++ safe.
MS cl is probably not that strict as gnu.
Even xsubpp creates lousy c++ code.
For the start having a wrapper should help use in fixing this inside
ld2 or perlld.
We should detect if the intermediate .o was compiled as c++ or plain gcc.
nm -C $obj|grep "operator new(" for example. Is there a better way?
--
Reini Urban
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [test-version] emacs-22.1-3/emacs-el-22.1-3/emacs-X11-22.1-3
Ken Brown wrote: > Emacs-22.1-3 aborts with a core dump when I try to compile a large latex > document I observe a similar behaviour with a document of about 43 page. The same thing happens using 'M-x compile' with a my application that gives about 2000 line of link errors: emacs simply dies! The problem doesn't occur with my cited build of emacs 22.1. Cheers, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Trying to build (perl) Inline::CPP-0.25.
On 24 July 2007 21:00, Reini Urban wrote:
> Switching to g++ probably has other issues. Most XS modules are pretty
> fine with gcc, but I wouldn't be sure if all of them are C++ safe.
This isn't an issue, or rather, it's not as bad as you think. Whether you
use g++ or gcc as the driver, it still looks at the file extension to decide
what language subcompiler to invoke; the only real difference between the two
is in the -I, -D and -L options they assume by default. There could be
namespace clashes with C++ headers that don't exist in C, and there could
perhaps be issues in linking against libstdc++ and libsupc++ (name mangling
would protect against most accidental collisions here, but I don't know if
there might be extern "C" functions in either of them), but you would't need
to worry about the language incompatibilities.
> For the start having a wrapper should help use in fixing this inside
> ld2 or perlld.
> We should detect if the intermediate .o was compiled as c++ or plain gcc.
> nm -C $obj|grep "operator new(" for example. Is there a better way?
I'm not sure this is necessary (particularly in light of the above).
Whatever you do should work if the final executable combines C *and* C++
modules, without causing complications for the C, so it should work for a
final executable that only has plain C modules as a special case. I think you
should be just able to use g++ for the link step regardless, and need only
trouble yourself with picking the right driver for the compilation step.
cheers,
DaveK
--
Can't think of a witty .sigline today
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Emacs takes 100% CPU
Hi,
thanks for your answers. Attached is the result of cygcheck -srv. I had
some package that were not ok. I reinstalled them, and now all are ok,
and the crashes still happen when I start emacs and emacs -debug-init
and emacs -no-init-file (I can't start emacs -vanilla). I also get
immediate crashes on startup with segmentation fault and "fatal error -
called with threadlist_ix -1".
What else can I provide ?
Best regards,
Nicolas
--
Nicolas Saunier
Postdoctoral Research Associate
Department of Civil Engineering
University of British Columbia
http://www.confins.net/saunier/
Cygwin Configuration Diagnostics
Current System Time: Mon Jul 23 15:38:40 2007
Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 2
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
C:\cygwin\home\saunier~\bin\
c:\Program Files\OpenCV\bin
c:\Program Files\Java\jdk1.5.0_03\bin
.
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\Program Files\Microsoft DirectX SDK (February 2007)\Utilities\Bin\x86
c:\texmf\miktex\bin
c:\PROGRA~1\GTK\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\system32\wbem
%halconroot%\bin\i586-nt4
%halconroot%\flexlm\i586-nt4
c:\Program Files\MATLAB\R2006a\bin\win32
c:\program files\matlab704\bin\win32
c:\progra~1\att\graphviz\bin
c:\Python24
c:\Python24\Scripts
c:\Python24\DLLs
c:\Python24\Enthought\MingW\bin
c:\Python24\Enthought\Graphviz\bin
c:\Python24\Enthought\SWIG-1.3.24
c:\Python24\Lib\site-packages\vtk_python
c:\Python24\Lib\site-packages\wx-2.6-msw-unicode-enthought\wx
c:\Program Files\MySQL\MySQL Server 5.0\bin
c:\Program Files\QuickTime\QTSystem\
c:\Program Files\OpenCV\bin
C:\cygwin\lib\lapack
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1008(saunier) GID: 513(None)
0(root) 513(None) 544(Administrators) 545(Users)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1008(saunier) GID: 513(None)
0(root) 513(None) 544(Administrators) 545(Users)
SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS
HOME = '/home/saunier'
PWD = '/home/saunier/Desktop'
USER = 'saunier'
MAKE_MODE = 'unix'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
APPDATA = 'C:\Documents and Settings\saunier\Application Data'
CLASSPATH = '.;C:\Program Files\Java\jre1.6.0_01\lib\ext\QTJava.zip'
CLIENTNAME = 'Console'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
COMPUTERNAME = 'SAUNIER-UBC'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
CYGWIN_ROOT = '\cygwin'
DISPLAY = '127.0.0.1:0.0'
DXSDK_DIR = 'C:\Program Files\Microsoft DirectX SDK (February 2007)\'
FP_NO_HOST_CHECK = 'NO'
GTK_BASEPATH = 'C:\PROGRA~1\GTK'
HOMEDRIVE = 'C:'
HOMEPATH = '\Documents and Settings\saunier'
JAVA_HOME = 'C:\Program Files\Java\jre1.5.0_06'
LOGONSERVER = '\\SAUNIER-UBC'
NUMBER_OF_PROCESSORS = '2'
OS = 'Windows_NT'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = 'x86'
PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 4 Stepping 1, GenuineIntel'
PROCESSOR_LEVEL = '15'
PROCESSOR_REVISION = '0401'
PROGRAMFILES = 'C:\Program Files'
PROMPT = '$P$G'
QTJAVA = 'C:\Program Files\Java\jre1.6.0_01\lib\ext\QTJava.zip'
SESSIONNAME = 'Console'
SYSTEMDRIVE = 'C:'
SYSTEMROOT = 'C:\WINDOWS'
TEMP = '/cygdrive/c/DOCUME~1/saunier/LOCALS~1/Temp'
TERM = 'xterm'
TMP = '/cygdrive/c/DOCUME~1/saunier/LOCALS~1/Temp'
USERDOMAIN = 'SAUNIER-UBC'
USERPROFILE = 'C:\Documents and Settings\saunier'
VS80COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\'
WINDIR = 'C:\WINDOWS'
XAPPLRESDIR = '/usr/X11R6/lib/X11/app-defaults'
XCMSDB = '/usr/X11R6/lib/X11/Xcms.txt'
XKEYSYMDB = '/usr/X11R6/lib/X11/XKeysymDB'
XNLSPATH = '/usr/X11R6/lib/X11/locale'
WINDOWID = '4194318'
XTERM_VERSION = 'Cygwin 6.8.2.0(202)'
LOGNAME = 'saunier'
TERMCAP = 'xterm-r6|xterm|xterm X11R6
version:am:km:mi:ms:xn:co#80:it#8:li#24:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kd=\EOB:ke=\E[?1l\E>:kh=\E[1~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:rc=\E8:sc=\E7:se=\E[m:sf=^J:so=\E[7m:sr=\EM:ta=^I:te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:ue=\E[m:up=\E[A:us=\E[4m:kb=\010:'
XTERM_SHELL = '/bin/zsh'
TZ = 'PST8PDT7,M3.2.0/2,M11.1.0/2'
SHLVL = '1'
OLDPWD = '/home/saunier'
PS1 = '%{]0;%/
[32m%}([EMAIL PROTECTED])[%h] %{[33m%}%~%{[0m%}
$ '
BOOST_BUILD_PATH = '/home/saunier/bin/boost-build'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
INFOPATH = '/usr/local/info:/usr/share
Re: Emacs takes 100% CPU
Nicolas Saunier wrote: > thanks for your answers. Attached is the result of cygcheck -srv. I had > some package that were not ok. I reinstalled them, and now all are ok, > and the crashes still happen when I start emacs and emacs -debug-init > and emacs -no-init-file (I can't start emacs -vanilla). I also get > immediate crashes on startup with segmentation fault and "fatal error - > called with threadlist_ix -1". > What else can I provide ? The output of `cygcheck /usr/bin/emacs-nox.exe` (to look the libraries used), but do it with the real executable you are using, if there is an emacs it probably is a symlink. > DISPLAY = '127.0.0.1:0.0' Are you running emacs with output to X11? if X is not running then emacs just takes a long time to say it didn't find an X server. > emacs21.2-13 > emacs-X1121.2-13 Have you considered upgrading to the latest (22.1-3)? -- René Berber -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
screen - doesn't call .bashrc at startup
Under RedHat/Fedora, when screen starts up, it will execute (source) my .bashrc file. Under cygwin, it doesn't. Bug? Feature request? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: screen - doesn't call .bashrc at startup
yitzle wrote: Under RedHat/Fedora, when screen starts up, it will execute (source) my .bashrc file. Under cygwin, it doesn't. Bug? Feature request? Disabled feature? I don't know much about screen (never used it myself) but looking at the man page I find: shell command Set the command to be used to create a new shell. This overrides the value of the environment variable $SHELL. This is useful if you’d like to run a tty-enhancer which is expecting to execute the program speci- fied in $SHELL. If the command begins with a ’-’ character, the shell will be started as a login-shell. Then on my Fedora Core system '/etc/screenrc' contains: # make the shell in every window a login shell #shell -$SHELL So maybe look in '/etc/screenrc' and see if there's a similar setting there that you can enable? Otherwise, just add it to your '~/.screenrc'. -- 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? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: screen - doesn't call .bashrc at startup
Then on my Fedora Core system '/etc/screenrc' contains: # make the shell in every window a login shell #shell -$SHELL So maybe look in '/etc/screenrc' and see if there's a similar setting there that you can enable? Otherwise, just add it to your '~/.screenrc'. That line does the trick. Thanks! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: pcre-7.2-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The following package has been updated in the Cygwin net release: *** pcre-7.2-1 *** pcre-devel-7.2-1 *** pcre-doc-7.2-1 *** libpcre0-7.2-1 This is an upstream version bump, no Cygwin-specific changes. Yaakov ~ *** 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: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpufmpiWmPGlmQSMRCJKmAJ9ZSYWQY8n9Fkq/luNNPCBvurYDpwCfWD7D 6iSxVLTxhBMEa075naKnB28= =bm1a -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: libxml2-2.6.28-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The following package has been updated in the Cygwin net release: *** libxml2-2.6.28-2 *** libxml2-devel-2.6.28-2 *** libxml2-doc-2.6.28-2 *** python-libxml2-2.6.28-2 This is an upstream version bump. The Python bindings are for Python-2.5 and were renamed (upgrade should happen automatically). Yaakov ~ *** 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: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpuhdpiWmPGlmQSMRCArLAJ9vVG+LVkFnPO7B5X0ud4f2ijPH1ACgvUEq z9c9MFGQXpsULeuHjCqed/8= =4Y1n -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: libxslt-1.1.20-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The following package has been updated in the Cygwin net release: *** libxslt-1.1.20-2 *** libxslt-devel-1.1.20-2 *** libxslt-doc-1.1.20-2 *** python-libxslt-1.1.20-2 This is an upstream version bump. The Python bindings are for Python-2.5 and were renamed (upgrade should happen automatically). Yaakov ~ *** 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: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpui4piWmPGlmQSMRCPouAKDl29dD2YxS7kQYMiIdqM7nekEfiQCgqpG2 fJ7nP8HtlePJdwifRBGJlzg= =XE9t -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] SECURITY: Updated: libexif-0.6.16-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The following package has been updated in the Cygwin net release: *** libexif-0.6.16-1 *** libexif12-0.6.16-1 *** libexif-devel-0.6.16-1 This is an upstream version bump which fixes a possible buffer overflow (CVE-2006-4168). The DLL and development libs and headers were broken out into separate packages; upgrading will automatically pull in the DLL but not -devel. Yaakov ~ *** 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: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpum4piWmPGlmQSMRCD+wAKDzLzSmBYbZgK9ZpEdn+OfKs+iwFQCeJFUs HLsdADAF4pdDSPDLhWlOSD8= =9qJQ -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
