Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ext/XS-APItest/t/call_checker.t fails under Cygwin #10750

Open
p5pRT opened this issue Oct 21, 2010 · 42 comments
Open

ext/XS-APItest/t/call_checker.t fails under Cygwin #10750

p5pRT opened this issue Oct 21, 2010 · 42 comments

Comments

@p5pRT
Copy link

p5pRT commented Oct 21, 2010

Migrated from rt.perl.org#78502 (status was 'open')

Searchable as RT78502$

@p5pRT
Copy link
Author

p5pRT commented Oct 21, 2010

From @jdhedden

Created by @jdhedden

'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

Perl Info

Flags:
    category=core
    severity=high

Site configuration information for perl 5.13.6:

Configured by Jerry at Thu Oct 21 08:55:28 EDT 2010.

Summary of my perl5 (revision 5 version 13 subversion 6 patch 43246)
configuration:
  Snapshot of: 5bc1001b08a9ab20cf55683d2a0b5f53d4ad2c2b
  Platform:
    osname=cygwin, osvers=1.5.25(0.15642), archname=cygwin-thread-multi-64int
    uname='cygwin_nt-5.1 pn100-02-2-364p 1.5.25(0.15642) 2008-06-12
19:34 i686 cygwin '
    config_args='-de -Dusedevel -Dversiononly=no -Dinstallusrbinperl
-Uusemallocwrap -Duse64bitint -Dusethreads -Dinc_version_list=none
-Dnoextensions=IPC/SysV Sys/Syslog Devel/DProf Devel/Peek re GDBM_File
NDBM_File ODBM_File Text/Soundex Math/BigInt/FastCalc Time/Piece -A
append:ccflags= -DNO_MATHOMS  -A define:optimize=-Os -pipe
-funit-at-a-time -march=pentium4 -mfpmath=sse -mieee-fp -mmmx -msse
-msse2'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=undef, uselongdouble=undef
    usemymalloc=y, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__
-DNO_MATHOMS -fno-strict-aliasing -pipe',
    optimize='-Os -pipe -funit-at-a-time -march=pentium4 -mfpmath=sse
-mieee-fp -mmmx -msse -msse2',
    cppflags='-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -DNO_MATHOMS
-fno-strict-aliasing -pipe'
    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', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='g++', ldflags =' -Wl,--enable-auto-import
-Wl,--export-all-symbols -Wl,--stack,8388608
-Wl,--enable-auto-image-base -s -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib /lib
    libs=-lgdbm -ldl -lcrypt -lgdbm_compat
    perllibs=-ldl -lcrypt
    libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=cygperl5_13_6.dll
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s'
    cccdlflags=' ', lddlflags=' --shared  -Wl,--enable-auto-import
-Wl,--export-all-symbols -Wl,--stack,8388608
-Wl,--enable-auto-image-base -s -L/usr/local/lib'

Locally applied patches:



@INC for perl 5.13.6:
    /usr/lib/perl5/site_perl/5.13.6/cygwin
    /usr/lib/perl5/site_perl/5.13.6
    /usr/lib/perl5/5.13.6/cygwin
    /usr/lib/perl5/5.13.6
    .


Environment for perl 5.13.6:
    CYGWIN=ntsec
    HOME=/home/jhedden
    LANG=C
    LANGUAGE=C
    LC_ALL=C
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/jhedden/bin:/usr/local/src/perl/bin:/link/work/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/c/Program
Files/WiX:/c/djgpp/bin:/c/bb/tools/apache-ant-1.6.5/bin:/c/Program
Files/nant-0.85/bin:/c/bb/tools/jse5/bin:/c/dev-cpp/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/system32/WBEM:/c/blp/API/dde:/c/blp/API:/c/oracle/ora92/bin:/c/Program
Files/Oracle/jre/1.3.1/bin:/c/Program
Files/Oracle/jre/1.1.8/bin:/c/Program
Files/Hummingbird/Connectivity/7.10/Accessories:/usr/bin:/c/Program
Files/Windows Imaging/:/c/Program Files/Citrix/ICAService/:/c/Program
Files/Citrix/System32/:.
    PERLIO=perlio
    PERL_BADLANG (unset)
    SHELL (unset)

@p5pRT
Copy link
Author

p5pRT commented Mar 30, 2011

From @iabyn

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
Copy link
Author

p5pRT commented Mar 30, 2011

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Apr 1, 2011

From @jdhedden

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
Copy link
Author

p5pRT commented Apr 1, 2011

From zefram@fysh.org

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
Copy link
Author

p5pRT commented Apr 2, 2011

From @jandubois

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 ad6ab6c,
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
Copy link
Author

p5pRT commented Apr 2, 2011

From @obra

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 ad6ab6c,
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
Copy link
Author

p5pRT commented Apr 2, 2011

From @rurban

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 ad6ab6c,
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
Copy link
Author

p5pRT commented Apr 2, 2011

From @jdhedden

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 ad6ab6c,
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
Copy link
Author

p5pRT commented Apr 3, 2011

From zefram@fysh.org

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
Copy link
Author

p5pRT commented Apr 4, 2011

From @jandubois

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
Copy link
Author

p5pRT commented Apr 4, 2011

From @jandubois

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
Copy link
Author

