extutils::MakeMaker trying to portability build a shared lib

extutils::MakeMaker trying to portability build a shared lib

am 09.07.2007 22:36:42 von Andrew Torda

I cannot see how to get MakeMaker to build a dynamic library for
me in the most portable manner.
I have a module which consists of a few dozen C files in two
directories.
For years, we have used a Makefile to build our library, then
MakeMaker/Makefile.PL to build the top level and link it all. The
problem is that we have to tweak all the options in our Makefile
manually. Do we compile with -fpic/-shared/nothing ? Do we link
to a .so or .a ? Do we have to ranlib the resulting library ?
I thought MakeMaker should have the machinery to sort this out,
but I am missing something. The top level Makefile.PL seems easy,

WriteMakefile(
'NAME' => 'Myname',
'DIR' => ['src'], # the first of the library directories
'INC' => '-Isrc',
'MYEXTLIB' => 'src/libmyname$(DLEXT)',
);
In the src directories with the C code, I have less luck
WriteMakefile(
NAME => 'libmyname',
OBJECT => '$(O_FILES)',
);
will build something, but puts them in
blib/arch/auto/libmyname/libmyname.so, but I want ./libmyname.so. In
one of the man pages, they use a postamble section like
sub MY::postamble {'
all :: dynamic
dynamic :: libmyname.$(DLEXT)
libmyname$(DLEXT): $(OFILES)
$(AR) cr libmyname.$(DLEXT) $(O_FILES)
$(RANLIB) libmyname.$DLEXT)';
}

but this cannot be the correct approach. On some machines, we
have to use "ar", but on others "cc -shared". I am sure that
there is a MakeMaker rule to handle this for me, but I can't find
it. Even better, I would like to persuade MakeMaker not to bury
the libmyname.so in blib.
I know I am not the first to try this, but I couldn't find any
nice examples.
Failing this, is there an elegant approach to building perl
binary extensions using the FSF's autoconf ?
Many thanks for any suggestions.