ExtUtils::CBuilder uses ld to link programs, thus failing #13531
Comments
From schmorp@schmorp.deCreated by schmorp@schmorp.deSubject basically says it all, ExtUtils::CBuilder errornously tries to use The symptom is a lot of modules fialing entirely or installing pure-perl This most often, but not always, happens when modules use the Whats more, on systems that do not use dynamic loading, $Config{ld} always The only workaround is to define LD in the environment, which is the wrong Perl Info |
From schmorp@schmorp.deThings seem more complicated - ExtUtils::CBuilder actually tries to link -- |
From @LeontOn Thu, Jan 16, 2014 at 3:29 PM, schmorp@schmorp.de <
On Unix, it explicitly uses $Config{cc} to link executables[1], though it
What flags are missing? I suspect that'd be lddlflags not being defined. This most often, but not always, happens when modules use the
Can you give a concrete example of how you trigger this? AFAIK it usually Whats more, on systems that do not use dynamic loading, $Config{ld} always
ld not being overridable definitely sounds like a bug. I think on most
I agree that's not much of a solution. Leon
|
|
The RT System itself - Status changed from 'new' to 'open' |
From @LeontOn Thu, Jan 16, 2014 at 4:07 PM, Marc Lehmann <schmorp@schmorp.de> wrote:
Correct. The only thing it does reliably is the thing Module::Build uses it for: I've been meaning to write a minimalistic "can this system compile stuff" Leon |
From schmorp@schmorp.deOn Thu, Jan 16, 2014 at 04:47:46PM +0100, Leon Timmermans <fawaka@gmail.com> wrote:
The problem is that this isn't reflected in the manpage, and it being a I guess a better solution would be to remove both Module::Build and Maybe for the time being a clear warning in the manpage not to use these
Thats a great building block, but doesn't solve the larger issue of more (As I had to painfully find out over the last week - last year I could -- |
From @rjbs* Marc Lehmann <schmorp@schmorp.de> [2014-01-16T11:12:57]
For the record, Module::Build is slated for removal in 5.21, but EU::CB is not. -- |
From @LeontOn Thu, Jan 16, 2014 at 5:12 PM, Marc Lehmann <schmorp@schmorp.de> wrote:
It is mentioned as "it is *not* intended as a general cross-platform
Module::Build is deprecated for 5.20, and will be removed in 5.22 ;-). That As for ExtUtils::CBuilder, personally I see no reason why it should remain Maybe for the time being a clear warning in the manpage not to use these
There are situations where Module::Build is the only reasonable option, and Thats a great building block, but doesn't solve the larger issue of more
That isn't going to change as long as there aren't any alternatives. Leon |
From schmorp@schmorp.deOn Fri, Jan 17, 2014 at 04:20:29AM +0100, Leon Timmermans <fawaka@gmail.com> wrote:
Well, people use it mostly to detect whether a compiler is available. I
That made my day! Probably my year! However... (moved below to the It's scary how that dependency crept into CPAN in recent years, and that (https://metacpan.org/requires/module/Module::Build lists 3816 results,
Ok... however, to be fair, you must admit that meta 2.0 support isn't So, while meta 2.0 support might be great progress, it doesn't really feel As it is both Module::Build and ExtUtils::CBuilder simply ignore the So, while it might not be fair, you must admit that calling it
While it certainly should go, removing it from the core isn't atcually fixing It would be far preferable to make these modules work, at least
I am curious, can you name even one such situation (or even a few?). I I did hear that Module::Build is "great" for module authors (I am a module However, I am also from the other side (building perl distros), and for those For example, after SDL was switched to Module::Build there wasn't a SDL The design of Module::Build makes it almost impossible to actually build the If Module::Build would generate a Makefile.PL by default (something it That unfortunately doesn't help for ExtUtils::CBuilder - I have found that So a much more preferably (probably in addition) way to actually help the
Sure - the disadvantage of Module::Build and ExtUtils::CBuilder, however, Again, for people actually building modules, Module::Build is pure hell. And Unfortunately, that is also true for ExtUtils::CBuilder, as it suffers
Well, there are. The easiest alternative the works in 90% of the cases is to a) extra check to tell the user that her configuration is broken. that usage The b) case is valid, but using it for this purpose doesn't work all that After all, the systems where you cannot install the proper compiler easily Might be a good start, but neither "can_compile_executable" nor Most uses of "have_compiler" are of the form "can I compile an xs Do you have an actual use case where one would use To be more precise, the question most people want answered is "will Some want the quetsion answered: "will Module::Build be able to compile Anyways, I cloned it, and can tell you that can_compile_executable works As expected (thats true), can_compile_loadable_object works well as well, The questions regarding loadable objects mostly boils down to these: - when two extensions use the same library, will it be the same (.so) The all important question "can I compile an extension that uses Lastly, I wonder - if you are concerned about these issues, and you There are really low-hanging fruit to catch here. Heck, even something like: sub have_compiler { in a cpan-installable ExtUtils::CBuilder would already be enourmously Is there a specific reason to keep the modules in question in broken -- |
From ambs@zbr.ptA quick pair of cents... On 17/01/14, 10:01, Marc Lehmann wrote:
It is not, but it does a pretty good job on that both for C and C++. I Cheers |
From @LeontOn Fri, Jan 17, 2014 at 11:01 AM, Marc Lehmann <schmorp@schmorp.de> wrote:
Most of those 216 are probably because Module::Build used to require one to
It is an important feature for many end-users, for example those that want There are well-known build bugs open for half a decade, and I feel I
Same could be said for ExtUtils::MakeMaker actually, though thanks to
It doesn't work for a fairly tiny minority, but AFAICT it's pretty much It would be far preferable to make these modules work, at least
Obviously. I am curious, can you name even one such situation (or even a few?). I
You can write extensions in Module::Build entirely in Perl, which you I did hear that Module::Build is "great" for module authors (I am a module
IME writing a *good*, correct and backwards compatible Makefile.PL is can For example, after SDL was switched to Module::Build there wasn't a SDL
I agree that is a problem, but again the real issue is in
Patches welcome. Honestly, you're probably the person here with most Sure - the disadvantage of Module::Build and ExtUtils::CBuilder, however,
They do work on most configurations, or else perl couldn't ship with it.
Actually I would like to see Module::Build gone, but for subtly different
We conceived PUREPERL_ONLY/--pureperl_only at last year's QA Hackathon, but
Many cheap hosting companies don't supply a compiler :-(.
Well, it's just something I hacked up last night, it's quite far from being
That's why I called it can_compile_loadable_object and not have_compiler or
It's mostly a step towards can_compile_perl_extension. The all important question "can I compile an extension that uses
Is that on static perls (where it should be false), or on dynamic perls? Lastly, I wonder - if you are concerned about these issues, and you
Because I consider it unsalvageable: I'd rather spend time on writing a Another part of your particular issue is that there's no documentation on I might actually fix this given how much depends on it, but hateful code is
Seems reasonable.
There is no specific reason. It's really that it isn't getting any love Leon |
From schmorp@schmorp.deOn Fri, Jan 17, 2014 at 06:27:51PM +0100, Leon Timmermans <fawaka@gmail.com> wrote:
I install without running tetss by default (as my experience is that
I'd gladly install test dependencies (in fact, I currently have to, as
But apparently none as important as actually making the module compile and
Possibly, but ExtUtils::MakeMaker never kept me from having a module actually I think the majore thing that ExtUtils::MakeMaker has in it's favour is that It's not at all uncommon to have to have some adjustments for some build
Yes, but even before, ExtUtils::MakeMaker never was even near as
For some reason, all my platforms seem to be "in the minority". I cannot
I am not sure what that means - all of my pure-perl extensions are using
True, but unlike with Module::Build, it's at least possible. Trying the same with Module::Build generally results in basically I know it's just me, but I choose difficult-but-possible over
All cases I stumble over are have_compiler return false when I really don't care how ell it is designed, but the main problem w.r.t.
I am quite sure one can fix have_compiler and a lot more without rewriting As long as ExtUtils::CBuilder doesn't even do what it documents to do, it's So at the very least, the documentation should have some big "WARNING: this That would make it much easier to get cpan authors to actually fix their So there is a classical catch 22 - module authors rely on ExtUtils::CBuilder One side has to give - either deprecate ExtUtils::CBuilder *officially* Saying it's badly designed but at the same time claiming it works when it
As if the problem happens only with non-dynamic perls. I'll think about a patch - however, if ExtUtils::CBuilder is supposed to
Not in my experience.
Perl as shipped usually only builds cleanly on a few platforms. I think you confuse "most platforms" with "most gnu/linux distributions in
As it is, Module::Build/ExtUtils::CBuilder don't work on GNU/Linux and If I only had problems with static linking I could understand your
Very likely - I don't want to see it gone as much as I would like to see it The reason I want tos ee it gone is that I don't see it gettting fixed
If that means using an env variable or switch, then I'd say it's a Maybe that's just a minority, but unfortunately, some CPAN authors want to
Looking at the prices for virtual hosting, I am not sure the price is the Whats more, Debian GNU/Linux and Fedora (and most other GNU/Linux distros) do So, since this is a real problem, module authors will want to go for
You called it thsat wa ybecause you do not want to answre the common I am still quite intereste din a usecase for can_compile_loadable_object -
But can_compile_perl_extension does not rely on
static perls (I maintain 4 dynamic distros and 9 static ones at the (as a sidenote, the distinction is between static extensions and dynamic however, is it really clearly defined what a "loadable object"
Would you accept a doc patch that officiall deprecates the module,
Not just that, adding more frameworks makes the problem worse, not better - No issue if you actively maintain such frameworks, but as Module::Build
I know a lot of ways to detect the presence of the configured compiler and A simple way would be for the existance of the programs themselves. That would I wouldn't work correctly when your compiler is "ccache gcc" (as it often If that isn't enough, indeed linking an extension the way MakeMaker I mean, do you want to answer "system has a compiler" as documented, or do
I can send a patch - any suggestions for the name of the variable? (my -- |
From schmorp@schmorp.deBTW, yes, you can also load modules dynamically in static perls - the In any case, a point I wanted to make clear is that I do not expect perl to My concern is being able to work around any issues. For example, The first three are relatively minor in effect. The last one is brutal, So, all I would be asking fro is to not have a totally hardwired Being able to trickle out a (full) Makefile.PL in a generic way from a # patch CPAN::HandleConfig.pm to always include _our_ MyConfig.pm, # patch ExtUtils::MM_Unix to always search blib for modules # patch ExtUtils::Miniperl to always add DynaLoader # ExtUtils::CBuilder always tries to link shared libraries -- |
Migrated from rt.perl.org#121017 (status was 'open')
Searchable as RT121017$
The text was updated successfully, but these errors were encountered: