Open p5pRT opened 14 years ago
p5pRT
commented
14 years ago 'make test' produces the following in blead under Cygwin on Windows:
ext/XS-APItest/t/call_checker..................................fail at APItest.xs line 1763 at t/call_checker.t line 7. # Looks like your test exited with 255 before it could output anything. FAILED--expected 64 tests\, saw 0
p5pRT
commented
13 years ago On Thu\, Oct 21\, 2010 at 09:34:15AM -0700\, Jerry D. Hedden wrote:
'make test' produces the following in blead under Cygwin on Windows:
ext/XS-APItest/t/call_checker..................................fail at APItest.xs line 1763 at t/call_checker.t line 7. # Looks like your test exited with 255 before it could output anything. FAILED--expected 64 tests\, saw 0
Hi Jerry\, are you still seeing this failure?
-- Thank God I'm an atheist.....
p5pRT
commented
13 years ago The RT System itself - Status changed from 'new' to 'open'
p5pRT
commented
13 years ago Yes\, the problem still exists. Here is the latest:
ext/XS-APItest/t/call_checker................................fail 5200b055!=6a1960b0 at APItest.xs line 2188 at t/call_checker.t line 7. # Looks like your test exited with 255 before it could output anything. FAILED--expected 64 tests\, saw 0
On Wed\, Mar 30\, 2011 at 12:12\, Dave Mitchell \davem@​iabyn\.com wrote:
On Thu\, Oct 21\, 2010 at 09:34:15AM -0700\, Jerry D. Hedden wrote:
'make test' produces the following in blead under Cygwin on Windows:
ext/XS-APItest/t/call_checker..................................fail at APItest.xs line 1763 at t/call_checker.t line 7. # Looks like your test exited with 255 before it could output anything. FAILED--expected 64 tests\, saw 0
Hi Jerry\, are you still seeing this failure?
p5pRT
commented
13 years ago Jerry D. Hedden wrote:
Yes\, the problem still exists.
Unless we have a Win32 linker wizard in the house\, I suggest that we should just skip that part of the test on Win32.
-zefram
p5pRT
commented
13 years ago On Fri\, 01 Apr 2011\, Zefram wrote:
Jerry D. Hedden wrote:
Yes\, the problem still exists.
Unless we have a Win32 linker wizard in the house\, I suggest that we should just skip that part of the test on Win32.
I assume you meant Cygwin\, not Win32.
I have fixed this same issue for MSWin32 with commit ad6ab6c50\, and I suspect that the Cygwin side might be fixed by moving the change from win32/win32.h into perl.h:
http://perl5.git.perl.org/perl.git/commitdiff/ad6ab6c50
of course wrapped with:
#if defined(__CYGWIN__) || defined(WIN32) #endif
It needs confirmation from Jerry and/or Reini that this actually solves the problem before we bother asking Jesse if he prefers the change\, or the skipping of the test for 5.14.
Cheers\, -Jan
p5pRT
commented
13 years ago On Fri 1.Apr'11 at 18:11:48 -0700\, Jan Dubois wrote:
On Fri\, 01 Apr 2011\, Zefram wrote:
Jerry D. Hedden wrote:
Yes\, the problem still exists.
Unless we have a Win32 linker wizard in the house\, I suggest that we should just skip that part of the test on Win32.
I assume you meant Cygwin\, not Win32.
I have fixed this same issue for MSWin32 with commit ad6ab6c50\, and I suspect that the Cygwin side might be fixed by moving the change from win32/win32.h into perl.h:
http://perl5.git.perl.org/perl.git/commitdiff/ad6ab6c50
of course wrapped with:
#if defined(__CYGWIN__) || defined(WIN32) #endif
It needs confirmation from Jerry and/or Reini that this actually solves the problem before we bother asking Jesse if he prefers the change\, or the skipping of the test for 5.14.
If we think it works\, I'd rather the fix than skipping the test.
p5pRT
commented
13 years ago 2011/4/2 Jan Dubois \jand@​activestate\.com:
On Fri\, 01 Apr 2011\, Zefram wrote:
Jerry D. Hedden wrote:
Yes\, the problem still exists.
Unless we have a Win32 linker wizard in the house\, I suggest that we should just skip that part of the test on Win32.
I assume you meant Cygwin\, not Win32.
I have fixed this same issue for MSWin32 with commit ad6ab6c50\, and I suspect that the Cygwin side might be fixed by moving the change from win32/win32.h into perl.h:
http://perl5.git.perl.org/perl.git/commitdiff/ad6ab6c50
of course wrapped with:
#if defined(__CYGWIN__) || defined(WIN32) #endif
It needs confirmation from Jerry and/or Reini that this actually solves the problem before we bother asking Jesse if he prefers the change\, or the skipping of the test for 5.14.
Oops. This is a rather tricky change\, which will need some testing time I do not have in the moment. I'm on darwin right now...
Jerry\, can you do this? We would also need some embed tests\, and I'm not sure if the core suite does test it enough. -- Reini Urban
p5pRT
commented
13 years ago On Sat\, Apr 2\, 2011 at 04:20\, Reini Urban \rurban@​x\-ray\.at wrote:
2011/4/2 Jan Dubois \jand@​activestate\.com:
On Fri\, 01 Apr 2011\, Zefram wrote:
Jerry D. Hedden wrote:
Yes\, the problem still exists.
Unless we have a Win32 linker wizard in the house\, I suggest that we should just skip that part of the test on Win32.
I assume you meant Cygwin\, not Win32.
I have fixed this same issue for MSWin32 with commit ad6ab6c50\, and I suspect that the Cygwin side might be fixed by moving the change from win32/win32.h into perl.h:
http://perl5.git.perl.org/perl.git/commitdiff/ad6ab6c50
of course wrapped with:
#if defined(__CYGWIN__) || defined(WIN32) #endif
It needs confirmation from Jerry and/or Reini that this actually solves the problem before we bother asking Jesse if he prefers the change\, or the skipping of the test for 5.14.
Oops. This is a rather tricky change\, which will need some testing time I do not have in the moment. I'm on darwin right now...
Jerry\, can you do this?
I took a look at this\, but I'm not able to figure out the intricacies of how to set up all the nested conditions for the includes.
We would also need some embed tests\, and I'm not sure if the core suite does test it enough. -- Reini Urban
p5pRT
commented
13 years ago Jerry D. Hedden wrote:
ext/XS-APItest/t/call_checker................................fail 5200b055!=6a1960b0 at APItest.xs line 2188 at t/call_checker.t line 7. # Looks like your test exited with 255 before it could output anything. FAILED--expected 64 tests\, saw 0
I've just uploaded a CPAN module that provides cv_set_call_checker() and friends on pre-5.13.6 Perls. (All the way back to 5.6.0!) I haven't yet made any allowance in it for this linker issue. I'm expecting that I'll end up declaring the module's functions with PERL_CALLCONV\, modified based on the fix for this core test. Those who have taken an interest in the core issue\, please also try out Devel-CallChecker. I'll be watching the CPAN Testers results\, but it'd be handy to have testers familiar with the particular platform-specific issues. Thanks.
-zefram
p5pRT
commented
13 years ago On Sat\, 02 Apr 2011\, Jerry D. Hedden wrote:
On Sat\, Apr 2\, 2011 at 04:20\, Reini Urban \rurban@​x\-ray\.at wrote:
Oops. This is a rather tricky change\, which will need some testing time I do not have in the moment. I'm on darwin right now...
Hmm\, I thought it would be straight-forward to move the definitions and test them.
Jerry\, can you do this?
I took a look at this\, but I'm not able to figure out the intricacies of how to set up all the nested conditions for the includes.
Ok\, ok\, I'll try it myself then. I've never built Perl with Cygwin before though\, so I'm wondering if I'm doing things alright: Just running `./Configure -des` has turned my MacBook into a hairblower for over 30 minutes now\, and I don't even run Flash on it... Is this normal? By this time I would probably already have finished running `nmake` with a native VC6 build inside the same VM.
We would also need some embed tests\, and I'm not sure if the core suite does test it enough.
I don't think this is necessary for this change.
Cheers\, -Jan
p5pRT
commented
13 years ago On Sun\, 03 Apr 2011\, Jan Dubois wrote:
Ok\, ok\, I'll try it myself then. I've never built Perl with Cygwin before though\, so I'm wondering if I'm doing things alright: Just running `./Configure -des` has turned my MacBook into a hairblower for over 30 minutes now\, and I don't even run Flash on it... Is this normal? By this time I would probably already have finished running `nmake` with a native VC6 build inside the same VM.
Looks like it isn't building with Cygwin for me at all:
$ git clone git://perl5.git.perl.org/perl.git perl $ cd perl $ ./Configure -des $ make
[...]
make[1]: *** No rule to make target `../../cygperl5_14_0.dll'\, needed by `../../ lib/auto/Cwd/Cwd.dll'. Stop. make[1]: Leaving directory `/cygdrive/c/home/Jan/perl/dist/Cwd' Unsuccessful make(dist/Cwd): code=512 at make_ext.pl line 463.
README.cygwin kind of leads me to expect that the above should have worked...
Cheers\, -Jan
PS: Just in case this is somehow relevant:
$ cygcheck.exe -s
Cygwin Configuration Diagnostics Current System Time: Mon Apr 04 01:04:00 2011
Windows XP Professional Ver 5.1 Build 2600 Service Pack 3
Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem W:\p4 W:\bin
Output from C:\cygwin\bin\id.exe UID: 1003(Jan) GID: 513(None) 513(None) 0(root) 544(Administrators) 545(Users)
SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS
USER = 'Jan' PWD = '/cygdrive/c/home/Jan' HOME = '/cygdrive/c/home/Jan'
Use '-r' to scan registry
obcaseinsensitive set to 1
Cygwin installations found in the registry: System: Key: c5e39b7a9d22bafb Path: C:\cygwin
a: fd N/A N/A c: hd NTFS 20465Mb 48% CP CS UN PA FC w: cd UDF 2460Mb 100% CS UN Windows z: net HGFS 476611Mb 84% CP Shared Folders
C:\cygwin / system binary\,auto C:\cygwin\bin /usr/bin system binary\,auto C:\cygwin\lib /usr/lib system binary\,auto cygdrive prefix /cygdrive user binary\,auto
Found: C:\cygwin\bin\awk -> C:\cygwin\bin\gawk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cpp.exe -> C:\cygwin\etc\alternatives\cpp -> C:\cygwin\bin\cpp-4.exe Not Found: crontab Found: C:\cygwin\bin\find.exe Found: C:\WINDOWS\system32\find.exe Found: C:\WINDOWS\system32\find.exe Found: C:\cygwin\bin\gcc.exe -> C:\cygwin\etc\alternatives\gcc -> C:\cygwin\bin\gcc-4.exe Not Found: gdb Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\kill.exe Found: C:\cygwin\bin\ld.exe Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\make.exe Found: C:\cygwin\bin\mv.exe Found: C:\cygwin\bin\patch.exe Found: C:\cygwin\bin\perl.exe Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\sed.exe Found: C:\cygwin\bin\ssh.exe Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\tar.exe Found: C:\cygwin\bin\test.exe Not Found: vi Not Found: vim
15k 2009/12/27 C:\cygwin\bin\cygattr-1.dll 62k 2011/01/12 C:\cygwin\bin\cygbz2-1.dll 108k 2010/01/05 C:\cygwin\bin\cygcloog-0.dll 7k 2003/10/19 C:\cygwin\bin\cygcrypt-0.dll 1147k 2011/03/16 C:\cygwin\bin\cygcrypto-0.9.8.dll 284k 2010/06/01 C:\cygwin\bin\cygcurl-4.dll 943k 2007/12/17 C:\cygwin\bin\cygdb-4.5.dll 1296k 2007/12/17 C:\cygwin\bin\cygdb_cxx-4.5.dll 511k 2010/06/17 C:\cygwin\bin\cygedit-0.dll 118k 2008/05/09 C:\cygwin\bin\cygexpat-1.dll 22k 2011/03/22 C:\cygwin\bin\cygffi-4.dll 43k 2010/01/02 C:\cygwin\bin\cygform-10.dll 40k 2009/03/01 C:\cygwin\bin\cygform-8.dll 47k 2010/01/02 C:\cygwin\bin\cygformw-10.dll 44k 2011/03/22 C:\cygwin\bin\cyggcc_s-1.dll 19k 2009/02/26 C:\cygwin\bin\cyggdbm-4.dll 8k 2009/02/26 C:\cygwin\bin\cyggdbm_compat-4.dll 315k 2009/06/06 C:\cygwin\bin\cyggmp-3.dll 14k 2009/06/06 C:\cygwin\bin\cyggmpxx-4.dll 25k 2011/03/22 C:\cygwin\bin\cyggomp-1.dll 25k 2011/01/26 C:\cygwin\bin\cyghistory7.dll 360k 2010/08/15 C:\cygwin\bin\cygicons-0.dll 980k 2011/01/28 C:\cygwin\bin\cygiconv-2.dll 193k 2010/05/16 C:\cygwin\bin\cygidn-11.dll 31k 2005/11/20 C:\cygwin\bin\cygintl-3.dll 31k 2009/04/03 C:\cygwin\bin\cygintl-8.dll 5k 2011/03/29 C:\cygwin\bin\cyglsa.dll 9k 2011/03/29 C:\cygwin\bin\cyglsa64.dll 125k 2010/04/09 C:\cygwin\bin\cyglzma-1.dll 103k 2011/02/03 C:\cygwin\bin\cygmagic-1.dll 25k 2010/01/02 C:\cygwin\bin\cygmenu-10.dll 21k 2009/03/01 C:\cygwin\bin\cygmenu-8.dll 25k 2010/01/02 C:\cygwin\bin\cygmenuw-10.dll 211k 2009/06/06 C:\cygwin\bin\cygmp-3.dll 64k 2009/11/09 C:\cygwin\bin\cygmpc-1.dll 269k 2009/06/07 C:\cygwin\bin\cygmpfr-1.dll 63k 2010/01/02 C:\cygwin\bin\cygncurses++-10.dll 66k 2009/03/01 C:\cygwin\bin\cygncurses++-8.dll 63k 2010/01/02 C:\cygwin\bin\cygncurses++w-10.dll 195k 2010/01/02 C:\cygwin\bin\cygncurses-10.dll 237k 2009/03/01 C:\cygwin\bin\cygncurses-8.dll 244k 2010/01/02 C:\cygwin\bin\cygncursesw-10.dll 13k 2010/01/02 C:\cygwin\bin\cygpanel-10.dll 11k 2009/03/01 C:\cygwin\bin\cygpanel-8.dll 13k 2010/01/02 C:\cygwin\bin\cygpanelw-10.dll 224k 2010/06/15 C:\cygwin\bin\cygpcre-0.dll 10k 2010/06/15 C:\cygwin\bin\cygpcreposix-0.dll 1627k 2010/08/29 C:\cygwin\bin\cygperl5_10.dll 22k 2002/06/09 C:\cygwin\bin\cygpopt-0.dll 695k 2009/04/18 C:\cygwin\bin\cygppl-7.dll 2481k 2009/04/18 C:\cygwin\bin\cygppl_c-2.dll 18k 2009/04/18 C:\cygwin\bin\cygpwl-4.dll 164k 2011/01/26 C:\cygwin\bin\cygreadline7.dll 10k 2009/12/14 C:\cygwin\bin\cygsigsegv-2.dll 121k 2010/06/01 C:\cygwin\bin\cygssh2-1.dll 263k 2011/03/16 C:\cygwin\bin\cygssl-0.9.8.dll 8k 2011/03/22 C:\cygwin\bin\cygssp-0.dll 771k 2011/03/22 C:\cygwin\bin\cygstdc++-6.dll 48k 2010/01/02 C:\cygwin\bin\cygtic-10.dll 48k 2010/01/02 C:\cygwin\bin\cygticw-10.dll 28k 2010/03/28 C:\cygwin\bin\cygwrap-0.dll 76k 2010/08/01 C:\cygwin\bin\cygz.dll 2604k 2011/03/29 C:\cygwin\bin\cygwin1.dll Cygwin DLL version info: DLL version: 1.7.9 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 237 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Installations name: Installations Cygdrive default prefix: Build date: Shared id: cygwin1S5
No Cygwin services found.
Cygwin Package Information Package Version Status _update-info-dir 00958-1 OK alternatives 1.3.30c-10 OK base-cygwin 3.0-1 OK base-files 4.0-6 OK bash 4.1.10-4 OK bash-completion 1.3-1 OK binutils 2.20.51-2 OK bzip2 1.0.6-1 OK coreutils 8.10-1 OK cpio 2.11-1 OK crypt 1.1-1 OK csih 0.9.4-1 OK curl 7.20.1-1 OK cvs 1.12.13-10 OK cvsps 2.2b1-1 OK cygrunsrv 1.34-1 OK cygutils 1.4.4-1 OK cygwin 1.7.9-1 OK cygwin-doc 1.7-1 OK dash 0.5.6.1-2 OK diffutils 2.9-1 OK editrights 1.01-2 OK file 5.05-1 OK findutils 4.5.9-2 OK gawk 3.1.8-1 OK gcc-core 3.4.4-999 OK gcc-mingw-core 20050522-1 OK gcc4-core 4.3.4-4 OK gettext 0.17-11 OK git 1.7.4-1 OK git-completion 1.7.4-1 OK git-gui 1.7.4-1 OK gitk 1.7.4-1 OK grep 2.6.3-1 OK groff 1.20.1-2 OK gzip 1.4-1 OK ipc-utils 1.0-1 OK less 436-1 OK libattr1 2.4.43-1 OK libbz2_1 1.0.6-1 OK libcloog0 0.15.7-1 OK libcurl4 7.20.1-1 OK libdb4.5 4.5.20.2-2 OK libedit0 20090923-1 OK libexpat1 2.0.1-1 OK libffi4 4.3.4-4 OK libgcc1 4.3.4-4 OK libgdbm4 1.8.3-20 OK libgmp3 4.3.1-3 OK libgmpxx4 4.3.1-3 OK libgomp1 4.3.4-4 OK libiconv2 1.13.1-2 OK libidn11 1.18-1 OK libintl3 0.14.5-1 OK libintl8 0.17-11 OK liblzma1 4.999.9beta-11 OK libmpc1 0.8-1 OK libmpfr1 2.4.1-4 OK libncurses10 5.7-18 OK libncurses8 5.5-10 OK libncursesw10 5.7-18 OK libopenssl098 0.9.8r-2 OK libpcre0 8.02-1 OK libpopt0 1.6.4-4 OK libppl 0.10.2-1 OK libreadline7 6.1.2-2 OK libsigsegv2 2.8-1 OK libssh2_1 1.2.5-1 OK libssp0 4.3.4-4 OK libstdc++6 4.3.4-4 OK libwrap0 7.6-21 OK login 1.10-10 OK make 3.81-2 OK man 1.6f-1 OK mingw-runtime 3.18-1 OK openssh 5.8p1-1 OK patch 2.5.8-9 OK perl 5.10.1-5 OK perl-Error 0.17016-1 OK ping 1.0-1 OK rebase 3.0.1-1 OK rsync 3.0.7-1 OK run 1.1.13-1 OK sed 4.2.1-1 OK tar 1.25-1 OK tcltk 20080420-1 OK terminfo 5.7_20091114-14 OK terminfo0 5.5_20061104-12 OK texinfo 4.13-3 OK tzcode 2010j-1 OK unzip 6.0-10 OK w32api 3.17-2 OK wdiff 0.6.3-1 OK wget 1.12-1 OK which 2.20-2 OK whois 5.0.8-1 OK xz 4.999.9beta-11 OK zip 3.0-11 OK zlib 1.2.5-1 OK zlib-devel 1.2.5-1 OK zlib0 1.2.5-1 OK Use -h to see help about each section
p5pRT
commented
13 years ago From: Jan Dubois [mailto:jand@activestate.com] Looks like it isn't building with Cygwin for me at all:
$ git clone git://perl5.git.perl.org/perl.git perl $ cd perl $ ./Configure -des $ make
[...]
make[1]: *** No rule to make target `../../cygperl5_14_0.dll'\, needed by `../../ lib/auto/Cwd/Cwd.dll'. Stop. make[1]: Leaving directory `/cygdrive/c/home/Jan/perl/dist/Cwd' Unsuccessful make(dist/Cwd): code=512 at make_ext.pl line 463.
README.cygwin kind of leads me to expect that the above should have worked...
I have no better idea on why it fails\, other than clock skew.
My build was okay\, for both 5-13-11 and for latest git at http://perl5.git.perl.org/perl.git/snapshot/57f45d7ba6658ede12e3850ae36f93319790c957.tar.gz
Is the file cygperl5_14_0.dll created on your system?
for the record\, here is my cygwin version (I know\, it is a little bit old) :
Cygwin DLL version info: DLL version: 1.5.18 DLL epoch: 19 DLL bad signal mask: 19005 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 132 Shared data: 4 DLL identifier: cygwin1 Mount registry: 2 Cygnus registry name: Cygnus Solutions Cygwin registry name: Cygwin Program options name: Program Options Cygwin mount registry name: mounts v2 Cygdrive flags: cygdrive flags Cygdrive prefix: cygdrive prefix Cygdrive default prefix: Build date: Sat Jul 2 20:30:04 EDT 2005 Shared id: cygwin1S4
Cygwin DLL version info​: DLL version​: 1\.7\.9 DLL epoch​: 19 DLL old termios​: 5 DLL malloc env​: 28 Cygwin conv​: 181 API major​: 0 API minor​: 237 Shared data​: 5 DLL identifier​: cygwin1 Mount registry​: 3 Cygwin registry name​: Cygwin Program options name​: Program Options Installations name​: Installations Cygdrive default prefix​: Build date​: Shared id​: cygwin1S5
Best regards\, Vadim.
p5pRT
commented
13 years ago On Mon\, 04 Apr 2011\, Konovalov\, Vadim (Vadim)** CTR ** wrote:
From: Jan Dubois [mailto:jand@activestate.com] make[1]: *** No rule to make target `../../cygperl5_14_0.dll'\, needed by `../../ lib/auto/Cwd/Cwd.dll'. Stop. make[1]: Leaving directory `/cygdrive/c/home/Jan/perl/dist/Cwd' Unsuccessful make(dist/Cwd): code=512 at make_ext.pl line 463.
README.cygwin kind of leads me to expect that the above should have worked...
I have no better idea on why it fails\, other than clock skew.
I don't think it is clock skew.
My build was okay\, for both 5-13-11 and for latest git at http://perl5.git.perl.org/perl.git/snapshot/57f45d7ba6658ede12e3850ae36f93319790c957.tar.gz
Is the file cygperl5_14_0.dll created on your system?
No\, it is not created at all.
for the record\, here is my cygwin version (I know\, it is a little bit old) :
Cygwin DLL version info​: DLL version​: 1\.5\.18
My builds were running on a newly created VM with the latest Cygwin 1.7.x installed.
I've now tried to build using the "unsupported legacy version" 1.5 (on an old Win2000 VM that already had it installed)\, and the build does succeed\, but has additional test failures:
Failed 10 tests out of 2039\, 99.51% okay. ../cpan/ExtUtils-MakeMaker/t/MM_Cygwin.t ../cpan/Time-HiRes/t/HiRes.t ../ext/XS-APItest/t/call_checker.t ../lib/overload.t op/filetest.t op/magic.t op/taint.t op/utftaint.t porting/cmp_version.t re/substT.t
So given the general state of Cygwin support in blead I don't think it makes much sense to address this particular issue for the 5.14 release during code freeze; it is after all just one more failing test among others\, if the build does succeed at all.
I'll be happy to try to fix the call_checker.t failure once the overall support for building Perl on the current Cygwin is improved enough so that it actually builds.
Cheers\, -Jan
p5pRT
commented
13 years ago 2011/4/4 Jan Dubois \jand@​activestate\.com:
On Mon\, 04 Apr 2011\, Konovalov\, Vadim (Vadim)** CTR ** wrote:
From: Jan Dubois [mailto:jand@activestate.com] make[1]: *** No rule to make target `../../cygperl5_14_0.dll'\, needed by `../../ lib/auto/Cwd/Cwd.dll'. Stop. make[1]: Leaving directory `/cygdrive/c/home/Jan/perl/dist/Cwd' Unsuccessful make(dist/Cwd): code=512 at make_ext.pl line 463.
README.cygwin kind of leads me to expect that the above should have worked...
I have no better idea on why it fails\, other than clock skew.
I don't think it is clock skew.
My build was okay\, for both 5-13-11 and for latest git at http://perl5.git.perl.org/perl.git/snapshot/57f45d7ba6658ede12e3850ae36f93319790c957.tar.gz
Is the file cygperl5_14_0.dll created on your system?
No\, it is not created at all.
for the record\, here is my cygwin version (I know\, it is a little bit old) :
Cygwin DLL version info: DLL version: 1.5.18
My builds were running on a newly created VM with the latest Cygwin 1.7.x installed.
I've now tried to build using the "unsupported legacy version" 1.5 (on an old Win2000 VM that already had it installed)\, and the build does succeed\, but has additional test failures:
Failed 10 tests out of 2039\, 99.51% okay. ../cpan/ExtUtils-MakeMaker/t/MM_Cygwin.t ../cpan/Time-HiRes/t/HiRes.t ../ext/XS-APItest/t/call_checker.t ../lib/overload.t op/filetest.t op/magic.t op/taint.t op/utftaint.t porting/cmp_version.t re/substT.t
So given the general state of Cygwin support in blead I don't think it makes much sense to address this particular issue for the 5.14 release during code freeze; it is after all just one more failing test among others\, if the build does succeed at all.
I'll be happy to try to fix the call_checker.t failure once the overall support for building Perl on the current Cygwin is improved enough so that it actually builds.
The necessary fixes are still in my cygwin branch on github.com\, and will be the base for the upcoming cygwin package\, which is in testing right now. It's not so bad\, less errors and less patches needed since 5.10. -- Reini Urban
p5pRT
commented
13 years ago I'm removing this ticket as an RC blocker for 5.14 based on Jan's comments.
p5pRT
commented
13 years ago On Wed 6.Apr'11 at 13:05:10 +0200\, Reini Urban wrote:
The necessary fixes are still in my cygwin branch on github.com\, and will be the base for the upcoming cygwin package\, which is in testing right now. It's not so bad\, less errors and less patches needed since 5.10.
I'm glad it's "better" and sorry it's not yet "good" -- After 5.14\, what are the chances of you (or someone else) setting up a full-time cygwin smoker so we can watch the builds over time and catch when we introduce regressions or have outstanding fails to deal with? Since so few porters work on cygwin\, we need to do _something_ to make this a bit easier.
-jesse
p5pRT
commented
13 years ago From: Jesse Vincent [mailto:jesse@fsck.com] On Wed 6.Apr'11 at 13:05:10 +0200\, Reini Urban wrote:
The necessary fixes are still in my cygwin branch on github.com\, and will be the base for the upcoming cygwin package\, which is in testing right now. It's not so bad\, less errors and less patches needed since 5.10.
I'm glad it's "better" and sorry it's not yet "good" -- After 5.14\, what are the chances of you (or someone else) setting up a full-time cygwin smoker so we can watch the builds over time and catch when we introduce regressions or have outstanding fails to deal with? Since so few porters work on cygwin\, we need to do _something_ to make this a bit easier.
given that currently cygwin does not even build perl - at least some portions of Reini's patch should be applied.
I am fine with some failing tests\, but it will be very unlucky to be not able play with 5.14.0 on cygwin at all.
in this patch\, 'm' modifier looks strange n the lines: if ($linktype eq 'static' and $flags =~ /-DUSEIMPORTLIB/m) { $flags =~ s/-DUSEIMPORTLIB/-UUSEIMPORTLIB/m; }
but I believe it is some copy-paste from elsewhere.
Best regards\, Vadim.
p5pRT
commented
13 years ago On Mon\, Apr 11\, 2011 at 09:26:05AM +0200\, Konovalov\, Vadim (Vadim)** CTR ** wrote:
From: Jesse Vincent [mailto:jesse@fsck.com] On Wed 6.Apr'11 at 13:05:10 +0200\, Reini Urban wrote:
The necessary fixes are still in my cygwin branch on github.com\, and will be the base for the upcoming cygwin package\, which is in testing right now. It's not so bad\, less errors and less patches needed since 5.10.
I'm glad it's "better" and sorry it's not yet "good" -- After 5.14\, what are the chances of you (or someone else) setting up a full-time cygwin smoker so we can watch the builds over time and catch when we introduce regressions or have outstanding fails to deal with? Since so few porters work on cygwin\, we need to do _something_ to make this a bit easier.
given that currently cygwin does not even build perl - at least some portions of Reini's patch should be applied.
Hangon. We're getting conflicting information here. If Cygwin doesn't build *at all*\, how come no-one else is reporting this? Particularly Reini and Jerry. (and I think Jan\, who was tying it)
What is different about your Cygwin?
I am fine with some failing tests\, but it will be very unlucky to be not able play with 5.14.0 on cygwin at all.
in this patch\, 'm' modifier looks strange n the lines: if ($linktype eq 'static' and $flags =~ /-DUSEIMPORTLIB/m) { $flags =~ s/-DUSEIMPORTLIB/-UUSEIMPORTLIB/m; }
but I believe it is some copy-paste from elsewhere.
Aha. That code in that patch:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-08/msg00714.html
It's actually stalled on an (*acknowledged* - "sure") request for a clearer commit message:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-08/msg00719.html
Given that the original proposed commit message was this:
part1: support the standard cyg dll prefix\, which is e.g. needed for FFI's.
Ctypes and C::DynaLib use DynaLoader to find dlls.
part2: With -DUSEIMPORTLIB DynaLoader symbols link against the prefixed
symbol names for the .dll.a importlib\, but we need to link against the
symbols directly. We don't link Dynaloader against libperl.dll.a.
$ nm /usr/lib/perl5/5.13.4/i686-cygwin/CORE/libperl.dll.a|grep boot_DynaLoader
00000000 I __imp__boot_DynaLoader
00000000 T _boot_DynaLoader
$ nm /usr/lib/perl5/5.13.4/i686-cygwin/CORE/cygperl5_13_4.dll|grep boot_DynaLoader
54245944 T _boot_DynaLoader
$ g++-4 -o cygperl5_13_4.dll --shared -Wl\,--enable-auto-import -Wl\,--export-all-symbols -Wl\,--stack\,8388608 -Wl\,--enable-auto-image-base -L/usr/local/lib -fstack-protector -Wl\,--out-implib=libperl.dll.a -Wl\,--image-base\,0x52000000 op.o perl.o madly.o malloc.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o cygwin.o DynaLoader.o Win32CORE.o -ldl -lcrypt
Creating library file: libperl.dll.a
DynaLoader.o: In function `XS_DynaLoader_dl_undef_symbols':
/usr/src/perl/blead/buildnothreads/ext/DynaLoader/DynaLoader.c:346: undefined reference to `__imp__PL_stack_sp'
/usr/src/perl/blead/buildnothreads/ext/DynaLoader/DynaLoader.c:346: undefined reference to `__imp__PL_markstack_ptr'
/usr/src/perl/blead/buildnothreads/ext/DynaLoader/DynaLoader.c:346: undefined reference to `__imp__PL_stack_base'
DynaLoader.o: In function `XS_DynaLoader_dl_error':
which doesn't act as a clear summary of the intent to anyone unfamiliar with Cygwin's build system\, so isn't fit for purpose.
[Actually\, it looks like the original patch should be *two* patches each with half the commit message\, as they appear to do distinct different things to distinct different files]
Nicholas Clark
p5pRT
commented
13 years ago From: Nicholas Clark On Mon\, Apr 11\, 2011 at 09:26:05AM +0200\, Konovalov\, Vadim wrote:
From: Jesse Vincent [mailto:jesse@fsck.com] On Wed 6.Apr'11 at 13:05:10 +0200\, Reini Urban wrote:
The necessary fixes are still in my cygwin branch on github.com\, and will be the base for the upcoming cygwin package\, which is in testing right now. It's not so bad\, less errors and less patches needed since 5.10.
I'm glad it's "better" and sorry it's not yet "good" -- After 5.14\, what are the chances of you (or someone else) setting up a full-time cygwin smoker so we can watch the builds over time and catch when we introduce regressions or have outstanding fails to deal with? Since so few porters work on cygwin\, we need to do _something_ to make this a bit easier.
given that currently cygwin does not even build perl - at least some portions of Reini's patch should be applied.
Hangon. We're getting conflicting information here. If Cygwin doesn't build *at all*\, how come no-one else is reporting this? Particularly Reini and Jerry. (and I think Jan\, who was tying it)
I was able to build on cygwin\, Jan had unresolved external error in Cwd\, as seen in this particular thread.
What is different about your Cygwin?
My cygwin is older (1.5.x) Jan has newer one (1.7.x)
I am fine with some failing tests\, but it will be very unlucky to be not able play with 5.14.0 on cygwin at all.
in this patch\, 'm' modifier looks strange n the lines: if ($linktype eq 'static' and $flags =~ /-DUSEIMPORTLIB/m) { $flags =~ s/-DUSEIMPORTLIB/-UUSEIMPORTLIB/m; }
but I believe it is some copy-paste from elsewhere.
Aha. That code in that patch:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-08 /msg00714.html
It's actually stalled on an (*acknowledged* - "sure") request for a clearer commit message:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-08 /msg00719.html
Given that the original proposed commit message was this:
part1​: support the standard cyg dll prefix\, which is e\.g\.needed for FFI's. Ctypes and C::DynaLib use DynaLoader to find dlls.
part2​: With \-DUSEIMPORTLIB DynaLoader symbols linkagainst the prefixed symbol names for the .dll.a importlib\, but we need to link against the symbols directly. We don't link Dynaloader against libperl.dll.a.
$ nm/usr/lib/perl5/5.13.4/i686-cygwin/CORE/libperl.dll.a|grep boot_DynaLoader 00000000 I __imp__boot_DynaLoader 00000000 T _boot_DynaLoader
$ nm/usr/lib/perl5/5.13.4/i686-cygwin/CORE/cygperl5_13_4.dll|grep boot_DynaLoader 54245944 T _boot_DynaLoader
$ g\+\+\-4 \-o cygperl5\_13\_4\.dll \-\-shared-Wl\,--enable-auto-import -Wl\,--export-all-symbols -Wl\,--stack\,8388608 -Wl\,--enable-auto-image-base -L/usr/local/lib -fstack-protector -Wl\,--out-implib=libperl.dll.a -Wl\,--image-base\,0x52000000 op.o perl.o madly.o malloc.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o cygwin.o DynaLoader.o Win32CORE.o -ldl -lcrypt Creating library file: libperl.dll.a DynaLoader.o: In function `XS_DynaLoader_dl_undef_symbols':
/usr/src/perl/blead/buildnothreads/ext/DynaLoader/DynaLoader.c :346: undefined reference to `__imp__PL_stack_sp'
/usr/src/perl/blead/buildnothreads/ext/DynaLoader/DynaLoader.c :346: undefined reference to `__imp__PL_markstack_ptr'
/usr/src/perl/blead/buildnothreads/ext/DynaLoader/DynaLoader.c :346: undefined reference to `__imp__PL_stack_base' DynaLoader.o: In function `XS_DynaLoader_dl_error':
which doesn't act as a clear summary of the intent to anyone unfamiliar with Cygwin's build system\, so isn't fit for purpose.
[Actually\, it looks like the original patch should be *two* patches each with half the commit message\, as they appear to do distinct different things to distinct different files]
indeed\, Reini sent cumulative patch\, I believe.
Thanks for looking into this :)
Vadim.
p5pRT
commented
13 years ago On Mon\, Apr 11\, 2011 at 10:57:50AM +0200\, Konovalov\, Vadim (Vadim)** CTR ** wrote:
From: Nicholas Clark I was able to build on cygwin\, Jan had unresolved external error in Cwd\, as seen in this particular thread.
What is different about your Cygwin?
My cygwin is older (1.5.x) Jan has newer one (1.7.x)
I build ok on 1.7.x\, thought some tests fail or get stuck.
Tony
p5pRT
commented
13 years ago Jan Dubois wrote:
I have fixed this same issue for MSWin32 with commit ad6ab6c50\, and I suspect that the Cygwin side might be fixed by moving the change from win32/win32.h into perl.h: ... It needs confirmation from Jerry and/or Reini that this actually solves the problem
I can now confirm that this is the correct fix. Due to debugging the same problem for the Devel-CallChecker CPAN distro\, I have determined that Cygwin requires exactly the same treatment as Windows. That is\, PERL_CALLCONV must contain "__declspec(dllimport)" when declaring core functions outside the core\, but must not contain that when declaring them inside the core.
For the use of modules (such as D-CC) that export C functions\, it would be useful to have this logic available more openly. PERL_CALLCONV has the right specifiers for core functions\, but the right specifiers for a module's functions may be different (they're different when building the module itself). We should probably have something like:
#define PERL_BASE_CALLCONV EXTERN_C #define PERL_EXPORT_CALLCONV PERL_BASE_CALLCONV #if defined(WIN32) || defined(__CYGWIN__) # define PERL_IMPORT_CALLCONV PERL_BASE_CALLCONV __declspec(dllimport) #else # define PERL_IMPORT_CALLCONV PERL_BASE_CALLCONV #endif #ifdef PERL_CORE # define PERL_CALLCONV PERL_EXPORT_CALLCONV #else # define PERL_CALLCONV PERL_IMPORT_CALLCONV #endif
Adding PERL_{EX\,IM}PORT_CALLCONV to the API should\, of course\, wait until 5.15. For now\, I suggest just extending the current Windows logic to Cygwin.
-zefram
p5pRT
commented
13 years ago On Mon\, Apr 11\, 2011 at 12:02 PM\, Zefram \zefram@​fysh\.org wrote:
For the use of modules (such as D-CC) that export C functions\, it would be useful to have this logic available more openly. PERL_CALLCONV has the right specifiers for core functions\, but the right specifiers for a module's functions may be different (they're different when building the module itself).
There is already another option to do this: the FUNCLIST option in ExtUtils::MakeMaker. Module::Build currently doesn't support this but it could be added easily (ExtUtils::CBuilder already supports it\, M::B just isn't using it). Your option has the distinct advantage of working with C++ too though. Another option that should have been easy would be to make the compiler export all symbols much like on Unix\, but I've never gotten that to work properly.
Leon
p5pRT
commented
13 years ago Leon Timmermans wrote:
There is already another option to do this: the FUNCLIST option in ExtUtils::MakeMaker.
No\, that tackles a different aspect of the job. It needs to be used *as well as* __declspec(dllimport).
FUNCLIST is used when building a shared library\, to export symbols\, making it possible to refer to them from outside the library. On Unix\, all symbols that were external from the POV of individual .o files are visible from outside the shared object\, so FUNCLIST isn't needed.
__declspec(dllimport) is used when linking against a shared library\, and changes the manner in which a symbol from the shared library is used. Without it (on Windows)\, a thunk gets implicitly wrapped around the symbol\, so the symbol as seen on the importing side has a different value from the value seen within the shared library\, which is what causes the call_checker.t failure that we've seen. Adding this specifier suppresses the thunk\, making the linker use the symbol directly\, just like it does anyway on Unix.
Windows additionally has the complication\, over Unix\, of needing to refer to some version of the exporting shared library when linking importing code. On Cygwin it refers to the exporting shared library itself\, but on native Windows it needs a separate file that gets built and installed alongside the shared library. FUNCLIST wouldn't have a chance to make any difference if it were not for this aspect of Windows linking.
-zefram
p5pRT
commented
13 years ago On Mon\, Apr 11\, 2011 at 1:09 PM\, Zefram \zefram@​fysh\.org wrote:
No\, that tackles a different aspect of the job. It needs to be used *as well as* __declspec(dllimport).
I see. Linking on Windows continues to amaze me.
Leon
p5pRT
commented
13 years ago On Mon\, 11 Apr 2011 13:15:31 +0200\, Leon Timmermans \fawaka@​gmail\.com wrote:
On Mon\, Apr 11\, 2011 at 1:09 PM\, Zefram \zefram@​fysh\.org wrote:
No\, that tackles a different aspect of the job. It needs to be used *as well as* __declspec(dllimport).
I see. Linking on Windows continues to amaze me.
The MinGW linker will also link against dlls and generate output that seems valid. The last time i tried that though\, the result didn't manage to pass tests. I don't know if that means that linking against a dll is useless or needs extra massaging\, but it doesn't seem outright impossible.
-- With regards\, Christian Walde
p5pRT
commented
13 years ago On Mon\, 11 Apr 2011\, Tony Cook wrote:
On Mon\, Apr 11\, 2011 at 10:57:50AM +0200\, Konovalov\, Vadim (Vadim)** CTR ** wrote:
From: Nicholas Clark I was able to build on cygwin\, Jan had unresolved external error in Cwd\, as seen in this particular thread.
What is different about your Cygwin?
My cygwin is older (1.5.x)
I could build blead with 1.5.x\, although I got a bunch of test failures.
Jan has newer one (1.7.x)
I build ok on 1.7.x\, thought some tests fail or get stuck.
This one did not work for me at all\, with a fresh copy of a pristine WinXP VM that just had an install of the latest Cywin 1.7.x on it. It did not build the cygperl5_14_0.dll at all\, so I'm curious why it worked for you. Did you specify anything more to ./Configure than just -des?
Cheers\, -Jan
p5pRT
commented
13 years ago On Mon\, Apr 11\, 2011 at 10:34:19AM -0700\, Jan Dubois wrote:
On Mon\, 11 Apr 2011\, Tony Cook wrote:
On Mon\, Apr 11\, 2011 at 10:57:50AM +0200\, Konovalov\, Vadim (Vadim)** CTR ** wrote:
From: Nicholas Clark I was able to build on cygwin\, Jan had unresolved external error in Cwd\, as seen in this particular thread.
What is different about your Cygwin?
My cygwin is older (1.5.x)
I could build blead with 1.5.x\, although I got a bunch of test failures.
Jan has newer one (1.7.x)
I build ok on 1.7.x\, thought some tests fail or get stuck.
This one did not work for me at all\, with a fresh copy of a pristine WinXP VM that just had an install of the latest Cywin 1.7.x on it. It did not build the cygperl5_14_0.dll at all\, so I'm curious why it worked for you. Did you specify anything more to ./Configure than just -des?
Just -Dusedevel.
I've built blead with cygwin successfully on both Win7 and XP x64.
I started a smoker for cygwin last night\, but it gets stuck in tests too much to be useful.
But then\, my NetBSD smoker gets stuck occasionally too.
Tony
p5pRT
commented
13 years ago From: Tony Cook On Mon\, Apr 11\, 2011 at 10:34:19AM -0700\, Jan Dubois wrote:
On Mon\, 11 Apr 2011\, Tony Cook wrote:
On Mon\, Apr 11\, 2011 at 10:57:50AM +0200\, Konovalov\, Vadim wrote:
From: Nicholas Clark I was able to build on cygwin\, Jan had unresolved external error in Cwd\, as seen in this particular thread.
What is different about your Cygwin?
My cygwin is older (1.5.x)
I could build blead with 1.5.x\, although I got a bunch of test failures.
Jan has newer one (1.7.x)
Jan\, is your cygwin build any better?
I build ok on 1.7.x\, thought some tests fail or get stuck.
This one did not work for me at all\, with a fresh copy of a pristine WinXP VM that just had an install of the latest Cywin 1.7.x on it. It did not build the cygperl5_14_0.dll at all\, so I'm curious why it worked for you. Did you specify anything more to ./Configure than just -des?
Just -Dusedevel.
Could it be the GCC version that makes difference?
Reini told that after GCC upgrade he must declare all exportable symbols on cygwin\, thus unresolved symbol in "Cwd"?
mine is 3.4.4 $ gcc --version gcc (GCC) 3.4.4 (cygming special) (gdc 0.12\, using dmd 0.125)
Hmm... why its "ming"?
Still\,. simplest "hello.world.c" program is cygwin (not mingw) i.e. it generates for cygwin (otherwise it would not build at all)
D:\cygwin\home\vkonovalov>dumpbin /dependents a.exe Microsoft (R) COFF Binary File Dumper Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file a.exe
File Type: EXECUTABLE IMAGE
Image has the following dependencies:
cygwin1.dll KERNEL32.dll
Regards\, Vadim.
p5pRT
commented
13 years ago On Mon\, Apr 11\, 2011 at 10:34:19AM -0700\, Jan Dubois wrote:
This one did not work for me at all\, with a fresh copy of a pristine WinXP VM that just had an install of the latest Cywin 1.7.x on it. It did not build the cygperl5_14_0.dll at all\, so I'm curious why it worked for you. Did you specify anything more to ./Configure than just -des?
this one still bothers me\, as fresh cygwin does not build 5.13.11\, in some cases\, and the last bit known to me\, that some random piece of Reini patch should be applied to buld.
Are there any cygwin smoke?
I very much in favour to have cygwin supported\, otherwise it is a bad sign\, to say the least.
Just -Dusedevel.
Could it be the GCC version that makes difference?
Looks like there's no gcc 4.x.y for cygwin\, Reini\, what have been you talking about changing GCC versions?
Why they matter?
Regards\, Vadim.
p5pRT
commented
13 years ago On Sun 24.Apr'11 at 22:53:22 +0200\, Konovalov\, Vadim (Vadim)** CTR ** wrote:
this one still bothers me\, as fresh cygwin does not build 5.13.11\, in some cases\, and the last bit known to me\, that some random piece of Reini patch should be applied to buld.
Are there any cygwin smoke?
I'd really like too see regular cygwin smoking. I don't believe there is one now.
I very much in favour to have cygwin supported\, otherwise it is a bad sign\, to say the least.
It's too late for 5.14. I did work to apply everything from Reini's tree earlier in the 5.13 series and didn't hear anything about it not being enough until far too far into freeze.
I agree 100% that it's a bad sign for Perl on cygwin that there isn't enough communication about the state of things (and that people are getting differing results on the same cygwin configuration)
I'd love Perl to work great out of the box on every platform\, but we need active participation from porters for a given platform throughout the development cycle. I'd be thrilled to see a stream of patches for the cygwin port when we reopen 5.15. Depending on the patches\, they may even be reasonable for backporting to 5.14.
-Jesse
p5pRT
commented
13 years ago On Wed\, Apr 27\, 2011 at 03:40:34PM +0800\, Jesse Vincent wrote:
On Sun 24.Apr'11 at 22:53:22 +0200\, Konovalov\, Vadim (Vadim)** CTR ** wrote:
this one still bothers me\, as fresh cygwin does not build 5.13.11\, in some cases\, and the last bit known to me\, that some random piece of Reini patch should be applied to buld.
Are there any cygwin smoke?
I'd really like too see regular cygwin smoking. I don't believe there is one now.
I'm now smoking blead.
It tends to lock up in several tests though.
Tony
p5pRT
commented
13 years ago From: Tony Cook On Wed\, Apr 27\, 2011 at 03:40:34PM +0800\, Jesse Vincent wrote:
On Sun 24.Apr'11 at 22:53:22 +0200\, Konovalov\, Vadim wrote:
this one still bothers me\, as fresh cygwin does not build 5.13.11\, in some cases\, and the last bit known to me\, that some random piece of Reini patch should be applied to buld.
Are there any cygwin smoke?
I'd really like too see regular cygwin smoking. I don't believe there is one now.
I'm now smoking blead.
It tends to lock up in several tests though.
What version of Test::Smoke do you use?
Latest CPAN version seemingly fails\, please see https://rt.cpan.org/Ticket/Display.html?id=67786
Regards\, Vadim.
p5pRT
commented
13 years ago On Wed\, Apr 27\, 2011 at 12:57:29PM +0200\, Konovalov\, Vadim (Vadim)** CTR ** wrote:
From: Tony Cook On Wed\, Apr 27\, 2011 at 03:40:34PM +0800\, Jesse Vincent wrote:
On Sun 24.Apr'11 at 22:53:22 +0200\, Konovalov\, Vadim wrote:
this one still bothers me\, as fresh cygwin does not build 5.13.11\, in some cases\, and the last bit known to me\, that some random piece of Reini patch should be applied to buld.
Are there any cygwin smoke?
I'd really like too see regular cygwin smoking. I don't believe there is one now.
I'm now smoking blead.
It tends to lock up in several tests though.
What version of Test::Smoke do you use?
Latest CPAN version seemingly fails\, please see https://rt.cpan.org/Ticket/Display.html?id=67786
It works for me\, though I clean PATH to just /bin:/usr/bin.
eg.
http://perl.develop-help.com/raw/?id=26157
Tony
p5pRT
commented
13 years ago From: Tony Cook [mailto:tony@develop-help.com] On Wed\, Apr 27\, 2011 at 12:57:29PM +0200\, Konovalov\, Vadim wrote:
What version of Test::Smoke do you use?
Tony\, you use Test-Smoke-1-44 version?
Latest CPAN version seemingly fails\, please see https://rt.cpan.org/Ticket/Display.html?id=67786
It works for me\, though I clean PATH to just /bin:/usr/bin.
this does not help me either :( I have absolutely same errors with "clean" PATH
Now I suspect that I have broken one of gazillon CYGWIN commands\, but I do not know which exactly.
Regards\, Vadim.
p5pRT
commented
13 years ago On Wed\, Apr 27\, 2011 at 01:49:12PM +0200\, Konovalov\, Vadim (Vadim)** CTR ** wrote:
From: Tony Cook [mailto:tony@develop-help.com] On Wed\, Apr 27\, 2011 at 12:57:29PM +0200\, Konovalov\, Vadim wrote:
What version of Test::Smoke do you use?
Tony\, you use Test-Smoke-1-44 version?
Yes.
Tony
p5pRT
commented
13 years ago 2011/4/27 Tony Cook \tony@​develop\-help\.com:
On Wed\, Apr 27\, 2011 at 01:49:12PM +0200\, Konovalov\, Vadim (Vadim)** CTR ** wrote:
From: Tony Cook [mailto:tony@develop-help.com] On Wed\, Apr 27\, 2011 at 12:57:29PM +0200\, Konovalov\, Vadim wrote:
What version of Test::Smoke do you use?
Tony\, you use Test-Smoke-1-44 version?
Yes.
I used Test-Smoke before but got tired that new perls were not supported and git neither.
So I started with adding git support\, talked with the smoker guys\, but since then I heard nothing regarding git support.
$ ls -l smokecurrent.log -rw-rw-rw- 1 rurban users 51 Apr 25 02:10 smokecurrent.log
rurban@reini /usr/src/perl/.smoke $ cat smokecurrent.log Invalid sync_type 'git' at ./smokeperl.pl line 189 -- Reini Urban
p5pRT
commented
13 years ago On Wed\, Apr 27\, 2011 at 10:37:45PM +0200\, Reini Urban wrote:
I used Test-Smoke before but got tired that new perls were not supported and git neither.
I'm not sure what you mean here about new perls - I'm running it fine with the cygwin supplied perl.
So I started with adding git support\, talked with the smoker guys\, but since then I heard nothing regarding git support.
I have my own -- fairly crude -- wrapper that extracts the HEAD of a branch. It works over blead\, maint\, smoke-me/* and tests various configurations[1].
Tony
[1] when the platform is fast enough to support that
p5pRT
commented
13 years ago On Thu\, 28 Apr 2011\, Tony Cook wrote:
On Wed\, Apr 27\, 2011 at 10:37:45PM +0200\, Reini Urban wrote:
I used Test-Smoke before but got tired that new perls were not supported and git neither.
I'm not sure what you mean here about new perls - I'm running it fine with the cygwin supplied perl.
So I started with adding git support\, talked with the smoker guys\, but since then I heard nothing regarding git support.
I have my own -- fairly crude -- wrapper that extracts the HEAD of a branch. It works over blead\, maint\, smoke-me/* and tests various configurations[1].
My own git wrapper is https://github.com/greerga/smoke-me
For blead and maint I just change the regex of branches it looks for.
-- George Greer
p5pRT
commented
13 years ago On Wed\, 27 Apr 2011 22:37:45 +0200\, Reini Urban \rurban@​x\-ray\.at wrote:
2011/4/27 Tony Cook \tony@​develop\-help\.com:
On Wed\, Apr 27\, 2011 at 01:49:12PM +0200\, Konovalov\, Vadim (Vadim)** CTR ** wrote:
From: Tony Cook [mailto:tony@develop-help.com] On Wed\, Apr 27\, 2011 at 12:57:29PM +0200\, Konovalov\, Vadim wrote:
What version of Test::Smoke do you use?
Tony\, you use Test-Smoke-1-44 version?
Yes.
I used Test-Smoke before but got tired that new perls were not supported and git neither.
Test::Smoke is under construction at the moment. git support *is* available\, but rather underdocumented.
Right now\, that is however not our first goal. The maintainers of the mailing list have asked us to find/create a way to lower the traffic\, which is exactly what we are working on right now. The QA Hackathon got us in-line and the whole plan has been drawn. We're now coloring in the big picture. I have absolutely no idea about a release plan though.
Sorry for the silence.
So I started with adding git support\, talked with the smoker guys\, but since then I heard nothing regarding git support.
$ ls -l smokecurrent.log -rw-rw-rw- 1 rurban users 51 Apr 25 02:10 smokecurrent.log
rurban@reini /usr/src/perl/.smoke $ cat smokecurrent.log Invalid sync_type 'git' at ./smokeperl.pl line 189
-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20\, 11.00\, 11.11\, 11.23 and 11.31\, OpenSuSE 10.1\, 11.0 .. 11.3 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
p5pRT
commented
12 years ago On Mon Apr 11 03:02:36 2011\, zefram@fysh.org wrote:
For the use of modules (such as D-CC) that export C functions\, it would be useful to have this logic available more openly. PERL_CALLCONV has the right specifiers for core functions\, but the right specifiers for a module's functions may be different (they're different when building the module itself). We should probably have something like:
\#define PERL\_BASE\_CALLCONV EXTERN\_C \#define PERL\_EXPORT\_CALLCONV PERL\_BASE\_CALLCONV \#if defined\(WIN32\) || defined\(\_\_CYGWIN\_\_\) \# define PERL\_IMPORT\_CALLCONV PERL\_BASE\_CALLCONV \_\_declspec\(dllimport\) \#else \# define PERL\_IMPORT\_CALLCONV PERL\_BASE\_CALLCONV \#endif \#ifdef PERL\_CORE \# define PERL\_CALLCONV PERL\_EXPORT\_CALLCONV \#else \# define PERL\_CALLCONV PERL\_IMPORT\_CALLCONV \#endifAdding PERL_{EX\,IM}PORT_CALLCONV to the API should\, of course\, wait until 5.15. For now\, I suggest just extending the current Windows logic to Cygwin.
I tried the following change:
This failed linking perl itself in Dynaloader, since it sees __declspec(dllimport) but isn't provided the appropriate __imp__Foo symbols for perl APIs. I'd expect similar failures linking any other extension statically.
I modified sub cflags in EU::MM_Unix to add a -DPERL_STATIC_EXT define when building a static extension\, and modified the final conditional above to check for PERL_STATIC_EXT as well as PERL_CORE.
This time it failed linking the re extension\, since Perl_regprop aka my_regprop is declared as dllimport\, but isn't an import to the the other objects linked into re.dll. I fiddled with this a bit (removing E from the entry in embed.fnc to start) but haven't managed to get it to work yet.
Tony
p5pRT
commented
10 years ago On Thu Oct 21 09:34:14 2010\, jdhedden@cpan.org wrote:
'make test' produces the following in blead under Cygwin on Windows:
ext/XS-APItest/t/call_checker..................................fail at APItest.xs line 1763 at t/call_checker.t line 7. # Looks like your test exited with 255 before it could output anything. FAILED--expected 64 tests\, saw 0
I've made this test TODO on cygwin to make new failures more visible\, the test is no longer failing\, but this is still an issue.
Tony
Migrated from rt.perl.org#78502 (status was 'open')
Searchable as RT78502$