Why would anyone be smoking with their compiler not set up?
Martin J. Evans
http://www.nntp.perl.org/group/perl.cpan.testers/2009/01/msg3090019.html
but it looks as if the C compiler is not set up properly. Why would
anyone be smoking and attempting to build XS modules without their C
compiler being set up. May be this is some other issue. Any ideas?
Martin
David Golden
ActiveState Perl setup. Why smoke without a compiler? To show what happens
when distros on CPAN get tested without one. (Which could happen for normal
users unknowingly via dependencies, which is one of the reasons that Perl
without a compiler makes CPAN nearly unusable and one of the reasons that
drove the creationof Strawberry Perl.)
In this case, the "UNKNOWN" result is correct (in the new definition of
it). The build failed and tests could not be run, thus the result of tests
is unknown. Your error message is very descriptive -- I think it's perhaps
the best Makefile.PL error message I've ever seen.
-- David
On Mon, Jan 19, 2009 at 4:51 AM, Martin J. Evans
<martin...@easysoft.com>wrote:
> Perhaps I am misreading
> http://www.nntp.perl.org/group/perl.cpan.testers/2009/01/msg3090019.htmlbut it looks as if the C compiler is not set up properly. Why would anyone
Martin Evans
> Some people have Perl without a compiler -- this looks like a Windows
> ActiveState Perl setup. Why smoke without a compiler? To show what
> happens when distros on CPAN get tested without one. (Which could
> happen for normal users unknowingly via dependencies, which is one of
> the reasons that Perl without a compiler makes CPAN nearly unusable and
> one of the reasons that drove the creationof Strawberry Perl.)
I didn't get the impression this person was doing a single report - he
is 16th on the leader board of test submissions. If the C compiler is
not set up properly (and see below because I did not generate the
compiler error) he could generate thousands of UNKNOWN for any module
that has XS - does not seem any point in that.
> In this case, the "UNKNOWN" result is correct (in the new definition of
> it). The build failed and tests could not be run, thus the result of
> tests is unknown. Your error message is very descriptive -- I think
> it's perhaps the best Makefile.PL error message I've ever seen.
That error did not come from me - I think it may have come from
ExtUtils::MakeMaker but I'm not sure.
> -- David
Martin
David Golden
> I didn't get the impression this person was doing a single report - he is
> 16th on the leader board of test submissions. If the C compiler is not set
> up properly (and see below because I did not generate the compiler error) he
> could generate thousands of UNKNOWN for any module that has XS - does not
> seem any point in that.
>
There's a debate at the moment on #p5p about whether it's an error to have
$Config{cc} and not have the named compiler. If so, every AS perl is
"broken".
There *is* a point -- it's how well does a distribution that requires a
compiler deal with the situation where a compiler doesn't exist. Does it
die with a reasonable error to a user? Or does it fail with something
unintelligible. It's just a prerequisite like any other.
> In this case, the "UNKNOWN" result is correct (in the new definition of
> it). The build failed and tests could not be run, thus the result of tests
> is unknown. Your error message is very descriptive -- I think it's perhaps
> the best Makefile.PL error message I've ever seen.
>
> That error did not come from me - I think it may have come from
> ExtUtils::MakeMaker but I'm not sure.
>
I meant the long text from Makefile.PL about running the VCVARS32.bat file
and so on. You're being very prescriptive about how to get the compiler set
up correctly. I think that's awesome.
-- David
Ulrich Habel
> users unknowingly via dependencies, which is one of the reasons that Perl
> without a compiler makes CPAN nearly unusable and one of the reasons that
> drove the creationof Strawberry Perl.)
I don't think this renders Perl totally useless. There are at least
alot of modules which doesn't require a compiler just a plain
"make"/nbmake. Even with the introduction of Module::Build it
obsoletes the need for a compiler for pure modules.
Maybe XS modules should be more careful in the build phase, so I think
it's perfectly fine with me that such modules enters the state of
"UNKNOWN".
Uli
Martin Evans
> On Mon, Jan 19, 2009 at 6:30 AM, Martin Evans <martin...@easysoft.com
> <mailto:martin...@easysoft.com>> wrote:
>
> I didn't get the impression this person was doing a single report -
> he is 16th on the leader board of test submissions. If the C
> compiler is not set up properly (and see below because I did not
> generate the compiler error) he could generate thousands of UNKNOWN
> for any module that has XS - does not seem any point in that.
>
>
> There's a debate at the moment on #p5p about whether it's an error to
> have $Config{cc} and not have the named compiler. If so, every AS perl
> is "broken".
>
> There *is* a point -- it's how well does a distribution that requires a
> compiler deal with the situation where a compiler doesn't exist. Does
> it die with a reasonable error to a user? Or does it fail with
> something unintelligible. It's just a prerequisite like any other.
This smoker does seem to have a compiler but it is not set up right. I
see little point in a smoker doing this all day - it will generate loads
of reports for little gain - so I guess we'll have to disagree there.
I guess I was interested to find out if this was deliberate or
unintentional.
>
>
> In this case, the "UNKNOWN" result is correct (in the new definition
> of it). The build failed and tests could not be run, thus the
> result of tests is unknown. Your error message is very descriptive
> -- I think it's perhaps the best Makefile.PL error message I've ever
> seen.
>
> That error did not come from me - I think it may have come from
> ExtUtils::MakeMaker but I'm not sure.
>
>
> I meant the long text from Makefile.PL about running the VCVARS32.bat
> file and so on. You're being very prescriptive about how to get the
> compiler set up correctly. I think that's awesome.
So did I. I do not generate that text - it must come from
ExtUtils::MakeMaker, or MS visual C may be.
>
> -- David
Martin
David Golden
> This smoker does seem to have a compiler but it is not set up right. I see
> little point in a smoker doing this all day - it will generate loads of
> reports for little gain - so I guess we'll have to disagree there.
>
> I guess I was interested to find out if this was deliberate or
> unintentional.
>
If it's present, but misconfigured, then I agree with you, as that's
misleading. But I'm supportive of modules that need a compiler actually
checking for a compiler. Devel::CheckLib now makes this pretty easy.
(Checking for no libraries at all does a simple compiler check).
> So did I. I do not generate that text - it must come from
> ExtUtils::MakeMaker, or MS visual C may be.
>
Oh! You're right -- I assumed was part of the long text like you had about
reading the README. My mistake.
Have you contacted the author directly? DAVIDRW is a CPAN author so "@
cpan.org" should work.
-- David
David Westbrook
i'll hop in from some scattered quotes:
> Some people have Perl without a compiler -- this looks like a Windows ActiveState Perl setup.
Yes, it's activestate 5.8.7 on a win2k box -- Binary build 815
[211909], built 11/2/2005.
> This smoker does seem to have a compiler but it is not set up right.
yeah, apparently i just have nmake.exe, and not the other moving parts
on this box.
> I didn't get the impression this person was doing a single report - he is 16th on the leader board of test submissions.
But only 200 reports have been sent from this box. The bulk of the
others have been from the methodology described in the "rfc: pen drive
smoker howto" thread from a knoppix livecd.
The reports in question here were generated with the snippet from the
'rfc: "safer" smoking' thread, where i was attempting to test what
i've currently got, as opposed to full smoking (which i wouldn't do on
this box, since it's a home desktop).
--david
David Cantrell
> There's a debate at the moment on #p5p about whether it's an error to have
> $Config{cc} and not have the named compiler. If so, every AS perl is
> "broken".
As is perl as distributed by Debian, Redhat and no doubt others, as you
can install them without installing a compiler. You can even install a
*different* compiler, such as icc or Sun's cc instead of gcc, or gcc
instead of MIPSpro on Irix, or ...
%Config tells you how perl was built. Using it to find out what the
current environment is can be at best a guide. That's why
Devel::CheckLib (for example) looks for $Config{cc} and checks to see
if it actually exists.
Also note that $Config{cc} might be something like "ccache blah" where
blah is the compiler and ccache some species of wrapper. Both of them
seperate executables, there is no file called "ccache blah" and trying
to exec() it will fill your computer with suffering and woe.
Devel::CheckLib knows about that too :-) although it doesn't check that
the second word is also executable - perhaps I should special-case
ccache and have it do that too.
So I suppose there might be a bug, but given that it's possible to build
perl and have $Config{cc} come out the end set as "ccache gcc", then the
bug is in the perl build process.
--
David Cantrell | Official London Perl Mongers Bad Influence
There is no one true indentation style,
But if there were K&R would be Its Prophets.
Peace be upon Their Holy Beards.
David Golden
> On Mon, Jan 19, 2009 at 06:55:00AM -0500, David Golden wrote:
> > There's a debate at the moment on #p5p about whether it's an error to
> have
> > $Config{cc} and not have the named compiler. If so, every AS perl is
> > "broken".
>
> As is perl as distributed by Debian, Redhat and no doubt others, as you
> can install them without installing a compiler. You can even install a
> *different* compiler, such as icc or Sun's cc instead of gcc, or gcc
> instead of MIPSpro on Irix, or ...
>
Here's the Pod for Config on the subject (Nicholas Clark cited it to me on
IRC):
"cc"
From cc.U:
This variable holds the name of a command to execute a C compiler
which can resolve multiple global references that happen to have
the same name. Usual values are "cc" and "gcc". Fervent "ANSI"
compilers may be called "c89". "AIX" has xlc.
So technically, one could say that installing a perl without a compiler
should clear the $Config{cc} setting, as there is no command to execute a C
compiler.
Practically speaking, this is night impossible, so the IRC discussion
concluded that there was little to be done about it.
-- David
Slaven Rezic
Other than changing the documentation of Config.pm?
--
Slaven Rezic - slaven <at> rezic <dot> de
tksm - Perl/Tk program for searching and replacing in multiple files
http://ptktools.sourceforge.net/#tksm
Jan Dubois
> On Mon, Jan 19, 2009 at 6:30 AM, Martin Evans <martin...@easysoft.com>wrote:
>
> > I didn't get the impression this person was doing a single report - he is
> > 16th on the leader board of test submissions. If the C compiler is not set
> > up properly (and see below because I did not generate the compiler error) he
> > could generate thousands of UNKNOWN for any module that has XS - does not
> > seem any point in that.
> >
>
> There's a debate at the moment on #p5p about whether it's an error to have
> $Config{cc} and not have the named compiler. If so, every AS perl is
> "broken".
This would be trivial to change. ActivePerl already determines the value of
$Config{cc} dynamically. It sets it to 'gcc' if cl.exe can't be found on the
PATH but gcc.exe is there.
When neither is found $Config{cl} remains at 'cl', indicating the compiler
this version of Perl was built with. Setting it to '' or even undef instead
would be trivial. However:
> There *is* a point -- it's how well does a distribution that requires a
> compiler deal with the situation where a compiler doesn't exist. Does it
> die with a reasonable error to a user? Or does it fail with something
> unintelligible. It's just a prerequisite like any other.
Right now you'll get a nice explanation from MakeMaker that your compiler is
set to Microsoft's Visual Studio compiler, but your LIB and INCLUDE variables
haven't been set up to match. It then doesn't generate a Makefile at all.
If you set $Config{cc} to the empty string MakeMaker will blindly insert this
into the generated Makefile and you get a bunch of warnings when you run
`nmake` that the '-c' command cannot be found.
If the "broken" version produces a sensible error message, and the "correct"
version produces a bunch of gibberish, then I prefer the brokenness.
I'm happy to get ActivePerl to change the value of $Config{cc} when no compiler
is found once the build tools do something sensible with an empty setting.
Cheers,
-Jan
Jan Dubois
> Right now you'll get a nice explanation from MakeMaker that your compiler is
> set to Microsoft's Visual Studio compiler, but your LIB and INCLUDE variables
> haven't been set up to match. It then doesn't generate a Makefile at all.
Looking more closely, this error messages comes from DBi/DBD and is not
generic to MakeMaker. :(
> If you set $Config{cc} to the empty string MakeMaker will blindly insert this
> into the generated Makefile and you get a bunch of warnings when you run
> `nmake` that the '-c' command cannot be found.
>
> If the "broken" version produces a sensible error message, and the "correct"
> version produces a bunch of gibberish, then I prefer the brokenness.
Standard Makemaker will blindly insert $Config{cc} and `nmake` will then complain:
'cl' is not recognized as an internal or external command,
This is still slightly better than
'-c' is not recognized as an internal or external command,
Module::Install gives proper error messages, regardless if $Config is set to
'' or 'cl':
Error (9): OS unsupported: Compiler used to build perl not specified in perl configuration
or
Error (8): OS unsupported: Compiler used to build perl ('cl') not found
I haven't checked Module::Build yet.
> I'm happy to get ActivePerl to change the value of $Config{cc} when no compiler
> is found once the build tools do something sensible with an empty setting.
The status quo still looks preferable right now, even though the
difference is not as big as I initially thought it would be.
Cheers,
-Jan
David Golden
> If the "broken" version produces a sensible error message, and the
> "correct"
> version produces a bunch of gibberish, then I prefer the brokenness.
>
> I'm happy to get ActivePerl to change the value of $Config{cc} when no
> compiler
> is found once the build tools do something sensible with an empty setting.
>
I was merely repeating what Nicholas Clark had said off the cuff on #p5p. I
agree with you and I think the general view was "oh, well" it's been that
way for ages so let's leave well enough alone.
-- David
Martin Evans
I am somewhat surprised the way the discussion went on this thread. Just
to clear a few things up from my perspective.
As Jan Dubois says, the error messages referred to in the smoke report
do appear to be from the Perl DBI module (actually, they are in
DBI::DBD) - I didn't realise that but in any case it was not my point.
My point was it looked like someone was smoking XS modules without a
properly installed development system capable of compiling and linking C
code. I guessed that from the aforesaid message that DBI::DBD output
which I think is a good message.
It would appear some people think it is perfectly reasonable to smoke XS
modules without a supporting development system - that's fine, I don't
really see the point myself but I can live with it.
All I was really attempting to do was to a) confirm that someone was
smoking without a development system and b) try and find out why. It
could always have been a problem in my module, and that was what
definitely did concern me.
I don't really have any strong opinion on the later discussions over
whether cc is in $Config{cc} but I would simply make one point. It is a
regular occurrence on the dbi-users list for someone to install a Perl
binary they got from IBM/Sun/HP/etc/etc and then try and use a compiler
different from the one used to build Perl - it never seems to work
(unsurprisingly). I often wonder why this is never caught. Lately, a new
issue is taking over - someone installs a 32bit perl and attempts to use
it with 64bit libraries or vice versa.
Thank you to all who responded.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
David Golden
> I am somewhat surprised the way the discussion went on this thread. Just to
> clear a few things up from my perspective.
>
We're just chatty. ;-)
Thank you for the original email -- it's good for us to test our own
assumptions and motivations sometimes.
-- David
David Cantrell
> This would be trivial to change. ActivePerl already determines the value of
> $Config{cc} dynamically. It sets it to 'gcc' if cl.exe can't be found on the
> PATH but gcc.exe is there.
Isn't that kinda dodgy? XS modules expect to be built with the same
toolchain as perl was, and the way they figure that out is by looking at
%Config. If you mix and match compilers, Bad Things can happen.
--
David Cantrell | Minister for Arbitrary Justice
Eye have a spelling chequer / It came with my pea sea
It planely marques four my revue / Miss Steaks eye kin knot sea.
Eye strike a quay and type a word / And weight for it to say
Weather eye am wrong oar write / It shows me strait a weigh.
Jan Dubois
> On Mon, Jan 19, 2009 at 03:35:17PM -0800, Jan Dubois wrote:
>
> > This would be trivial to change. ActivePerl already determines the
> > value of $Config{cc} dynamically. It sets it to 'gcc' if cl.exe
> > can't be found on the PATH but gcc.exe is there.
>
> Isn't that kinda dodgy? XS modules expect to be built with the same
> toolchain as perl was, and the way they figure that out is by looking
> at %Config. If you mix and match compilers, Bad Things can happen.
Yes, just changing $Config{cc} is kind of dodgy, but ActivePerl is
actually reconfiguring the rest of the toolchain too. So $Config{ccflags},
$Config{ldflags} and so on are all changed to the correct values too.
Both Visual C 6.0 and the MinGW GCC compiler link against the same C runtime
library (MSVCRT.dll), so there are no problems there either. One difference
between the compilers is that VC uses a somewhat unusual mechanism to layout
bit fields inside structs, so ActivePerl adds the -mms-bitfields option
to the ccflags if GCC is being used.
I'm not aware of any problems using MinGW to build additional modules for
ActivePerl. Feel free to play with it yourself; all you need to do is
ppm install MinGW
with any ActivePerl 5.8.8 or later and you should be able to build modules
using GCC and dmake, e.g. by using the cpan shell:
cpan Win32::UTCFileTime
BTW, the same is true for ActivePerl on HP-UX and Solaris: while ActivePerl
has been compiled with the vendor compilers on those platforms, it will switch
all %Config settings to the correct values for GCC if the vendor compiler
isn't found, but 'gcc' is on the PATH (there are no PPM packages for GCC on
HP-UX or Solaris though; you have to install it the traditional way).
Cheers,
-Jan