Just to continue my saga to figure out how to compile wxPerl on OS X, I think I have figured out a least partially way I can't get past the Makefile.PL stage.

I am getting errors like:
No such 'link' library: 'adv' at /Users/dfreed/sourcecode/WxPerl-0.67/build/Wx/build/MakeMaker.pm line 206

When running this stage.  I ran this through the debugger, and it appears that wxPerl is expecting to find libs like:  adv, core, base, html when calling Alien::wxWidgets->libraries, at least the Makefile.PL script is passing a list of names like this to that Alien function.  When I dug into what was going on in Alien::wxWidgets, I see that it has a file:  /Library/Perl/5.8.6/darwin-thread-multi-2level/Alien/wxWidgets/Config/mac_2_8_0_gcc_3_4.pm  which appears to be generated when Alien::wxWidgets is built.  This file defines a hash that contains wx-config information in it.  The keys of the _libraries hash are all a single letter for example:

'_libraries' => {
                            'e' => {
                                     'link' => '-lwx_mac_core-2.8',
                                     'dll' => 'libwx_mac_core-2.8.dylib'
                            'c' => {
                                     'link' => '-lwx_mac_xrc-2.8',
                                     'dll' => 'libwx_mac_xrc-2.8.dylib'
                            'e' => {
                                     'link' => '-lwx_base_carbon-2.8',
                                     'dll' => 'libwx_base_carbon-2.8.dylib'

But it looks like the wxPerl is passing it keys like 'core' and 'xrc', etc.  Somehow the hash keys appear to only be the last letter of the library name.  I didn't dig to see why that is.  There were also several important libraries not in the hash at all.  After hand editing the file to this:

          '_libraries' => {
                            'core' => {
                                     'link' => '-lwx_mac_core-2.8',
                                     'dll' => 'libwx_mac_core-2.8.dylib'
                            'xrc' => {
                                     'link' => '-lwx_mac_xrc-2.8',
                                     'dll' => 'libwx_mac_xrc-2.8.dylib'
                            'base' => {
                                     'link' => '-lwx_base_carbon-2.8',
                                     'dll' => 'libwx_base_carbon-2.8.dylib'
                            'qa' => {
                                     'link' => '-lwx_mac_qa-2.8',
                                     'dll' => 'libwx_mac_qa-2.8.dylib'
                            'adv' => {
                                     'link' => '-lwx_mac_adv-2.8',
                                     'dll' => 'libwx_mac_adv-2.8.dylib'
                            'aui' => {
                                     'link' => '-lwx_mac_aui-2.8',
                                     'dll' => 'libwx_mac_aui-2.8.dylib'
                            'richtext' => {
                                     'link' => '-lwx_mac_richtext-2.8',
                                     'dll' => 'libwx_mac_richtext-2.8.dylib'
    'html' => {
                                     'link' => '-lwx_mac_html-2.8',
                                     'dll' => 'libwx_mac_html-2.8.dylib'
    'net' => {
                                     'link' => '-lwx_base_carbon_net-2.8',
                                     'dll' => 'libwx_base_carbon_net-2.8.dylib'
                            'xml' => {
                                     'link' => '-lwx_base_carbon_xml-2.8',
                                     'dll' => 'libwx_base_carbon_xml-2.8.dylib'
                            'stc' => {
                                     'link' => '-lwx_mac_stc-2.8',
                                     'dll' => 'libwx_mac_stc-2.8.dylib'


I can now run perl Makefile.PL to completion and build wxPerl.  I'm still having some problems.  Just loading the Wx module is now causing an error:

$ wxperl
use Wx;
Can't load '/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/Wx/Wx.bundle' for module Wx: dlopen(/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/Wx/Wx.bundle, 1): Symbol not found: __ZTV11wxMediaCtrl
  Referenced from: /Library/Perl/5.8.6/darwin-thread-multi-2level/auto/Wx/Wx.bundle
  Expected in: dynamic lookup
at - line 1
Compilation failed in require at - line 1.
BEGIN failed--compilation aborted at - line 1.

I'm not sure what the heck this is about.  But I am closing in...

If anyone has anything thoughts that would help, they would be very much appreciated.

Dan Freed

On Jan 19, 2007, at 2:53 PM, Eric Wilhelm wrote:

# from Beule, Franck
# on Friday 19 January 2007 06:01 am:

And for my conclusion, if it's hard to compile on Windows (someone
succeded on this task,
but he didn't explained how) and impossible to compile on Linux and
does someone really use wxPerl ???

Yes, it is quite possible.  No, it is not easy.  IME, Alien::WxWidgets 
can be a bit of a pain.  I've not managed to successfully compile on 
windows, but getting the right tools installed on windows is a huge 
pain.  I built wxGTK on linux without any trouble, but Alien::WxWidgets 
is still a speed-bump there.  The mac works too, though getting it 
built as a universal binary is a huge pain because apple decided to put 
too much of the smarts into xcode and CPAN isn't having any of that.

Which is why dotReader has to provide out-of-the-box bundles for all 
three platforms.  That's not easy.  Dependency scanning is the current 

Consider the challenges:

  o compiling wxWidgets without user intervention (Alien)
  o compatibility with multiple wxWidgets versions
  o compatibility with multiple perl versions
  o various flaky windows environments (make, nmake, gcc, cc.exe, etc)
  o compatibility with multiple mac versions
    (mac testing is expensive: 1 OS per machine, no virtualizing,
     and apple end-of-lifes the old xcode on day one of the next OS)

And that's just the overhead to developing the perl binding.  
Unfortunately, until more people pitch in to strawberry perl, automated 
cross-platform testing, etc, this isn't going to get easier for 
end-users either.  wxPerl itself is very well done, but these huge 
barriers to entry make it hard to test, let alone contribute.

IMNSHO, the spam on this list doesn't help much.  The wiki is also a bit 
slow from this part of the world.  I think wxPerl's users, code, and 
documentation would really benefit from moving to the perl.org 
infrastructure (mail, svn, probably even hosting.)

"Matter will be damaged in direct proportion to its value."
--Murphy's Constant

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
wxperl-users mailing list

Daniell Freed
Bereshit bara Elohim et hashamayim ve'et ha'arets...