p5pRT commented Apr 4, 2011

From vadim.konovalov@alcatel-lucent.com

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&#8203;:
    DLL version&#8203;: 1\.7\.9
    DLL epoch&#8203;: 19
    DLL old termios&#8203;: 5
    DLL malloc env&#8203;: 28
    Cygwin conv&#8203;: 181
    API major&#8203;: 0
    API minor&#8203;: 237
    Shared data&#8203;: 5
    DLL identifier&#8203;: cygwin1
    Mount registry&#8203;: 3
    Cygwin registry name&#8203;: Cygwin
    Program options name&#8203;: Program Options
    Installations name&#8203;: Installations
    Cygdrive default prefix&#8203;:
    Build date&#8203;:
    Shared id&#8203;: cygwin1S5

Best regards,
Vadim.

@p5pRT
Copy link
Author

p5pRT commented Apr 4, 2011

From @jandubois

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&#8203;:
    DLL version&#8203;: 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
Copy link
Author

p5pRT commented Apr 6, 2011

From @rurban

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
Copy link
Author

p5pRT commented Apr 6, 2011

From @obra

I'm removing this ticket as an RC blocker for 5.14 based on Jan's comments.

@p5pRT
Copy link
Author

p5pRT commented Apr 11, 2011

From @obra

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
Copy link
Author

p5pRT commented Apr 11, 2011

From vadim.konovalov@alcatel-lucent.com

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
Copy link
Author

p5pRT commented Apr 11, 2011

From @nwc10

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
Copy link
Author

p5pRT commented Apr 11, 2011

From vadim.konovalov@alcatel-lucent.com

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&#8203;: support the standard cyg dll prefix\, which is e\.g\. 

needed for FFI's.
Ctypes and C​::DynaLib use DynaLoader to find dlls.

part2&#8203;: 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]

indeed, Reini sent cumulative patch, I believe.

Thanks for looking into this :)

Vadim.

@p5pRT
Copy link
Author

p5pRT commented Apr 11, 2011

From @tonycoz

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
Copy link
Author

p5pRT commented Apr 11, 2011

From zefram@fysh.org

Jan Dubois wrote​:

I have fixed this same issue for MSWin32 with commit ad6ab6c,
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
Copy link
Author

p5pRT commented Apr 11, 2011

From @Leont

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
Copy link
Author

p5pRT commented Apr 11, 2011

From zefram@fysh.org

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
Copy link
Author

p5pRT commented Apr 11, 2011

From @Leont

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
Copy link
Author

p5pRT commented Apr 11, 2011

From @wchristian

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
Copy link
Author

p5pRT commented Apr 11, 2011

From @jandubois

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
Copy link
Author

p5pRT commented Apr 11, 2011

From @tonycoz

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
Copy link
Author

p5pRT commented Apr 21, 2011

From vadim.konovalov@alcatel-lucent.com

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
Copy link
Author

p5pRT commented Apr 24, 2011

From vadim.konovalov@alcatel-lucent.com

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
Copy link
Author

p5pRT commented Apr 27, 2011

From @obra

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
Copy link
Author

p5pRT commented Apr 27, 2011

From @tonycoz

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
Copy link
Author

p5pRT commented Apr 27, 2011

From vadim.konovalov@alcatel-lucent.com

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
Copy link
Author

p5pRT commented Apr 27, 2011

From @tonycoz

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
Copy link
Author

p5pRT commented Apr 27, 2011

From vadim.konovalov@alcatel-lucent.com

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
Copy link
Author

p5pRT commented Apr 27, 2011

From @tonycoz

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
Copy link
Author

p5pRT commented Apr 27, 2011

From @rurban

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
Copy link
Author

p5pRT commented Apr 28, 2011

From @tonycoz

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
Copy link
Author

p5pRT commented Apr 28, 2011

From @greerga

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
Copy link
Author

p5pRT commented Apr 28, 2011

From @Tux

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
Copy link
Author

p5pRT commented Jun 2, 2012

From @tonycoz

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
\#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.

I tried the following change​:

Inline Patch
diff --git a/perl.h b/perl.h
index 798e7b7..ba9f540 100644
--- a/perl.h
+++ b/perl.h
@@ -5019,15 +5019,26 @@ struct tempsym; /* defined in pp_pack.c */

 #ifndef PERL_CALLCONV
 #  ifdef __cplusplus
-#    define PERL_CALLCONV extern "C"
+#    define PERL_BASE_CALLCONV extern "C"
 #  else
-#    define PERL_CALLCONV
+#    define PERL_BASE_CALLCONV
 #  endif
+#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
 #undef PERL_CKDEF
 #undef PERL_PPDEF
 #define PERL_CKDEF(s)  PERL_CALLCONV OP *s (pTHX_ OP *o);
 #define PERL_PPDEF(s)  PERL_CALLCONV OP *s (pTHX);
+#if defined(PERL_CORE)
+# define PERL_CALLCONV PERL_EXPORT_CALLCONV
+#else
+# define PERL_CALLCONV PERL_IMPORT_CALLCONV
+#endif
+#endif

 #ifdef MYMALLOC
 #  include "malloc_ctl.h"

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
Copy link
Author

p5pRT commented Oct 23, 2014

From @tonycoz

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants