I don't have a theoretical answer about the source of the problem; GDBM seems relatively undocumented. But I do have a workaround.
Define your file
$voo = "/somewhere/voo";
somewhere before the subroutine call.
Substitute the variable $voo for $_[0] in the DBMopenread subroutine -- it is a global variable, so the statement become:
$DBREFread=tie %DBM, GDBM_File, $voo, &GDBM_READER, 0644;
Leave the parameter out of the subroutine call, just:
&DBMopenread;
Seems to work. Of course you have to pay attention to the other instances of 'voo' versus the variable $voo.
Sorry I don't have a more satisfactory "why," but you can get on with yur work.
Well, it's good to know that I'm not the only one stumped by this! Thank you very much for the workaround; now I have to decide whether to apply this within my wreq installation, or just live with the error message. (The DBMopenread call occurs pretty commonly within wreq, so this would be nontrivial.)