Bug #77575 for Prima: Win32, my 64bit perls no longer build auto/Prima/Prima.a

Hi Rob, I vaguely remember that the problem was on a setup where ccname was not gcc but gcc-4 (out of box), and gcc-4 did the linking by itself, without the dlltool. I can't remember now whether that was because of gcc was version 3 or because the platform itself was special no matter gcc-3 or gcc-4. The problem with dlltool is that its use is kind of ad-hoc ... can I reproduce your bug by installing a fresh perl (what distro it is?) or possibly adding a hack to Makefile.PL DLLTOOL=1 or something similar would help? If you have any ideas how I can reproduce that it would be great. /dk

Hi Dmitry, Show quoted text
I've never heard of a gcc-3 or gcc-4 ccname for windows. What weird build is this ? It sounds a bit like Cygwin. They now have a gcc-3, so named to distinguish itself from version 4 of gcc (which, I think, is still called 'gcc', not 'gcc-4'). Would it keep everybody happy if the condition was changed to: $win32_use_dlltool = $Config{dlltool} || 'dlltool' if (($Config{ccname} =~ /\bgcc/) && ($Config{ccname} !~ /gcc\-/)); That would satisfy both myself and Strawberry Perl ... and would also satisfy that strange compiler (if I've understood correctly). Show quoted text
Once you get the "right" compiler it's just a matter of building perl from source in the usual way. My compiler comes from mingw64.sf - the same vendor that provides Strawberry Perl's x86 and x64 compiler. Unlike the SP x64 compiler, all of the executables on mine are prefixed with 'x86_x64-w64-mingw32-'. Any of the "mingw-w64-bin_i686-mingw_xxxxxxxx.zip" builds at http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/ are probably such a compiler. (Or are they 32-bit compilers ? ... to me, it's always been a bit of a mystery downloading from there, which is one reason that I don't do it very often.) I think (not sure) that the builds at the following link also use the 'x86_x64-w64-mingw32-' prefix: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/release/ Show quoted text
I'm not greatly fussed whether it gets fixed or not - I already have to patch win32/files.c anyway. The main thing from my point of view is that either it remains permanently fixed, or permanently broken. Having it alternate between fixed and broken is the one thing I really would like to avoid. I'll patch my Prima build script to verify that Prima.a gets created in blib/arch/auto/Prima. That way, if it fails to get created, I find out about it straight away .... not 3 hours later ;-) Cheers, Rob

On Fri Jun 01 05:38:43 2012, KARASIK wrote: Show quoted text
I'm interested to learn the details of any perls that break when you use "\bgcc". Just the 'perl -V' should do ... which reminds me that I should at least give you the 'perl -V' of one of my x64 builds. The following is for perl-5.12.0: ###################################### C:\_64>perl -V Summary of my perl5 (revision 5 version 12 subversion 0) configuration: Platform: osname=MSWin32, osvers=6.0, archname=MSWin32-x64-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='x86_64-w64-mingw32-gcc', ccflags =' -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DW IN64 -DCONSERVATIVE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -DPERL_MSVCRT_READFIX', optimize='-s -O2', cppflags='-DWIN32' ccversion='', gccversion='4.7.0', gccosandvers='' intsize=4, longsize=4, ptrsize=8, 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='long long', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='x86_64-w64-mingw32-g++', ldflags ='-s -L"c:\_64\perl512_470\lib\CORE" -L"C:\_64\alt\lib"' libpth=C:\_64\alt\mingw\lib C:\_64\msys\1.0\local_470\lib C:\_64\gsl_dyn_470\lib libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 libc=, so=dll, useshrplib=true, libperl=libperl512.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-mdll -s -L"c:\_64\perl512_470\lib\CORE" -L"C:\_64\alt\lib"' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PL_OP_SLAB_ALLOC USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF Built under MSWin32 Compiled at Apr 29 2011 19:46:04 @INC: C:/_64/perl512_470/site/lib C:/_64/perl512_470/lib . ###################################### Show quoted text
No rush ... whenever you get to it is fine :-) Cheers, Rob

On Sat Jun 02 08:08:45 2012, KARASIK wrote: Show quoted text
I thought it was in the Prima-1.33 Makefile.PL, but I see that I was mistaken. It must have been a change that *I* made to the 1.33 Makefile.PL (and failed to record the fact). I do apologize. Show quoted text
The thing is, that the following files in the perl source all decree that ccname should be whatever cc is: win32\config.gc win32\config.gc64 win32\config.gc64nox Perhaps this is an error in the perl sources ? If one uses ActivePerl with MinGW, one then finds that $Config{cc} becomes the full path to gcc.exe ... eg something like: C:/MINGW_~1/I686-P~1/bin/gcc.exe Yet, with ActivePerl, ccname then reports simply 'gcc'. I gather this is more like the behaviour that you expect - that is, irrespective of what $Config{cc} calls the gcc compiler, $Config{ccname} ahould always call it simply 'gcc' ? If that's the way it should be done, then we need to fix the perl source. (I'll ask about this on p5p.) As regards usage of "\bgcc", it's something that's not uncommon - mostly (if not exclusively) it's used in relation to $Config{cc}. You'll find it in such places as, eg: ExtUtils/MM_Win32.pm ExtUtils/Liblist/Kid.pm ExtUtils/Depends.pm (version 0.304) In the perl source you'll also find it in win32/config_sh.pl. Note that in many of these instances it's written as the more restrictive \bgcc\b. Cheers, Rob

On Sun Jun 03 04:39:25 2012, KARASIK wrote: Show quoted text
Are you sure ? I was actually getting quite ready to accept that it should be 'gcc' ... otherwise we're left wondering what purpose 'ccname' serves. (I didn't ask about this on p5p yet.) Show quoted text
Yep - works fine. As I've mentioned before, in win32/files.c, I have to replace #include <winsock.h> with #include <winsock2.h> #include <mswsock.h> My 64-bit mingw64.sf compiler doesn't care one way or the other - and I think the 32-bit mingw64.sf compiler would also not care. It's just the 32-bit mingw.org compiler (which built all of my 32-bit perls) that insists on this change. Other than that, commit 0985c1b is fine for all of the Windows perls I tried: 5.8.0 (32 bit only) 5.8.9 (32 bit only) 5.10.0 (32 bit and 64 bit) 5.12.0 (32 bit and 64 bit) 5.14.0 (32 bit and 64 bit) 5.16.0 (32 bit -Uuse64bitint, 32 bit -Duse64bitint, and 64 bit) Cheers, Rob