http://www.perlmonks.org?node_id=674349


in reply to Re^2: RFC: Setting up a minGW compiling envronment for Perl 5.10
in thread RFC: Setting up a minGW compiling envronment for Perl 5.10

Try adding the ld option -export-all-symbols to your builds that attempt to link against 2 dlls.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^4: RFC: Setting up a minGW compiling envronment for Perl 5.10
by syphilis (Archbishop) on Mar 15, 2008 at 14:05 UTC
    Try adding the ld option -export-all-symbols

    As regards my simplistic test case where I have Foo, Bar, and FooBar modules (and where FooBar needs to link to Foo.dll and Bar.dll), both Foo.dll and Bar.dll already export the symbols ('foo' and 'bar', respectively) that FooBar needs to link to.

    Having installed Foo and Bar into C:/temp/perl, I can try to build FooBar in the following way:

    1)Run 'perl Makefile.PL';
    2) Open the generated Makefile and, to the LDLOADLIBS entry, append -LC:/temp/perl/lib/auto/Bar -lBar -LC:/temp/perl/lib/auto/Foo -lFoo;

    Running dmake then terminates with: 
    FooBar.o:FooBar.c:(.text+0x1d): undefined reference to `foo'
collect2: ld returned 1 exit status
dmake:  Error code 129, while making 'blib\arch\auto\FooBar\FooBar.dll
+'

    [download]
    If, in step 2) I instead reverse the order and append -LC:/temp/perl/lib/auto/Foo -lFoo -LC:/temp/perl/lib/auto/Bar -lBar to the LDLOADLIBS entry in the generated Makefile, then dmake terminates with: 
    FooBar.o:FooBar.c:(.text+0x2b): undefined reference to `bar'
collect2: ld returned 1 exit status
dmake:  Error code 129, while making 'blib\arch\auto\FooBar\FooBar.dll
+'

    [download]
    If I don't do *anything* to the generated Makefile, dmake terminates with: 
    FooBar.o:FooBar.c:(.text+0x1d): undefined reference to `foo'
FooBar.o:FooBar.c:(.text+0x2b): undefined reference to `bar'
collect2: ld returned 1 exit status
dmake:  Error code 129, while making 'blib\arch\auto\FooBar\FooBar.dll
+'

    [download]
    I suspect that your suggestion of adding -export-all-symbols relates to the situation where Foo.dll and Bar.dll don't already export their symbols. In my case, both Foo.dll and Bar.dll already export their symbols, so I don't see that -export-all-symbols has anything to offer. (I know I don't have to ask you to correct me if I've missed the point :-)

    (This goes back to this thread - where, as you probably recall, you provided excellent help.)

    Hidden in readmore tags, below my sig, is the source to all three (Foo, Bar and FooBar) extensions ... for any who feel driven to test things out. It amazes me that Gtk2 resorts to this sort of thing ... I'm sure there are reasons for doing that ... as to whether they are *good* reasons ....

    Cheers,
    Rob
    Read more... (4 kB)
[reply]
[d/l]
[select]

      It was after our discussion about ld linking directly against .dlls thatI went and browsed a few pages that google threw up, and I remember reading something about the export-all-symbols flag. It said something about it being enabled by default but disabled under certain conditions.

      When I saw your post and managed to locate a reference to the flag, to check the spelling, but not the page a read about the disabling of the default or the conditions, something to do with .def files. I don't have/use MinGW to try it out.

      I'll do another google and try to locate the discussion I saw before.

      Update: I found this page which discusses the stuff about that switch. I'm not sure if it is the same page I read before, but it rings bells. I'm also not able to determine in the abstract if it will have any affect on your example problem?

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
        I'm also not able to determine in the abstract if it will have any affect on your example problem?

        I don't think it does. It seems to me to be explaining how to get your dll's to export symbols. You can:
        1) Use -export-all-symbols which is apparently the default, and will export all symbols;
        2) Use a def file - which turns off -export-all-symbols and exports only those symbols specified in the def file;
        3)Mark the symbols to be exported with __declspec(dllexport) - which turns off -export-all-symbols and exports only those symbols marked as __declspec(dllexport).

        I'm already using the second method to successfully export all symbols. I can't see that there would be anything to be achieved by using the first method instead. The symbols are already being exported - the problem (though I regard it more as a *puzzle* than a problem) seems to be something else.

        Thanks for the link - it's a rather straghtforward and informative explanation.

        Cheers,
        Rob
[reply]
[d/l]
[select]

In Section Meditations