Re: From whence comes perl-5.8.6-smartmatch.tar?

[xmath]

As syphilis mentioned, the link errors are because Data::Alias digs a fair bit into perl's guts to do its job. It meddles with lexer state, modifies the PL_check[] array, and do various other things that are no doubt considered big "no-no"s. :-)

Work-arounds are using cygwin or recompiling perl with an augmented list of exported symbols.

I've also been pondering if there's some rude way for me to manually resolve those symbols are runtime, even if they're not exported. I'd need to dig a bit into what object formats and linkage are like on Win32.

[BrowserUk]

I've also been pondering if there's some rude way for me to manually resolve those symbols are runtime, even if they're not exported.

The simple answer is no. Unfortunately, the complicated answer is no also ;(

There really is no way to know where a piece of code has been stuffed in a dll if it's entrypoint is not exported.

The real answer here is to export all the entrypoints. It costs (almost) nothing to do and so what if people can call entrypoints that are not documented as public? If those entrypoints go away or change, and their code breaks--it's their problem.

Given that there isn't anyway to police this on most platforms including the 'reference platform', it's very much at odds with Perl's usual permissive stance, and very unfair on user of those few platforms that can enforce it.

[xmath]

There really is no way to know where a piece of code has been stuffed in a dll if it's entrypoint is not exported.

No debugging symbols or whatever?

The real answer here is to export all the entrypoints.

I agree

[BrowserUk]

No debugging symbols or whatever?

Not unless the dll was built for debugging. For example, the first of the missing exports in the OP is _Perl_av_reify referenced in function _da_refgen, and searching perl58.dll for "reify" turns up nothing:

C:\Perl\bin>strings perl58.dll | find "reify"