MakeMaker and Library filename extensions

[Anonymous Monk]

Howdy all

Does anyone know how to override (or coerce) the library filename extension that MakeMaker looks for on a per build bassis ...

For example to switch linking between shared (so) and static (a) libs.

It always uses the .so if it exists.

I'm no Perl guru, though diggin about in Kid.pm and it appears to use $Config{'so'}.
Thus a challenge! ... I don't get it, The values in $Config{} should be easily adjustable per build.

Thanks

[syphilis]

I don't get it, The values in $Config{} should be easily adjustable per build

They are, if you take the ExtUtils::FakeConfig approach:

use Config;
use warnings;
use strict;

print $Config{cc}, "\n";

my $obj = tied %Config::Config;
$obj->{cc} = 'garbage';

print $Config{cc}, "\n";

__END__

Outputs:
gcc
garbage

Do the assigning of the alternate value(s) in a module (say, Config_alt.pm) and load that module before you run the Makefile.PL:

perl -MConfig_alt Makefile.PL

Or, if you want Config_alt.pm to be automatically loaded every time perl is run, just set the PERL5OPT environment variable to -MConfig_alt

Cheers,
Rob

[Anonymous Monk]

Rob, Thank you ... Finally an answer with a technique.

However, A few minutes ago I decided to try ExtUtils::MakeMaker::Config, I figured (because of the wonderful documentation) it was just a local copy of the readonly Config::Config{}, I tried it, it's not readonly, It provides an easily modifiable $Config, A couple of quick tests later shows it does the job smack on ...
Wow, Exactly what is needed!

Of course that leaves me wondering why this is "FOR INTERNAL USE ONLY"

It's construction is initialized from Config::Config.
It's avaliable in Makefile.PL et al.

So now I beg to know what the issue is with it's use and why it's not a documented capability.
One I consider a must have feature!

Off to do more testing with it ...

Thanks

[syphilis]

it was just a local copy of the readonly Config::Config{}

Yes, you can overwrite its values.
That won't alter %Config::Config at all, but as long as the values are taken from this local %Config then you can perhaps make use of it.

However, my preference would still be to overwrite %Config::Config itself as that is cleaner and simpler (IMO).
Also, there might be something in the .pm file or the test suite that looks specifically at %Config::Config rather than this local copy that EU::MM uses.

Cheers,
Rob

[Anonymous Monk]

use :nosearch, as in

perl Makefile.PL INC="-Ithis -Ithat/the/other" LIBS=":nosearch -Lthat/the/other -lblahblah.a -l/that/the/other/foo.a"

If it works it will work, if not you may need DEFINE="-DSOMETIHNG ... " or if Makefile.PL is being clever you may need to edit Makefile.PL and prefix :nosearch

[Anonymous Monk]

The results ...

Potential libraries are ':nosearch -L/usr/local/lib -lmylib -liconv -l
+z':
Unrecognized argument in LIBS ignored: ':nosearch'
'-lmylib' found at /usr/local/lib/libmylib.so.1.0
'-liconv' found at /usr/local/lib/libiconv.so.7
'-lz' found at /usr/lib/libz.so

Using -static ... It should be looking for .a.
Remove all versions of so's and it works.

I am the Makefile.pl creator. So there has been plenty of Makefile.pl editing and circumvention of MakeMaker's choking intelligence.

From you inclusion of full paths I take that to mean 'if' :nosearch worked MakeMaker, would accept a fully qualified filename?
Something it should do anyhoo!

-Enjoy

[Anonymous Monk]

Unrecognized argument in LIBS ignored: ':nosearch'

Upgrade ExtUtils::Liblist

Using -static ... It should be looking for .a.

What is this "-static"?

would accept a fully qualified filename?

It has always accepted those

I am the Makefile.pl creator. So there has been plenty of Makefile.pl editing and circumvention of MakeMaker's choking intelligence.

Very few succeed at improving Makefile.PL, and those that do don't ask questions like this