Re: Fw: Cygwin updates cause rebaseall errors
- Original Message - From: "Andrey Repin" I'm a bit dubious about providing a hard link to http://cygwin.com/faq/faq-nochunks.html#faq.using.fixing-fork-failures as it seems like the sort of link that might change. Would "Go to http://cygwin.com/faq/ and see the section 'How do I fix fork() failures?'" be a better option ? You can safely give out the first link. Even if anchor name would be changed, the address of "nochunk" version of the document is unlikely to be changed any time soon. But then I'm not so sure about the advice offered in that FAQ entry. It says "Read the 'rebase' package README in /usr/share/doc/rebase/, and follow the instructions there to run 'rebaseall'". But, although I have a /usr/share/doc folder, I don't have a /usr/share/doc/rebase/ folder. You have to (re)install rebase package... http://cygwin.com/cgi-bin2/package-cat.cgi?file=rebase%2Frebase-4.0.1-1&grep=rebase Thanks Andrey !! I'll attend to all that when I get a chance. Cheers, Rob -- 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: Fw: Cygwin updates cause rebaseall errors
- Original Message - From: "Christopher Faylor" < I'd highly suggest not including pointers to random web sites as a method to fix this issue but, instead, point to the Cygwin FAQ and the Cygwin mailing list. Seems a sane suggestion to me. I'm a bit dubious about providing a hard link to http://cygwin.com/faq/faq-nochunks.html#faq.using.fixing-fork-failures as it seems like the sort of link that might change. Would "Go to http://cygwin.com/faq/ and see the section 'How do I fix fork() failures?'" be a better option ? But then I'm not so sure about the advice offered in that FAQ entry. It says "Read the 'rebase' package README in /usr/share/doc/rebase/, and follow the instructions there to run 'rebaseall'". But, although I have a /usr/share/doc folder, I don't have a /usr/share/doc/rebase/ folder. I can see /usr/bin/rebase.exe and /usr/bin/rebaseall, and I can reproduce the problem that Chloe reported with Inline::C and Cygwin. But I haven't yet fixed it, as I've been unable to work out how to successfully run 'rebaseall'. I'll check this out properly when I get a chance. In the meantime, the question about the "best way" to refer to the relevant Cygwin FAQ entry still stands. Cheers, Rob -- 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: x86_64-w64-ming32-g++ file not recognized by objdump
- Original Message -
From: "Thomas D. Dean"
#include
#include
using namespace std;
int main() {
vector vs;
vs.push_back("asdf");
}
If I compile with g++, I get an executable that works, i.e. runs without
error. This file is recognized by objdump and cygcheck.
If I compile with x86_64-w64-ming32-g++ -m64 t.cc -o t
I presume the 'ming32' is a typo.
Is the '-m64' necessary ?
What happens if you remove it from the command ?
I can't reproduce the error you get (either with or without '-m64'), though
I'm just running mingw in the cmd.exe shell - not under Cygwin.
the resulting executable produces an error message
./t.exe
t.exe: error while loading shared libraries: ?: cannot open shared
object file: no such file or directory.
objdump -p ./t.exe
objdump: ./t.exe: File format not recognized
I think that's to be expected - objdump expects to look at a 32-bit
executable.
I get the same error when I run objdump on a 64-bit executable.
Try:
x86_64-w64-mingw32-objdump -p ./t.exe
Cheers,
Rob
--
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: newlib and long-double question
- Original Message - From: "Hugh Myers" Sisyphus, this is off topic slightly, but you might want to adjust the link on the CPAN page: http://www.loria.fr/projets/mpfr/mpfr-current/mpfr.html Yes - thanks. (And it *is* OT :-) That's an old link that I'd overlooked. I can probably just delete it entirely. The http://www.mpfr.org link in the preceding (DEPENDENCIES) section is the appropriate starting place for everything one needs wrt the mpfr library. Cheers, Rob -- 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: newlib and long-double question
- Original Message - From: "Hugh Myers" The OP is trying to build Perl itself, not use it; hence the need for long double support functions... You don't need "long double support functions" to build perl ... unless you want to build a perl whose NV is a long double (instead of a double). Presumably the op wants to build a perl whose NV is a long double so that he can make use of that extra precision. Given that he can't build such a perl, the next best way of accessing that extra precision he wants is, imo, to use Math::MPFR. Cheers, Rob -- 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: newlib and long-double question
- Original Message - From: "marco atzeri" On a Linux system that I have access to, I see that those functions are in /lib/libm.* but cygwin's /lib/libm.* still seems to lack them. Is there any work around or alternate version ofthis lib that actually has these functions. I honestly do not mean to be rude, but how difficult is it to impliment these functions which seem so common in most unix-like systems? It is not overcomplicated to implement it, but it takes time and someone to do it. When I implemented all the complex functions (cabs, ccos..) I spent one month to make it right. A more capable guy will take less surely, but as mention I see little benefit moving from 64 to 80 bits so I was not interested to implement it. I sense an opportunity here to plug (to the op) the Math::MPFR perl module - for which the gmp and mpfr C libraries are required. I guess one could also use Math::BigFloat, but I assume the op has already considered (and rejected) that option - the performance hit incurred by its use has always discouraged me. Perhaps he has also already considered and rejected Math::MPFR, but it seems to me to be by far the best option for achieving added precision with floating point numbers - at least until such time as building perl with -Duselongdouble has been facilitated. Cheers, Rob -- 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: Cross-compiling for i686-pc-mingw32
- Original Message - From: "Charles Wilson" However, with cygwin-1.7.5, it doesn't work. For now, use CC='gcc-3 -mno-cygwin'. Soon you'll be able to use a real, honest-to-god cross compiler version of gcc-4 instead (e.g. "i686-pc-mingw32-gcc") Thanks Chuck. That works well I look forward to being able to cross-compile with gcc-4. Cheers, Rob -- 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
Cross-compiling for i686-pc-mingw32
Hi, With cygwin-1.5.25 I can cross-compile libraries for native win32 by starting with the following configure command: ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin CC='gcc -mno-cygwin' host_alias=i686-pc-mingw32 and that has worked fine on the few occasions that I've tried it. However, with cygwin-1.7.5, it doesn't work. To begin with, '-mno-cygwin' now causes an error - so I've tried removing the CC argument and leaving the rest of the command unchanged. Then the building of the library (currently proj-4.7.0) works fine - but the resulting library is built for i686-pc-cygwin, not for i686-pc-mingw32. Do I need to run a different configure command ? Or have I missed something ? Attached is the config.log for one of my cross-compilation attempts. In it I see: configure:3745: checking build system type configure:3763: result: i686-pc-cygwin configure:3785: checking host system type configure:3800: result: i686-pc-mingw32 However, proj.exe (one of the executables that gets built) needs the cygwin dll in order to run. With cygwin-1.5.25, proj.exe is definitely a win32 app (doesn't need the cygwin dll). Cheers, Rob config.log Description: Binary 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: sshd - sftp problem (perl demo)
- Original Message - From: "Sisyphus" I'm also unable to upload files to the Cygwin installation using SCP. (Again, no problems with SCP when connected to the remote linux box.) Where I've written "SCP", I meant "SCP over ssh". Cheers, Rob -- 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
sshd - sftp problem (perl demo)
Hi, I have the following perl script that attempts to connect (from native Windows) to an sshd server (either localhost, which is a Cygwin sshd server, or a remote linux host) and create a Net::SSH2::SFTP object. ### use warnings; use Net::SSH2; my ($host, $user, $pass) = qw(blah blah blah); my $ssh2 = Net::SSH2->new; die "can't connect" unless $ssh2->connect($host); print "Connected\n"; die "can't authenticate" unless $ssh2->auth(username => $user, password => $pass); print "Authenticated\n"; my $sftp = $ssh2->sftp; print $sftp, "\n"; # Line 19 $ssh2->disconnect(); ### Works fine when connecting to the sshd server on the remote linux box. The script then outputs: C:\_32\pscrpt\net-ssh2>perl cygwin.pl Connected Authenticated Net::SSH2::SFTP=SCALAR(0x2a92594) But when I modify the script to connect to the Cygwin sshd server I get: C:\_32\pscrpt\net-ssh2>perl cygwin.pl Connected Authenticated Use of uninitialized value $sftp in print at cygwin.pl line 19. No problem with the connection or the authentication, but the call to $ssh2->sftp is clearly failing. First thing that comes to mind is that I might need to install/run something additional for SFTP to be enabled on Cygwin. All I've done is install cygrunsrv and openssh, and then start the openssh server with 'net start sshd'. Did I miss something ? Second thing that comes to mind is that connecting via user cyg_server (using the password I created when I ran 'ssh-host-config -y') might not be the right thing to do. Is it ? Third thing that comes to mind is that it might be permissions related. Advice welcome. I'm also unable to upload files to the Cygwin installation using SCP. (Again, no problems with SCP when connected to the remote linux box.) Cheers, Rob -- 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: resolving _glgetstr...@4 by linking to _glGetString
- Original Message - From: "Sisyphus" How do I get gcc-3.4.4 to apply those fixups that gcc-4.3.4 applied ? Not so much of an issue any more (still a bit curious about it, but). I soon found that providing a '-lopengl32' link instead of '/cygdrive/c/Windows/System32/opengl32.dll' fixed the problem. Cheers, Rob -- 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
resolving _glgetstr...@4 by linking to _glGetString
Hi, When building the perl extension OpenGL-0.62 on Cygwin-1.7.5, gcc-4.3.4 I get the warning: Warning: resolving _glgetstr...@4 by linking to _glGetString Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups That's exactly what needs to be done, and everything goes fine. On Cygwin-1.5.25, gcc-3.4.4, however, running the same procedure I simply get the errors: glversion.o:glversion.c:(.text+0xc5): undefined reference to `_glgetstr...@4' glversion.o:glversion.c:(.text+0xd7): undefined reference to `_glgetstr...@4' glversion.o:glversion.c:(.text+0xe9): undefined reference to `_glgetstr...@4' glversion.o:glversion.c:(.text+0xfb): undefined reference to `_glgetstr...@4' How do I get gcc-3.4.4 to apply those fixups that gcc-4.3.4 applied ? The actual commands being run in order to build glversion are: gcc -DWIN32 -DHAVE_FREEGLUT -c glversion.c followed by g++ -o glversion glversion.o -L../FreeGLUT -lfreeglut /cygdrive/c/WINDOWS/system32/opengl32.dll I tried inserting '--enable-stdcall-fixup' into the second of those commands, but it didn't have any effect. Cheers, Rob -- 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: Looking for gcc.exe
- Original Message - From: "Larry Hall (Cygwin)" To: Sent: Tuesday, June 29, 2010 7:30 AM Subject: Re: Looking for gcc.exe On 6/28/2010 10:01 AM, Stephen Morton wrote: "Sisyphus" Wrote: I've just installed a fresh "CYGWIN_NT-6.0-WOW64 desktop2 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin", including gcc-4 (4.3.4-3). According to http://cygwin.com/packages/ there should be an executable named gcc.exe in there - but I see only gcc-4.exe. As a quick fix I've created a copy of gcc-4.exe named gcc.exe, and I expect that will work ok. (I've also done the same wrt cpp-4.exe, g++-4.exe and gcov-4.exe.) Is that what we're supposed to do ? ... or did I miss something ? You need to add /etc/alternatives to your path. There is always a symbolic link in '/usr/bin' for 'gcc' if it's been properly installed. Well ... I did have some doubts as to whether it was installed correctly, though everything seemed fine apart from the absence of "gcc", etc. However, I don't have a /usr/bin folder. And no /etc/alternatives either. There's no need to clutter your path regardless though. Just run 'sh /bin/set-gcc-default-4.sh' if you're missing '/usr/bin/gcc'. bash-3.2# sh /bin/set-gcc-default-4.sh /bin/set-gcc-default-4.sh: line 7: /usr/sbin/alternatives: No such file or directory /bin/set-gcc-default-4.sh: line 7: /usr/sbin/alternatives: No such file or directory /bin/set-gcc-default-4.sh: line 7: /usr/sbin/alternatives: No such file or directory /bin/set-gcc-default-4.sh: line 7: /usr/sbin/alternatives: No such file or directory I'll wipe the current Cygwin installation and do it again (hopefully I can get it done right next time :-) Everything I've tried seems to be working quite well, but there's bound to be ramifications down the track if I don't fix it up properly. Thanks. Cheers, Rob -- 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
Looking for gcc.exe
Hi, I've just installed a fresh "CYGWIN_NT-6.0-WOW64 desktop2 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin", including gcc-4 (4.3.4-3). According to http://cygwin.com/packages/ there should be an executable named gcc.exe in there - but I see only gcc-4.exe. As a quick fix I've created a copy of gcc-4.exe named gcc.exe, and I expect that will work ok. (I've also done the same wrt cpp-4.exe, g++-4.exe and gcov-4.exe.) Is that what we're supposed to do ? ... or did I miss something ? Here's the output of my 'gcc -v': ## bash-3.2# gcc -v Using built-in specs. Target: i686-pc-cygwin Configured with: /gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4/ configure --srcdir=/gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --infodir=/usr/share/info --mandir=/usr/share/man --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --with-slibdir=/usr/bin --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --disable -__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686 --with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind AS=/opt/gcc-tools/bin/as.exe AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe LD=/opt/gcc-tools/bin/ld.exe LD_FOR_TARGET=/opt/gcc-tools/bin/ld.exe --with-ecj-jar=/usr/share/java/ecj.jar Thread model: posix gcc version 4.3.4 20090804 (release) 1 (GCC) ## Cheers, Rob -- 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: 'git commit' problem
- Original Message - From: "Matthias Andree" To: "Sisyphus" ; When I try to 'git commit' my amendments I often get hit with "* trailing whitespace (line xxx)" errors. Configure your editor to not leave whitespace at the end of lines (sometimes the features are named flowed mode or soft line breaks or similarly, not always obvious). Annoyingly, the offending whitespace seems to already be in existence on the files (on github) that I'm trying to amend. Afaict my editor isn't introducing any additional trailing whitespace, but I can't commit because of the *pre-existing* trailing whitespace. Anyway, thanks for the pointers Matthias ... appreciated. (For the moment, I'm just running some perl code on the file(s) to clean up the offending spaces before I commit. It's a bit tedious, but it only needs to be done once on each file, and it does enable me to get the job done.) Cheers, Rob -- 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
'git commit' problem
Hi, This might be a general 'git' issue rather than something specific to Cygwin. (The only git I have used is Cygwin's git - version 1.5.4.) When I try to 'git commit' my amendments I often get hit with "* trailing whitespace (line xxx)" errors. Firstly, I'm wondering what's wrong with having whitespace at the end of a line ? Why should it prevent changes from being committed ? Secondly, what's the best way to deal with this ? Can this check be easily disabled ? Cheers, Rob -- 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: Can't install Perl modules with new Cygwin because of gcc version
- Original Message - From: "Chloe" I might be able to add a cc flag in cpan, but I don't know how to take one out. One hack (which I think should work) would be to remove " -fstack-protector" from the ccflags spec in cygwin/lib/perl5/5.10/cygwin/Config_heavy.pl. (I'm guessing that's the location of Config_heavy.pl - in my aging version of Cygwin it's in cygwin/lib/perl5/5.8/cygwin/ .) Cheers, Rob -- 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: undefined reference
- Original Message - From: "Winderson Martins de Souza" To: ; Sent: Friday, June 26, 2009 11:32 PM Subject: Fwd: undefined reference Hello, I'm trying to compile gettext on cygwin, but I'm getting an undefined reference error, could anyone help?? I'm running configure without shared library, as with it I was getting another undefined error [snip] msgcat-c++msgcat.o:c++msgcat.cc:(.text+0x701): undefined reference to `__imp__color_test_mode' The '__imp' prefix signifies a shared library - so, if (as I suspect) this symbol is supposed to be resolved by the gettext library, then the message that you've got a *static* library hasn't "got through". It may, in fact, be simpler to build a shared library. What 'undefined reference' did you strike when you tried that ? Cheers, Rob -- 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: Optimize cygwin on recent windows version (Vista and Seven)
- Original Message - From: "Chris Sutcliffe" >> Times taken were: >> Linux : 1.5 mimutes >> XP (mingw): 6.5 minutes >> Vista (mingw): 16.5 minutes >> Vista (cygwin): 23.25 minutes If UAC is disabled, does it improve performance? Yes - for Cygwin it reduced the time taken by 2 minutes (ie took 21.25 minutes). Didn't check with msys - I guess there'd be a similar ~10% reduction with it. 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: Optimize cygwin on recent windows version (Vista and Seven)
- Original Message - From: "Edward Lam" Times taken were: Linux : 1.5 mimutes XP (mingw): 6.5 minutes Vista (mingw): 16.5 minutes Vista (cygwin): 23.25 minutes Are these tests on 64-bit or 32-bit Windows? All on 32-bit, except for Vista which is 64-bit. It hadn't really occurred to me that the 64-bit architecture might be playing a major role in the difference - I thought it must surely be the different OS's that accounted for the bulk of the slowdown ... interesting :-) 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: Optimize cygwin on recent windows version (Vista and Seven)
- Original Message - From: "Vincent R." To: Sent: Tuesday, June 16, 2009 1:03 AM Subject: Optimize cygwin on recent windows version (Vista and Seven) Hi, Until now I was using cygwin on Windows XP and I was satisfied by cygwin-1.7 but these last few days I switched to a more powerful laptop with very fast hardware (Core Duo 3.0 Ghz and SSD OCZ Vertex) and running windows Seven. I don't have Windows Seven - but I do have Windows Vista, which seems to be afflicted with the same crippling disabilities as Windows Seven, afaict. Now when I test cygwin, everything is so sloowww, I know this is not something new but do you plan to work on this issue ? Don't know if mingw could be one of them ? I regularly build libraries using MinGW in the MSYS shell (by running './configure', 'make', etc.). I find this activity is a little quicker with MinGW/MSYS than with Cygwin. However, the main problem seems to be the OS - and your best way of getting a reasonable performance for this type of activity is to stick with XP. (Maybe Win2K and earlier offer even better performance - I haven't checked.) Here are some timings I did recently for building the mpc-0.6 library. On Vista and XP, (in the same version of the MSYS shell, and using the same version of MinGW's gcc) I ran: ./configure --disable-shared --enable-static CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib && make && make check On linux (mdk-9.1) and cygwin, it was the same command, but without the CPPFLAGS and LDFLAGS arguments (as they're not necessary on linux and cygwin). Times taken were: Linux : 1.5 mimutes XP (mingw): 6.5 minutes Vista (mingw): 16.5 minutes Vista (cygwin): 23.25 minutes In terms of processor capacity, the Vista box should be the fastest, followed by the XP box, followed by the old Linux box, but clearly, OS considerations are well and truly overwhelming those capacities. (If it were just up to the processor speeds, then there wouldn't be a great difference, anyway.) I raised this on the MinGW list, and the feeling there was that there wasn't much that the MinGW folk could do about it. (I didn't present the cygwin timings to the MinGW list, as I've only just done them now.) One suggestion was to build the libraries on the linux box as a cross-compilation. Even for a small library like mpc it might be worth doing that way (assuming you have access to a linux box), and for something like gmp, which takes over an hour to build and test on Vista, it's definitely an appealing idea. I don't have Cygwin on the XP laptop - but I assume it would perform the task more than twice as quickly on XP (as did MinGW/MSYS). 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: Copy converts tabs to spaces ?
- Original Message - From: "Sisyphus" One workaround is to run 'notepad foo.c' instead of 'cat.c' Hmmm .. doesn't make a lot of sense. I meant "instead of 'cat foo.c'". 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: Copy converts tabs to spaces ?
- Original Message - From: "xerces8" Details: - print the content of some text file that has tabs (like a C program source) : cat foo.c - select and copy the text with the mouse - paste (ctrl-V) into WordPad You'll get the same behaviour if, instead of running 'cat foo.c' in the bash/RXVT shell, you start by running 'type foo.c' in the cmd.exe shell. One workaround is to run 'notepad foo.c' instead of 'cat.c', and then copy'n'paste from the instance of foo.c that has been opened in notepad. Is that a suitable alternative ? 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: [perl] Portably linking to libstdc++
- Original Message -
From: "Brian Dessent" <[EMAIL PROTECTED]>
.
.
Please post the entire link command and not just the error. It's
impossible to say what the true nature of the problem is otherwise. For
example, if you're trying to link a library and not an executable then
the above error would be due to missing the "-shared" flag.
For the failure in question (ie the WinMain error), I start by running 'perl
Makefile.PL LD="g++"'.
This means that both CC and LD have been set to g++. The failing link
command is:
###
g++ -s -L/usr/local/lib Size.o -o blib/arch/auto/Devel/Size/Size.dll \
/usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a\
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab):
undefined reference to [EMAIL PROTECTED]'
collect2: ld returned 1 exit status
make: *** [blib/arch/auto/Devel/Size/Size.dll] Error 1
###
If I start by running simply 'perl Makefile.PL', then CC is set to g++, but
LD is set to ld2 (gcc).
The error is:
###
ld2 -s -L/usr/local/lib Size.o -o blib/arch/auto/Devel/Size/Size.dll \
/usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a\
gcc -shared -o
Size.dll -Wl,--out-implib=libSize.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import
-Wl,--stack,8388608 -Wl,--enable-auto-image-base -s -L/usr/local/lib Size.o
/usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a
Size.o:Size.c:(.text+0x122): undefined reference to `___gxx_personality_sj0'
Size.o:Size.c:(.text+0x21b): undefined reference to `___cxa_begin_catch'
Size.o:Size.c:(.text+0x24b): undefined reference to `___cxa_end_catch'
[followed by more undefined references to the same symbols]
###
If I start by running 'perl Makefile.PL LIBS="-lstdc++"', then everything
proceeds fine - but only because I've hacked $Config{libpth} to include the
location of libstdc++.a. The same section of the build output is:
###
ld2 -s -L/usr/local/lib Size.o -o blib/arch/auto/Devel/Size/Size.dll \
/usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a -lstdc++ \
gcc -shared -o
Size.dll -Wl,--out-implib=libSize.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import
-Wl,--stack,8388608 -Wl,--enable-auto-image-base \
-s -L/usr/local/lib Size.o
/usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a -lstdc++
Creating library file: libSize.dll.a
mv Size.dll libSize.dll.a blib/arch/auto/Devel/Size/
chmod 755 blib/arch/auto/Devel/Size/Size.dll
cp Size.bs blib/arch/auto/Devel/Size/Size.bs
chmod 644 blib/arch/auto/Devel/Size/Size.bs
/usr/bin/perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0,
'blib/lib', 'blib/arch')" t/*.t
t/basic..ok
t/podok
t/pod_covok
t/recurseok
All tests successful.
Files=4, Tests=69, 2 wallclock secs ( 0.93 cusr + 0.73 csys = 1.66 CPU)
###
But you're right, of course, about the missing "-shared" being a (the?)
problem. If I start with 'perl Makefile.PL LD="g++ -shared"' then everything
works fine:
###
g++ -shared -s -L/usr/local/lib Size.o -o
blib/arch/auto/Devel/Size/Size.dll \
/usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a\
chmod 755 blib/arch/auto/Devel/Size/Size.dll
cp Size.bs blib/arch/auto/Devel/Size/Size.bs
chmod 644 blib/arch/auto/Devel/Size/Size.bs
/usr/bin/perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0,
'blib/lib', 'blib/arch')" t/*.t
t/basic..ok
t/podok
t/pod_covok
t/recurseok
All tests successful.
Files=4, Tests=69, 3 wallclock secs ( 0.93 cusr + 0.79 csys = 1.72 CPU)
###
Apparently g++ needs a "-shared" but ld2 doesn't. (I don't understand that.)
And I don't understand what is achieved by:
gcc -shared -o
Size.dll -Wl,--out-implib=libSize.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import
-Wl,--stack,8388608 -Wl,--enable-auto-image-base \
-s -L/usr/local/lib Size.o /usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a
That command gets run only if LD is ld2 - there doesn't seem to be a
comparable command if LD is set to either "g++" or "g++ -shared".
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: [perl] Portably linking to libstdc++
- Original Message -
From: "Reini Urban" <[EMAIL PROTECTED]>
.
.
Current cygwin perl already has g++ as LD for some releases.
Good - I think that's a step in the right direction. (I wonder how we can
get linux builds to start doing the same.)
On my 5.8.8, LD is set to ld2 which, I think, is an alias for 'gcc:
[EMAIL PROTECTED] ~
$ perl -V:ld
ld='ld2';
[EMAIL PROTECTED] ~
$ ld2 -v
gcc -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab):
undefined reference to [EMAIL PROTECTED]'
collect2: ld returned 1 exit status
Why does that happen ?
Maybe because the linker believes you have a -mwindows GUI app?
There is some Microsoft-specific stuff in the XS file ... so such a
confusion is not out of the question.
Is it strange that it believes that only when LD is set to g++ ?
If I leave LD set to gcc and explicitly link to libstdc++.a, then there's no
problem.
Which distro are you talking about?
InlineX::CPP2XS I assume.
No problems with InlineX::CPP2XS.
I was doing some testing of someone else's upcoming release of Devel::Size
(0.72), which
has been significantly rewritten and is quite different to the current CPAN
version (0.71).
It's only small, so I'll attach it and you can take a look if you like.
Sounds like it should build ok for you, without the need to make any
amendment.
In the Makefile.PL you'll see that I've commented out the line:
LIBS => '-lstdc++',
If I'm to successfully build that module on my cygwin perl, I need to
include that line. And even then, that works only because I've added the
location of
libstdc++.a to my $Config{libpth}.
If it does build for more recent cygwin perls, then I guess the matter has
already been dealt with - and one can't ask for more than that :-)
Cheers,
Rob
Devel-Size-test.tar.gz
Description: GNU Zip compressed data
--
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: [perl] Portably linking to libstdc++
- Original Message -
From: "Brian Dessent" <[EMAIL PROTECTED]>
But on cygwin, there is no '-lstdc++' to be found in $Config{libpth}, so
MakeMaker decides to not pass the switch on (which has always been
MakeMaker's policy in such cases, afaik). This is a pity - there would be
no
problem if it *did* the pass switch on, as both gcc and g++ on cygwin
will
resolve that link.
MakeMaker should be fixed to allow the switch through.
This has been a long standing feature of MakeMaker, and I expect that a
significant number of modules would be broken if that behaviour was changed.
It allows module authors the convenience of being able to specify all libs
that might be needed, without having to worry about the fact that some of
those libs will be both unneeded and absent on some systems. At least, I
*guess* that's the idea behind it.
It would be better, however, if there was some way to override that
behaviour and force MakeMaker to pass the switch on. (I don't think such a
facility exists ... but I couldn't say for sure ...)
Really the correct way to link C++ code is by using g++ which doesn't
require this manual -lstdc++ nonsense. Can't you just do that, by
either fixing the makefile to link with $(CXX) or overriding the
appropriate variable?
Aaah ... good point. I had missed something.
I had changed $Config{cc} from 'gcc' to 'g++' thinking that should do the
trick. And it works fine for MinGW-built perls but (as it turns out)
only because $Config{ld} is already set to 'g++'.
On both linux and cygwin, I've just realised that $Config{ld} is still set
to 'gcc' - which is what necessitates linking explicitly to libstdc++.
Of course, the other option on both linux and cygwin is to set *both*
$Config{cc} and $Config{ld} to 'g++', and that works fine on linux, but
doesn't quite work on cygwin where I still get an undefined reference to
[EMAIL PROTECTED]':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab):
undefined reference to [EMAIL PROTECTED]'
collect2: ld returned 1 exit status
Why does that happen ?
Btw, overriding $Config{cc} and $Config{ld} is trivial. In the Makefile.PL's
%WriteMakefile() it's just a matter of:
CC => 'g++',
LD => 'g++',
Or they can be overridden from the command line when the Makefile.PL is run:
perl Makefile.PL CC="g++" LD="g++"
And I think that's all I need do on any perl build where g++ is the name of
the c++ compiler except for Cygwin (where it doesn't work because of
that undefined reference to [EMAIL PROTECTED]').
Thanks for the reply, 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: [perl] Portably linking to libstdc++
- Original Message -
From: "Sisyphus" <[EMAIL PROTECTED]>
.
.
How do I write that LIBS assignment so that it would be portable across
different *Cygwin* installations ?
I still don't know how to do that - though I did come to a better
understanding of how the problem arises.
For both linux and cygwin, 'perl -V:libpth' returns 'libpth='/usr/local/lib
/usr/lib /lib'.
On linux I can run 'perl Makefile.PL LIBS="-lstdc++"' and that runs fine
because '-lstdc++' is found in $Config{libpth}, in the form of libstdc++.so.
But on cygwin, there is no '-lstdc++' to be found in $Config{libpth}, so
MakeMaker decides to not pass the switch on (which has always been
MakeMaker's policy in such cases, afaik). This is a pity - there would be no
problem if it *did* the pass switch on, as both gcc and g++ on cygwin will
resolve that link.
IMO, on my cygwin perl, $Config{libpth} should be set to '/usr/local/lib
/usr/lib /lib /lib/gcc/i686-pc-cygwin/3.4.4', and I regard it as a bug that
'/lib/gcc/i686-pc-cygwin/3.4.4' is not being included in $Config{libpth}. In
fact, I've modified the libpth setting in Config.pm to '/usr/local/lib
/usr/lib /lib /lib/gcc/i686-pc-cygwin/3.4.4'.
Is there somewhere I should lodge a bug report about this ?
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/
[perl] Portably linking to libstdc++
Hi, On linux, I can have my perl distro link to libstdc++ by simply specifying (in the Makefile.PL's %WriteMakefile) : LIBS => ['-lstdc++'], And, for MinGW-built perls on Win32, the same construct works. For Cygwin, it seems that is not sufficient (as the directory that houses libstdc++.a is apparently not searched by default). Instead, Cygwin needs something like: LIBS => ['-L/lib/gcc/i686-pc-cygwin/3.4.4 -lstdc++'], But that doesn't look very portable across different Cygwin installations. (I'm looking mainly at the '3.4.4', and thinking that not every Cygwin installation will have such a directory.) How do I write that LIBS assignment so that it would be portable across different *Cygwin* installations ? 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: ppm disappeared
- Original Message - From: <[EMAIL PROTECTED]> . . $ ppm Can't locate ActivePerl/PPM/limited_inc.pm in @INC (@INC contains: /usr/lib/perl5/5.10/i686-cygwin /usr/lib/perl5/5.10 /usr/ lib/perl5/site_perl/5.10/i686-cygwin /usr/lib/perl5/site_perl/5.10 /usr/lib/perl5/vendor_perl/5.10/i686-cygwin /usr/lib/perl5/vendor_perl/5.10 /usr/lib/perl5/vendor_perl/5.10 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at /cygdrive/c/Perl/bin/ppm line 4. BEGIN failed--compilation aborted at /cygdrive/c/Perl/bin/ppm line 4. You're running /cygdrive/c/Perl/bin/ppm - which is the ActivePerl ppm utility, *not* the Cygwin ppm utility. (I didn't know Cygwin had a ppm utility btw.) Apparently, the ActivePerl ppm utility needs ActivePerl/PPM/limited_inc.pm, but can't find that file in your Cygwin build of perl - which is hardly surprising. (Not exactly sure of the mechanism that leads to ActivePerl's ppm finding Cygwin's perl instead of ActivePerl's perl - but that's what's happening.) The problem would probably go away if you removed /cygdrive/c/Perl/bin/ppm from Cygwin's $PATH - or at least put it at the end of $PATH. In installing ActivePerl, the system environment variable was probably altered to include C:/Perl/bin, and your bash shell is picking it up from there. 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: Perl IPC::Cmd
- Original Message - From: "Ronald Fischer" <[EMAIL PROTECTED]> To: Sent: Monday, May 05, 2008 8:00 PM Subject: Perl IPC::Cmd I'm using perl 5.8.7 for Solaris perl 5.8.8 for Cygwin perl 5.8.10 for Windows (native) perl 5.8.10 ?? To my surprise, the Cygwin version of Perl does not include the standard module IPC::Cmd, though the other two (in particular, the earlier 5.8.7 Perl) do. Is there a particular reason, why IPC::Cmd is left out from the Cygwin distribution? I don't know. Mind you, they don't need a reason to not include a non-core module - the fact that it's not a core module is, of itself, sufficient reason. With perl 5.10.0, IPC::Cmd became a core module, so *every* build of perl 5.10.0 ought to include that module. 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: Building perl-5.10.0
- Original Message - From: "Reini Urban" <[EMAIL PROTECTED]> To: Sent: Sunday, March 23, 2008 3:48 AM Subject: Re: Building perl-5.10.0 Sisyphus schrieb: - Original Message - From: "Matthew Persico" Well after a bit of googling around, the answer is this: 1) In a Windows cmd command prompt, cd where your cygwin lives - mine is at c:\opt\cygwin Mine is at C:\cygwin. 2) cd .. I first ran 'attrib cygwin' to see what was already there: Within cygwin you have better tools than the attrib or cacls. Use your shell and the posix tools, and don't add additional ACL's by using the explorer! C:\>attrib cygwin C:\cygwin 3) attrib -r cywgin - that removed the read-only bit. Don't try it in Windows Explorer; it does not "stick" > I then ran 'attrib -r cygwin' (even though it doesn't appear to be readonly to begin with). 4) Then in a Cygwin window, cd / 5) chmod 777 . That errors out as follows: [EMAIL PROTECTED] / $ chmod 777 . chmod: changing permissions of `.': Permission denied After all that I get: [EMAIL PROTECTED] / $ ls -alrt total 165 dr-xr-xr-x 1 0 root 0 Jan 1 1970 cygdrive dr-xr-xr-x 1 Rob None 0 Dec 1 2006 proc d---r-x---+ 7 admin Users 0 Mar 12 12:37 var d---r-x---+ 2 admin Users 0 Mar 12 12:37 dev d---r-x---+ 2 admin Users 0 Mar 12 12:37 tmp r-x---+ 1 admin Users 57 Mar 12 12:38 Cygwin.bat drwxrwxrwx+ 3 Rob None 0 Mar 12 12:38 home d---r-x---+ 12 admin Users 4096 Mar 12 12:38 .. d---r-x---+ 12 admin Users 4096 Mar 12 12:38 . d---r-x---+ 11 admin Users 4096 Mar 12 12:50 etc d---r-x---+ 11 admin Users 12288 Mar 12 12:51 lib d---r-x---+ 16 admin Users 4096 Mar 12 12:51 usr d---r-x---+ 2 admin Users 131072 Mar 15 21:20 bin r-x---+ 1 admin Users 7022 Mar 15 21:20 Cygwin.ico With such a mess, first fix your directories, than the files. Or better start from scratch. Ummm ... it's a fresh installation ... which I would have thought already constitutes a "start from scratch". A sane initial permission concept for cygwin would help. Your big problem is that cygwin has no write access, the user even no read access! d---r-x---+ The second problem is the +, the special Windows ACL, which should not be here on a plain new cygwin installation. Well ... it *is* there. (I had to google for "ACL" ... just to give you some idea of the extent to which I am already familiar with permissions.) POSIX access() doesn't check the additional ACL's, just the underlying windows calls allow or deny access then. This can be right or this can be contradictive. and running 'make' terminates as before. Besides the obvious not-writable lib/auto dir, note that Dynaloader requires the generated dll to be +x. Of course the blib/arch dir also as for every dir. I made (or at least I think I made) lib/auto writable, but it didn't make any difference. I changed it so that the permisions now read: drwxrwxrwx+ 3 Rob None 0 Mar 15 00:18 auto The error remains unchanged, however. Module::Install had a recent bug in doing POSIX::access() checks for writable dirs, which is wrong for your cases. Without the + (additional ACL's) it works fine. This is a fairly new installation of Cygwin, btw. (I stuffed up the old one trying to install rsync and had to delete the lot.) So there could be some additional stuff here that needs sorting out. I have, however, already built some perl extensions using the 5.8.8 build that was installed when I created this fresh build of Cygwin. And the fact that I can build 5.8.8 from source, but not 5.10.0 leads me to wonder whether this is instead a query that should be raised on p5p ? I would rather blaim cygwin and esp. you. Ok ... I won't raise it on p5p. But I still don't understand why I can build 5.8.8 from source but not 5.10.0. (I would have expected that the very same issues that prevent 5.10.0 from building would have also prevented 5.8.8 from building. That's obviously not the case, so I can only assume that build requirements must have changed dramatically between 5.8.8 and 5.10.0.) Module::Install is also faulty. Note that perl 5.10 is a bit stricter, mainly in taint checking. Group writable is forbidden with 5.10 taint now. Thanks for the reply, Matthew ... appreciated. I have a ACL sanifier in my /usr/local/bin/fixfacl, which recursively removes first the additional ACL's for directories, and then for the files, and simply overwrites it with my preferred user/group. But this a special hack just for me and my seperation into executable or non executable files. I don't care for the additional ACL's. Don't touch symlinks with setfacl or chmod! #!/bin/sh if [ "$1"="." ]; then setfacl -f /etc/facl.dir . find -type d \! -name '.*&
Re: build a GMPlib win32 dll with Cygwin
- Original Message - From: "cyrille37" <[EMAIL PROTECTED]> To: Sent: Wednesday, March 26, 2008 10:36 PM Subject: build a GMPlib win32 dll with Cygwin Hello, I need to use GMPlib (gmplib.org) on windows xp. After compiling GMP with cygwin, for runtime, should I need some cygwin dll to use the GMP dll ? Is there a solution to get only one dll with all in one ? If I understand correctly, you could get what you want by either: 1) Building the GMP dll in the MSYS shell; or 2) Building in Cygwin's shell, but as a cross-compilation for the i686-pc-mingw32 (native win32) host. Either way, you'll end up with a GMP dll that does not need the cygwin dll. I normally go with option 1). 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: Building perl-5.10.0
- Original Message - From: "Matthew Persico" <[EMAIL PROTECTED]> . . Well after a bit of googling around, the answer is this: 1) In a Windows cmd command prompt, cd where your cygwin lives - mine is at c:\opt\cygwin Mine is at C:\cygwin. 2) cd .. I first ran 'attrib cygwin' to see what was already there: C:\>attrib cygwin C:\cygwin 3) attrib -r cywgin - that removed the read-only bit. Don't try it in Windows Explorer; it does not "stick" I then ran 'attrib -r cygwin' (even though it doesn't appear to be readonly to begin with). 4) Then in a Cygwin window, cd / 5) chmod 777 . That errors out as follows: [EMAIL PROTECTED] / $ chmod 777 . chmod: changing permissions of `.': Permission denied After all that I get: [EMAIL PROTECTED] / $ ls -alrt total 165 dr-xr-xr-x 1 0 root 0 Jan 1 1970 cygdrive dr-xr-xr-x 1 Rob None 0 Dec 1 2006 proc d---r-x---+ 7 admin Users 0 Mar 12 12:37 var d---r-x---+ 2 admin Users 0 Mar 12 12:37 dev d---r-x---+ 2 admin Users 0 Mar 12 12:37 tmp r-x---+ 1 admin Users 57 Mar 12 12:38 Cygwin.bat drwxrwxrwx+ 3 Rob None 0 Mar 12 12:38 home d---r-x---+ 12 admin Users 4096 Mar 12 12:38 .. d---r-x---+ 12 admin Users 4096 Mar 12 12:38 . d---r-x---+ 11 admin Users 4096 Mar 12 12:50 etc d---r-x---+ 11 admin Users 12288 Mar 12 12:51 lib d---r-x---+ 16 admin Users 4096 Mar 12 12:51 usr d---r-x---+ 2 admin Users 131072 Mar 15 21:20 bin r-x---+ 1 admin Users 7022 Mar 15 21:20 Cygwin.ico and running 'make' terminates as before. This is a fairly new installation of Cygwin, btw. (I stuffed up the old one trying to install rsync and had to delete the lot.) So there could be some additional stuff here that needs sorting out. I have, however, already built some perl extensions using the 5.8.8 build that was installed when I created this fresh build of Cygwin. And the fact that I can build 5.8.8 from source, but not 5.10.0 leads me to wonder whether this is instead a query that should be raised on p5p ? Thanks for the reply, Matthew ... appreciated. 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/
Building perl-5.10.0
Hi, I thought I might build perl-5.10.0, so I downloaded the perl source into the ~/comp directory, switched to the top level source directory and ran: sh configure -de -Duse64bitint -Dprefix=~/myperl That seemed to run ok - so I then ran 'make'. That process runs for a while but terminates with the following error: --- Making DynaLoader (static_pic) make[1]: Entering directory `/home/Rob/comp/perl-5.10.0/ext/DynaLoader' make[1]: Leaving directory `/home/Rob/comp/perl-5.10.0/ext/DynaLoader' make[1]: Entering directory `/home/Rob/comp/perl-5.10.0/ext/DynaLoader' ERROR: Can't create '../../lib/auto' Do not have write permissions on '/' at -e line 1 I find that somewhat confusing. For a start, I find that '../../lib/auto' exists - so either it *was* succesfully created, or there was no need to create it anyway. (At least, `/home/Rob/comp/perl-5.10.0/lib/auto' exists - and, by my reckoning, that equates to '../../lib/auto'.) As for not having write permissions on '/', what directory is that referring to ? Interestingly, Google turns up a very similar case ( http://www.nntp.perl.org/group/perl.perl5.porters/2007/03/msg121921.html ) but that relates to buildng bleadperl on SuSE 64 ... and no resolution is given. There's no such problem with building perl-5.8.8 from source (using the exact same configure command). The first time I ran it 'make' terminated after a few minutes because ~/myperl/bin didn't already exist, so I simply created that directory, re-ran 'make' and all then proceeded smoothly. (I didn't go to the bother of running 'make test'.) 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/
rsync
Hi, Is there an rsync package for Cygwin ? I ran 'Setup.exe' but couldn't find the beast ... mind you, it's a while since I've run 'Setup.exe' for cygwin, so I might have been missing something that's obvious to the initiated. 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: Need help with Perl/Tk
- Original Message - From: "Michael Kairys" <[EMAIL PROTECTED]> . . I'll say it again, it would be wonderful if Perl/Tk would work with regular win32 graphical elements but nobody has bothered to develop that. Well, ActiveState has :) Actually, I don't think ActiveState do anything other than simply build Perl/Tk from source - same as anyone else can. So the credit for the fact that Tk "simply works" on native Win32 really belongs to the Tk developers. (Faik, some ActiveState identities may well provide input into the Tk development from time to time.) 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: Need help with Perl/Tk
- Original Message - From: "Michael Kairys" <[EMAIL PROTECTED]> To: Sent: Thursday, December 13, 2007 10:26 PM . . Can't load '/usr/lib/perl5/vendor_perl/5.8/cygwin/auto/Tk/Tk.dll' for module Tk: No such file or directory at /usr/lib/perl5/5.8/cygwin/DynaLoader.pm line 230. However /usr/lib/perl5/vendor_perl/5.8/cygwin/auto/Tk/Tk.dll is in fact there: Yes ... but note that the error message doesn't actually say that '/usr/lib/perl5/vendor_perl/5.8/cygwin/auto/Tk/Tk.dll' could not be found. In fact, it says that '/usr/lib/perl5/vendor_perl/5.8/cygwin/auto/Tk/Tk.dll' could not be *loaded* ... which implies that '/usr/lib/perl5/vendor_perl/5.8/cygwin/auto/Tk/Tk.dll' *was* found but ... ummm ... couldn't be *loaded*. Why couldn't it be loaded ? Perhaps because it tried to load a file (usually, in my experience, a dll) that couldn't be found at /usr/lib/perl5/5.8/cygwin/DynaLoader.pm line 230. (When it comes to DynaLoader you gotta learn to read the fine print and make intuitive leaps :-) . . However when I asked in that thread "Is it correct that Cygwin Perl/Tk requires a running X server?" I got: That is one of the stranger assertions to pass by here in a while. I must confess that my reaction would have been pretty much the same. On native Win32, Tk simply "works" ... and no X Server. In the final analysis, I can't answer your question(s), but I do look forward to learning just what the correct solution is :-) 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/
[Perl] source 'typemap' (only) can't be found
Hi, I have a perl source distro - the source files having been written using basic Win32 apps (like wordpad and notepad) : [EMAIL PROTECTED] /cygdrive/c/_32/working/math-gmpz/Math-GMPz-0.24 $ ls -l total 232 --+ 1 Rob None 1361 Dec 5 21:06 CHANGES --+ 1 Rob None 52630 Dec 5 21:06 GMPz.pm --+ 1 Rob None 155272 Dec 5 21:21 GMPz.xs --+ 1 Rob None 1099 Dec 5 21:21 INLINE.h --+ 1 Rob None340 Dec 1 23:36 MANIFEST --+ 1 Rob None 2085 Dec 2 10:57 Makefile.PL --+ 1 Rob None 2880 Nov 3 20:51 README d-+ 2 Rob None 4096 Dec 1 23:37 t --+ 1 Rob None299 Mar 14 2007 typemap [EMAIL PROTECTED] /cygdrive/c/_32/working/math-gmpz/Math-GMPz-0.24 $ perl Makefile.PL . < some custom stuff .. all as expected> . Checking if your kit is complete... Looks good Writing Makefile for Math::GMPz [EMAIL PROTECTED] /cygdrive/c/_32/working/math-gmpz/Math-GMPz-0.24 $ make cp GMPz.pm blib/lib/Math/GMPz.pm /usr/bin/perl.exe /usr/lib/perl5/5.8/ExtUtils/xsubpp -typemap /usr/lib/perl5/5. 8/ExtUtils/typemap -typemap typemap GMPz.xs > GMPz.xsc && mv GMPz.xsc GMPz.c Can't find typemap in /cygdrive/c/_32/working/math-gmpz/Math-GMPz-0.24 make: *** [GMPz.c] Error 255 I do not understand why 'typemap' cannot be found. It has the same permissions as GMPz.xs - which was apparently found since GMPz.xsc (though not GMPz.c) is created. (Hmmm ... on closer inspection, GMPz.xsc is an empty file.) It also has the same permissions as all of the other source files - and they, too, were found. (Otherwise the 'perl Makefile.PL' step would have failed.) Building from the same source (in the same directory) using any one of a number of "native" Win32 perls works without a hitch. My 'perl -V' for cygwin is supplied below. Cheers, Rob $ 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: "collect2.exe has stopped working"
- Original Message - From: "Brian Dessent" <[EMAIL PROTECTED]> . . Um, that particular problem (X_OK and _access()) is 100% irrelevant to Cygwin's gcc Sorry for the noise I had it in my head that the op's post had been sent to the MinGW mailing list. (I'll try to pay better attention in future.) 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: "collect2.exe has stopped working"
- Original Message - From: "Steve Casselman" <[EMAIL PROTECTED]> To: Sent: Sunday, October 28, 2007 11:48 AM Subject: "collect2.exe has stopped working" I have Vista and I'm trying to compile _anything_ with gcc 3.4.4 All I get is "collect2.exe has stopped working" Vista breaks MinGW - and I think that's the issue you're facing here. Try upgrading to 3.4.5. Then unpack http://dessent.net/tmp/gcc-vista-3.4.5-20060117-1.tar.gz into your MinGW root directory. (That will overwrite the existing "problem" files.) I don't know that it's necessary to do the upgrade - but, since the patched files in the (above) tarball have been built for 3.4.5, it's probably the safest way to approach the problem. 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: Once more: performance on Vista
- Original Message -
From: <[EMAIL PROTECTED]>
.
.
In particular, shell scripts (e.g. "configure" scripts) are ridiculously
slow, as is "make" on large projects
I find Vista, XP and 2000 are all (roughly) equally slow. That is, I think
it's a "Windows" thing rather than a "Vista" thing.
I can build ('./configure' and 'make') and test ('make check') *both* GMP
and MPFR on my linux box in the time it takes to run './configure' and
'make' for GMP *alone* on Cygwin. And that's the case irrespective of
whether the Windows box is 2k, XP, or Vista.
I have the impression that a build in the MSYS shell is slightly quicker
than a build in Cygwin's bash shell - but I haven't timed a comparison and
*could* be mistaken about that.
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: Danny Smith stepping down as MinGW maintainer
- Original Message - From: "Christopher Faylor" <[EMAIL PROTECTED]> . . In any event, I hope everyone will join with me to wish Danny the very best of luck in whatever he pursues next. He's going to be an asset whereever he goes and whatever he does. Absolutely !! 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: Cygwin Perl and -Duselongdouble
- Original Message -
From: "Brian Dessent" <[EMAIL PROTECTED]>
.
.
If I can successfully run 'gcc script.c' (where 'script.c' contains a
call
to 'sqrtl') then I'm inclined to say that sqrtl is "available in the C
compiler" (or something like that).
But you can't. That command should fail on Cygwin.
It certainly works for me for 'sqrtl' (but fails for 'frexpl' with
"undefined reference to `_frexpl'"):
--
[EMAIL PROTECTED] ~/C
$ cat script.c
#include
int main(void) {
long double x = sqrtl(7);
printf("%.19Lf\n", x);
return 0;
}
[EMAIL PROTECTED] ~/C
$ gcc script.c
[EMAIL PROTECTED] ~/C
$ ./a.exe
2.6457513110645905904
[EMAIL PROTECTED] ~/C
--
[Snip - a most helpful explanation of where libc and newlib fit into the
picture, and of other aspects that I was finding confusing. Thanks for that
Brian ... much appreciated.]
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: Cygwin Perl and -Duselongdouble
- Original Message - From: "Brian Dessent" <[EMAIL PROTECTED]> To: Sent: Thursday, July 26, 2007 10:29 PM Subject: Re: Cygwin Perl and -Duselongdouble Sisyphus wrote: I haven't checked for 'modfl' and 'frexpl', but 'sqrtl' at least seems to be available in the C compiler. Why does configure report that it's not Why do you say this? Oh ... it's probably just ignorance on my part. If I can successfully run 'gcc script.c' (where 'script.c' contains a call to 'sqrtl') then I'm inclined to say that sqrtl is "available in the C compiler" (or something like that). I gather from your response (and Corinna's) that there are also a couple of things called 'newlib' and 'libc' that enter into the equation. I don't know how they fit in. Feel free to enlighten me (but only if you're so inclined, as I realise that such an explanation is probably not on topic for this list). I find it all quite confusing. My MinGW version of math.h specifically prototypes the "long double" version of a number of functions (ceill, floorl, sqrtl, modfl, ...), yet I can't find any mention of those functions in any of the gcc headers on Linux or Cygwin. If I call sqrtl on linux I have to link to -lm, on Cygwin I don't. On linux I can build perl with -Duselongdouble, on Cygwin I can't. Anyway I gather that -Duselongdouble is out of the question while newlib remains in its current state. (That's pretty much the confirmation I was seeking.) Thanks guys. 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/
Cygwin Perl and -Duselongdouble
Hi, I'd like to have a perl on Cygwin built with -Duselongdouble, so I tried building blead (5.9.5) from source with: ./configure -de -Dusemorebits -Dprefix=~/Rob -Dusethreads -Uusemymalloc -Doptimize=-O3 -Dusedevel but that failed, culminating as follows: . . sqrtl() NOT found. scalbnl() NOT found. modfl() NOT found. modfl() prototype NOT found. *** You requested the use of long doubles but you do not seem to have *** the following mathematical functions needed for long double support: *** sqrtl modfl frexpl *** Please rerun Configure without -Duselongdouble and/or -Dusemorebits. *** Cannot continue, aborting. I haven't checked for 'modfl' and 'frexpl', but 'sqrtl' at least seems to be available in the C compiler. Why does configure report that it's not available ? (I don't need a detailed account ... rather I'm just seeking confirmation that the error is valid and well founded :-) By way of explanation, I find that perls built with -Duse64bitint but not -Duselongdouble don't DWIM very well. For example (with my current Cygwin build of perl 5.8.7 built with -Duse64bit int): - [EMAIL PROTECTED] ~/comp/perl-5.9.5 $ perl -e 'print "Crap" if 2 ** 55 + 6 == 2 ** 55 + 7' Crap [EMAIL PROTECTED] ~/comp/perl-5.9.5 - As I understand it, that's typical of *all* perls built with -Duse64bitint but not -Duselongdouble, not just Cygwin. (Build with -Duselongdouble as well and it doesn't print "Crap" ... on linux, at least.) 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/
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/
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: Problem with ping in Windows Vista
- Original Message - From: "Arthur Niswar" <[EMAIL PROTECTED]> To: Sent: Thursday, July 19, 2007 9:10 PM Subject: Problem with ping in Windows Vista Hi, I am using Cygwin on Windows Vista Business. The problem is: whenever I try to ping another host on the local network, it always fails. Nothing to do with Cygwin, but I had some connectivity issues on Vista Business that took me quite a while to sort out. I was able to ping by IP address, but not by name. The only solution I found was to run (in the cmd shell) 'msconfig' and elect for a "Selective startup" that disabled "IP Helper". Hard to say whether your issue is connected with "IP helper", but disabling it is something you could try if all else fails. 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/
Test file "is not readable" when running 'make test' (Perl)
Hi, I'm trying to build a very small (and simplistic) perl module that I've created (Foo-0.01): [EMAIL PROTECTED] /cygdrive/c/_32/comp/Foo-0.01 $ perl Makefile.PL Writing Makefile for Foo [EMAIL PROTECTED] /cygdrive/c/_32/comp/Foo-0.01 $ make test cp Foo.pm blib/lib/Foo.pm /usr/bin/perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/testt/test.t is not readable FAILED--1 test script could be run, alas--no output ever seen make: *** [test_dynamic] Error 255 [EMAIL PROTECTED] /cygdrive/c/_32/comp/Foo-0.01 Sure enough, when I look at the permissions associated with t/test.t I find: [EMAIL PROTECTED] /cygdrive/c/_32/comp/Foo-0.01/t $ ls -l total 1 --+ 1 Rob None 46 Jul 5 13:37 test.t [EMAIL PROTECTED] /cygdrive/c/_32/comp/Foo-0.01/t But the permissions associated with these files is *not* something with which I have had to concern myself on previous Cygwin installations. I'm wondering why it's suddenly an issue. And I find the following behaviour: [EMAIL PROTECTED] /cygdrive/c/_32/comp/Foo-0.01 $ /usr/bin/perl.exe -Mblib t/test.t 1..1 ok 1 [EMAIL PROTECTED] /cygdrive/c/_32/comp/Foo-0.01 All of a sudden, the permissions (or lack thereof) are no longer an issue !! So let's just check that command that failed before, by running a copy'n'paste of it: [EMAIL PROTECTED] /cygdrive/c/_32/comp/Foo-0.01 $ /usr/bin/perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/testt/test.t is not readable FAILED--1 test script could be run, alas--no output ever seen [EMAIL PROTECTED] /cygdrive/c/_32/comp/Foo-0.01 Bah!!! ... it has become a problem again. For one perl command there's a problem, but for another perl command there's no problem. Is it something that ExtUtils::Command::MM is doing ? Any help appreciated. 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: Perl documentation inaccessible via 'perldoc'.
- Original Message - From: "Andrew Schulman" <[EMAIL PROTECTED]> . . I wonder, do you have TMPDIR set? Try setting it, e.g. export TMPDIR=/tmp/Rob Yep - that fixes it. Both TEMP and TMP were set, but not TMPDIR. How do I make that alteration a permanent fixture, so that I don't have to do it every time I open a new shell ? I tried editing etc/profile (in wordpad), but only succeeded in stuffing up the line endings - and had to replace that file with a copy of the backup from etc/defaults/etc/profile. Thanks Andrew. 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/
Perl documentation inaccessible via 'perldoc'.
Hi, Just installed the latest cygwin (including Cygwin's build of perl 5.8.7) on Windows Vista Business (64) on an AMD64 box. Trying to access perl documentation using 'perldoc' throws an error: --- [EMAIL PROTECTED] /cygdrive/c/_32/working/math-gmpz/Math-GMPz-0.22 $ perldoc ExtUtils::MakeMaker Error in tempfile() using ./XX: Parent directory (./) is not writable at /usr/lib/perl5/5.8/Pod/Perldoc.pm line 1483 [EMAIL PROTECTED] /cygdrive/c/_32/working/math-gmpz/Math-GMPz-0.22 $ perldoc -f glob Error in tempfile() using ./XX: Parent directory (./) is not writable at /usr/lib/perl5/5.8/Pod/Perldoc.pm line 1483 --- If I cd to (eg) my home directory, then the perldoc commands work fine. Do I really have to make the cwd writable before the command will work ? I've not had to do that in my previous Cygwin installations (on Windows 2000). 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/
