The conundrum I'm in is that I need libperl.so to build mod_perl and libperl.a to build a static version of DBD::Sybase

Your best bet is probably to run the build twice, once with -Duseshrplib and once without.  And then install whichever variant of perl you want (static/dynamic), manually copying the missing libperl from the other build next to the already installed one. For example, if you install the statically linked perl binary, libperl.a will get installed together with it, so just copy the libperl.so from the other build next to it (in the same directory).

But note that if you have both a static and a dymanic library in the same location, the linker (ld) will by default link against the dynamic one (so if you don't want this to happen, the easiest approach is typically to just move it away temporarily while building whatever needs the static lib...).

That said, it might be wiser to simply install both versions into separate directories, because then the configuration information (i.e. essentially what you get via "perl -V") will automatically be correct without manual tweaking.

BTW, what exactly do you mean by "build a static version of DBD::Sybase"?  Are you building an extra perl binary that already includes the XS part of the DBD::Sybase module statically (as opposed to loading the extension at runtime via DynaLoader)? Otherwise, I wouldn't know why you would need a libperl.a for that.  If it's only because you don't want to have dependencies on shared sybase libs, you should (in theory) be able to link the sybase code/libs statically into a shared XS lib (i.e. Sybase.so) and still have that library loaded at runtime from either a statically or a dynamically linked perl binary (in which case that XS lib would no longer depend on the third party sybase libs — at runtime, that is, at build-time you of course need them).