Couple of important prefaces! Android support is brand new in core perl, so I'm still working out edge cases and just plain breakage in the port. Also, the patch below is only half of the solution for this -- the other part is this fix for MakeMaker:
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/9d540908bbc962715da337b308cab06983d51fd5
Which I haven't merged into MakeMaker proper yet, because I figure it ought to get a thumbs up from here as well.
The attached patch does two things; the first is relatively simple, it adds support for platforms with DynaLoader::mod2fname() defined.
mod2fname isn't exactly well documented, but basically, some platforms have some unusual requirements for their library names, so instead of, say, Utils.so for List::Utils, you might end up with PL_List__Utils.so; what mod2fname does is get you that library name.
There's currently two systems with mod2fname defined, VMS and Android. OS/2 uses it as well, but the OS/2 port isn't functional at the moment. Additionally, Windows may start using it in the near future.
(as an addendum: I have a suspicion that the module doesn't work quite right on VMS as-is, but I don't have a VMS box to confirm that)
The second thing that the patch does is actually solve a problem with Android's linker. I'll copypaste a bit of the patch to explain this bit:
+ # Android's linker ignores the RTLD_GLOBAL flag
+ # and loads everything as if under RTLD_LOCAL.
+ # What this means in practice is that modules need
+ # to explicitly link to their dependencies,
+ # because otherwise they won't be able to locate any
+ # functions they define.
+ # We use the -l:foo.so flag to indicate that the
+ # actual library name to look for is foo.so, not
+ # libfoo.so
As an example of what would happen, if i want my module to depend on mro, instead of passing LIBS something like
"-L/mnt/asec/home/built/lib/perl5/5.19.9/armv7l-linux-android-thread-multi/auto/mro -lPL_mro"
it ends up passing this:
"-L/mnt/asec/home/built/lib/perl5/5.19.9/armv7l-linux-android-thread-multi/auto/mro -l:PL_mro.so"
Which is then used during linking to get the correct dependency.
I've also made this part of the patch only kicks in for Android, since to my knowledge the module is working fine elsewhere. I'm also not sure if -l: is gcc/clang only, but currently it's only possible to compile perl for/on android with gcc and potentially clang, so it's not really a worry.

Thanks for your work on this. Since the two changes -- support for
DynaLoader::mod2fname and Android compatiblity -- seem to be
independent, could you split the patch up? And the comment in front of
find_extra_libs() needs to be adjusted to mention Android.
And could you be bothered to write unit tests for the changes? That
would make me more comfortable applying the patch.

I am sending updated patch that is based on my testing on MS Windows. I have tested it on builds:
- with $Config{dlext} = 'xs.dll'
- with d_libname_unique='define'
- with both d_libname_unique='define' + $Config{dlext} = 'xs.dll'

It seems to work fine.

On top of the patch you have to create the following (empty) files:
- t/inc/DepTest: PL_DepTest.dll
- t/inc/DepTest: PL_DepTest.lib
- t/inc/DepTest: PL_libDepTest.dll.a

> I am sending updated patch that is based on my testing on MS Windows. I have
> tested it on builds:
> - with $Config{dlext} = 'xs.dll'
> - with d_libname_unique='define'
> - with both d_libname_unique='define' + $Config{dlext} = 'xs.dll'
>
> It seems to work fine.

The code looks good to me, but I'd still like to see the patch split up
into logically independent pieces: the DLEXT fix, the mod2fname support,
and the Android support.
And doesn't t/04_extra_libs.t need to be changed to be run on Android?
Show quoted text

> On top of the patch you have to create the following (empty) files:
> - t/inc/DepTest: PL_DepTest.dll
> - t/inc/DepTest: PL_DepTest.lib
> - t/inc/DepTest: PL_libDepTest.dll.a

Where is the "PL_" coming from? From d_libname_unique? Can we rely on
it always adding a prefix "PL_"? What about builds with, say,
$Config{dlext} = 'xs.dll' like you suggested? Wouldn't they look for a
different file in t/inc/DepTest?

> <URL: https://rt.cpan.org/Ticket/Display.html?id=92699 >
>
> Thanks for your work on this. Since the two changes -- support for
> DynaLoader::mod2fname and Android compatiblity -- seem to be
> independent, could you split the patch up? And the comment in front of
> find_extra_libs() needs to be adjusted to mention Android.
>
> And could you be bothered to write unit tests for the changes? That
> would make me more comfortable applying the patch.
>

Sure, can do. Pardons for the delay; I haven't been able to do much
hacking in the last couple of months due to moving continents, but I
can probably get to this either today or tomorrow.

also please add t/inc/DepTest/PL_DepTest.so, which will be used on Unixy systems.
Show quoted text

>
>

> > Where is the "PL_" coming from? From d_libname_unique?

>
> yes
>
>

> > Can we rely on it always adding a prefix "PL_"?

>
> I do not know

Yes. The behavior is the same on everywhere. Er, except OS/2, but the relevant tests aren't run there, so no harm done.
Show quoted text

>
>

> > What about builds with, say, $Config{dlext} = 'xs.dll'
> > like you suggested? Wouldn't they look for a
> > different file in t/inc/DepTest?

>
> They will but if ModName.xs.dll (using $Config{dlext}) is not found it
> will
> fall back to ModName.dll (using $Config{so}) and succeed
>
> Please note that the latest strawberry perl 5.20.0 was already
> released with
> $Config{dlext} = 'xs.dll' so it might be worth to apply at least
> ExtUtils-Depends-part1-dlext.diff in the near future
>

I can't contribute much to the windows discussion, but I'm wondering if that might need extra fixes; how does gcc on Windows handle -lPL_foo.dll? Does Windows+d_libname_unique+gcc also need the -l:PL_foo.dll hack?
In any case, apologies again, took forever to get back to this. Turns out that this is mostly already tested for in t/04_extra_libs.t; all that's needed is to enable testing on android, and adding that empty file (t/inc/DepTest/PL_DepTest.so).

Hi all,
I *think* I have collected all of the various changes discussed in this ticket, and added them to my personal EU::D repo on Github. Can you please pull my changes and verify?
https://github.com/cpanxaoc/perl-ExtUtils-Depends/commits/android_windows_changes
Brian Frasier, your patches had extra whitespace at the end of the line, git complained when I ran 'git am' to apply them to my tree. I removed the whitespace in a new commit, then rebased my commits down on top of your commits. FWIW, I downloaded your patches directly from RT using wget.
After applying patches, make/make test in EU::D worked for me, Perl 5.20.0 on OS X 10.9.x. Can you please test on your respective platforms and give me feedback. If everybody is happy, I can cut a release in the next few days.
There's a quasi-deadline here, I'm unavailable to cut a new release on August 3rd and 4th, and again from August 7th through the 20th.

Whoops, sorry about that. I see that there's a git repo for the module
-- hadn't spotted that before, would've made things easier to follow.
Show quoted text

>
> After applying patches, make/make test in EU::D worked for me, Perl 5.20.0 on OS X 10.9.x. Can you please test on your respective platforms and give me feedback. If everybody is happy, I can cut a release in the next few days.

All tests pass on Android. Additionally, with the changes I just
merged to ExtUtils::MakeMaker, modules using ExtUtils::Depends now
work as expected!
It all look clear on this end; Thanks!
Show quoted text

>
> There's a quasi-deadline here, I'm unavailable to cut a new release on August 3rd and 4th, and again from August 7th through the 20th.