NAVIGATION
CATEGORIES
REFERRENCE
LINKS
Smoke 28115 FAIL(M) MSWin32 WinXP/.Net SP2 (x86/2 cpu)
5 answers - 2362 bytes -
Automated smoke report for 5.8.8 patch 28115
Mugwump.uk.radan.com: Intel(R) Pentium(R) 4 CPU 3.40GHz(~3391 MHz) (x86/2 cpu)
on MSWin32 - WinXP/.Net SP2
using cl version 13.10.3077
smoketime 34 minutes 7 seconds (average 1 minute 42.350 seconds)
Summary: FAIL(M)
= K F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during: - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep
28115 Configuration (common) -DCCTYPE=MSVC70FREE -DINST_TP=$(INST_DRV)\Smoke\doesntexist
M M
M M -Dusemymalloc
M M -Duselargefiles
M M -Duselargefiles -Dusemymalloc
M M -Duseithreads -Uuseimpsys
M M -Duseithreads -Uuseimpsys -Dusemymalloc
M M -Duseithreads -Uuseimpsys -Duselargefiles
M M -Duseithreads -Uuseimpsys -Duselargefiles -Dusemymalloc
M M -Duseithreads
M M -Duseithreads -Duselargefiles
| + -DDEBUGGING
+ no debugging
Locally applied patches:
MAINT27284
SMKE28115
Compiler messages(MSWin32):
\pp_pack.c(653) : warning C4244: 'return' : conversion from 'UV' to 'U8', possible loss of data
\pp_pack.c(680) : warning C4244: '=' : conversion from 'UV' to 'U8', possible loss of data
\regcomp.c(1066) : warning C4244: '=' : conversion from 'I32' to 'U8', possible loss of data
\toke.c(9416) : warning C4244: '=' : conversion from 'I32' to 'U8', possible loss of data
LINK : warning LNK4089: all references to 'SHELL32.dll' discarded by /PT:REF
perldll.def(2) : warning LNK4017: DESCRIPTIN statement not supported for the target platform; ignored
perldll.def : error LNK2001: unresolved external symbol Perl_csighandler_va
\perl58.lib : fatal error LNK1120: 1 unresolved externals
LINK : fatal error LNK1141: failure during build of exports file
perldll.def(2) : warning LNK4017: DESCRIPTIN statement not supported for the target platform; ignored
perldll.def : error LNK2001: unresolved external symbol Perl_csighandler_va
\perl58.lib : fatal error LNK1120: 1 unresolved externals
LINK : fatal error LNK1141: failure during build of exports fileNo.1 | | 2167 bytes |
| 
Nicholas Clark wrote:
Sun, May 07, 2006 at 07:04:00PM +0100, Steve Hay wrote:
>perldll.def(2) : warning LNK4017: DESCRIPTIN statement not supported for the target platform; ignored
>perldll.def : error LNK2001: unresolved external symbol Perl_csighandler_va
>\perl58.lib : fatal error LNK1120: 1 unresolved externals
Does this mean that both HAS_SIGACTIN and SA_SIGINF need to be in the
output of perl -V, so that makedef.pl can read them and thereby figure out
what the correct export list is?
I don't think so: blead's perl -V doesn't list it and that works fine.
As of change #28115, maint has this in embed.fnc:
#if defined(HAS_SIGACTIN) && defined(SA_SIGINF)
nop|Signal_t |sighandler_va|int sig|
Anop|Signal_t |csighandler_va|int sig|
#endif
nop|Signal_t |sighandler|int sig
Anop|Signal_t |csighandler|int sig
whereas blead has:
#if defined(HAS_SIGACTIN) && defined(SA_SIGINF)
np|Signal_t |sighandler|int sig|
Anp|Signal_t |csighandler|int sig|
#else
np|Signal_t |sighandler|int sig
Anp|Signal_t |csighandler|int sig
#endif
It this difference intentional? Where did the [c]sighandler_va's in
maint come from? That's the symbol that the linker is complaining
about, but I don't see it mentioned in any of the changes that #28115
says it was integrating.
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.No.2 | | 529 bytes |
| Sun, May 07, 2006 at 07:04:00PM +0100, Steve Hay wrote:
perldll.def(2) : warning LNK4017: DESCRIPTIN statement not supported for the target platform; ignored
perldll.def : error LNK2001: unresolved external symbol Perl_csighandler_va
\perl58.lib : fatal error LNK1120: 1 unresolved externals
Does this mean that both HAS_SIGACTIN and SA_SIGINF need to be in the
output of perl -V, so that makedef.pl can read them and thereby figure out
what the correct export list is?
Nicholas ClarkNo.3 | | 1469 bytes |
| Mon, May 08, 2006 at 09:48:58AM +0100, Steve Hay wrote:
I don't think so: blead's perl -V doesn't list it and that works fine.
But (as described below) maint is different.
As of change #28115, maint has this in embed.fnc:
#if defined(HAS_SIGACTIN) && defined(SA_SIGINF)
nop|Signal_t |sighandler_va|int sig|
Anop|Signal_t |csighandler_va|int sig|
#endif
nop|Signal_t |sighandler|int sig
Anop|Signal_t |csighandler|int sig
whereas blead has:
#if defined(HAS_SIGACTIN) && defined(SA_SIGINF)
np|Signal_t |sighandler|int sig|
Anp|Signal_t |csighandler|int sig|
#else
np|Signal_t |sighandler|int sig
Anp|Signal_t |csighandler|int sig
#endif
It this difference intentional? Where did the [c]sighandler_va's in
Yes
maint come from? That's the symbol that the linker is complaining
Me
about, but I don't see it mentioned in any of the changes that #28115
says it was integrating.
I made the change because I didn't want to change the prototype of sighandler
or csighandler. I don't trust someone out in the big wide stupid world to
futzed their system so that they have C++ mangling of our prototypes, lazy
dynamic linking (the default with at least dl_open), and then install a new
perl binary (without complete testing) which fails at run time when it can't
find
Nicholas ClarkNo.4 | | 2355 bytes |
| Nicholas Clark wrote:
Mon, May 08, 2006 at 09:48:58AM +0100, Steve Hay wrote:
>I don't think so: blead's perl -V doesn't list it and that works fine.
But (as described below) maint is different.
Ah, K. I think makedef.pl can be made to skip Perl_csighandler_va
without the need for any changes to perl -V.
Gisle previously (and quite rightly) objected to things being listed
there when they weren't really compile-time options:
The solution on that occasion was to skip the symbol based on the
platform (Win32), since it's necessity or otherwise was determined by
the platform:
If we go down that road then the attached patch1 does the trick for
Win32, but I'm not sure how many other platforms would need a similar trick.
If many more platforms are affected then perhaps something like patch2
is better? The only thing that worries me there is that
Perl_csighandler_va is defined or otherwise based on the definedness of
HAS_SIGACTIN and SA_SIGINF, but the makedef.pl change is only
considering d_sigaction. Is that good enough?
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
//#32 - c:\p5p\maintperl\makedef.pl
@@ -287,6 +287,7 @@
Perl_my_pclose
Perl_my_popen
Perl_my_sprintf
+ Perl_csighandler_va
)];
}
else {
//#32 - c:\p5p\maintperl\makedef.pl
@@ -797,6 +797,12 @@
)];
}
+unless ($define{'d_sigaction'}) {
+ skip_symbols [qw(
+ Perl_csighandler_va
+ )];
+}
+
sub readvar {
my $file = shift;
my $proc = shift || sub { "PL_$_[2]" };No.5 | | 667 bytes |
| Mon, May 08, 2006 at 12:35:09PM +0100, Steve Hay wrote:
If many more platforms are affected then perhaps something like patch2
is better? The only thing that worries me there is that
Perl_csighandler_va is defined or otherwise based on the definedness of
HAS_SIGACTIN and SA_SIGINF, but the makedef.pl change is only
considering d_sigaction. Is that good enough?
I don't know if it's good enough, but it seemed slightly more robust so I
applied it as change 28120. I guess it only matters if one of the few
platforms that needs makedef.pl also HAS_SIGACTIN but doesn't have
SA_SIGINF
Nicholas Clark
QUESTION ON "Perl"
- Support for inside-out classes
- RFC: Community Education Page
- Change 28116: Remvove code that get's undone in the next line.
- Net::LDAP
- Smoke 28108 FAIL(XM) MSWin32 WinXP/.Net SP2 (x86/2 cpu)
- skip() from test.pl causes 'fold_constants JMPENV_PUSH' in __WARN__ handler
- Perl is not as flexibile at allowing people to select vendor install paths as it should be
- Linux alternative for Win32 module
- Support for inside-out classes
- Change 28115: Integrate:
- hash confusion
- generate list in increments of 10's
- using the newer collection types - Interval
- CAP::Plugin::FormState and C::A::Dispatch ?
- UNIX commands: chmod
- libparrot.so.0.4.2
- recursion now removed from the regex engine
- Announce: Template::Plugin::Gravatar (Feedback, code review, comments)
- early draft of I/O PDD
- What is wrong with this file copy script