FAQ
The cflags part is the only blocking issue on cygwin. Needed since 5.10.0

--
Reini Urban

Search Discussions

  • Steffen Mueller at Aug 24, 2010 at 9:01 am
    Hi Reini,

    Reini Urban wrote:
    The cflags part is the only blocking issue on cygwin. Needed since 5.10.0

    I'm not sure I follow the second part of your patch. In DynaLoader's
    Makefile.PL, you add:

    +sub MY::cflags {
    + package MY;
    + my $flags = shift->SUPER::cflags(@_);
    + if ($flags =~ /-DUSEIMPORTLIB/m) {
    + $flags =~ s/-DUSEIMPORTLIB/-UUSEIMPORTLIB/m;
    + }
    + $flags;
    +}


    I wonder
    a) what USEIMPORTLIB does in the first place (grep doesn't come up with
    copious docs)
    b) if it is wise to more or less unconditionally remove it.
    c) why you're doing the if() if s/// simply not matching has the same
    effect.

    Finally, could you add a somewhat more descriptive commit message? It's
    not clear to me and I believe that will apply to a lot of other people
    as well.

    Cheers,
    Steffen
  • Reini Urban at Aug 24, 2010 at 11:52 am

    2010/8/24 Steffen Mueller <smueller@cpan.org>:
    Reini Urban wrote:
    The cflags part is the only blocking issue on cygwin. Needed since 5.10.0
    I'm not sure I follow the second part of your patch. In DynaLoader's
    Makefile.PL, you add:

    +sub MY::cflags {
    +  package MY;
    +  my $flags = shift->SUPER::cflags(@_);
    +  if ($flags =~ /-DUSEIMPORTLIB/m) {
    +    $flags =~ s/-DUSEIMPORTLIB/-UUSEIMPORTLIB/m;
    +  }
    +  $flags;
    +}


    I wonder
    a) what USEIMPORTLIB does in the first place (grep doesn't come up with
    copious docs)
    With -DUSEIMPORTLIB it simply fails, because the importlib symbolnames
    are used,
    e.g. __imp__PL_stack_sp and not the direct name _PL_stack_sp.

    g++-4 -o cygperl5_13_4-nt.dll --shared -Wl,--enable-auto-import
    -Wl,--export-all-symbols -Wl,--stack,8388608
    -Wl,--enable-auto-image-base -L/usr/local/lib -fstack-protector
    -Wl,--out-implib=libperl.dll.a -Wl,--image-base,0x52000000 op.o perl.o
    madly.o malloc.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o
    mg.o reentr.o mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o
    pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o
    universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o
    pp_pack.o pp_sort.o cygwin.o DynaLoader.o Win32CORE.o -ldl -lcrypt
    Creating library file: libperl.dll.a
    DynaLoader.o: In function `XS_DynaLoader_dl_undef_symbols':
    /usr/src/perl/blead/buildnothreads/ext/DynaLoader/DynaLoader.c:346:
    undefined reference to `__imp__PL_stack_sp'
    /usr/src/perl/blead/buildnothreads/ext/DynaLoader/DynaLoader.c:346:
    undefined reference to `__imp__PL_markstack_ptr'
    /usr/src/perl/blead/buildnothreads/ext/DynaLoader/DynaLoader.c:346:
    undefined reference to `__imp__PL_stack_base'
    DynaLoader.o: In function `XS_DynaLoader_dl_error':
    b) if it is wise to more or less unconditionally remove it.
    Yes. Using the importlib names can only link against the importlib
    (the .dll.a), but not against the libperl objects directly.

    From outside linking against libperl (the dll) is faster, and more
    flexible. All modern gcc linkers
    can link directly against a dll. Only Module::Build links against the
    .dll.a, all other extutils against libperl.
    c) why you're doing the if() if s/// simply not matching has the same
    effect.
    Just to be clear.
    Finally, could you add a somewhat more descriptive commit message? It's not
    clear to me and I believe that will apply to a lot of other people as well.
    Sure.
    --
    Reini Urban
    http://phpwiki.org/           http://murbreak.at/
  • Steffen Mueller at Aug 24, 2010 at 1:02 pm
    Hi Reini,

    thanks for your reply and clarifications.

    Reini Urban wrote:
    I wonder
    a) what USEIMPORTLIB does in the first place (grep doesn't come up with
    copious docs)
    With -DUSEIMPORTLIB it simply fails, because the importlib symbolnames
    are used,
    e.g. __imp__PL_stack_sp and not the direct name _PL_stack_sp.
    So -DUSEIMPORTLIB / -UUSEIMPORTLIB has an effect on the symbol names.
    Okay. Does this affect only cygwin? Should this affect only cygwin?
    What's the significance on other platforms?
    b) if it is wise to more or less unconditionally remove it.
    Yes. Using the importlib names can only link against the importlib
    (the .dll.a), but not against the libperl objects directly.

    From outside linking against libperl (the dll) is faster, and more
    flexible. All modern gcc linkers
    can link directly against a dll. Only Module::Build links against the
    ..dll.a, all other extutils against libperl.
    I'm not an expert in these matters, hence my questions. With
    "unconditionally", I was at least partly wondering whether it should be
    applied to cygwin (or win32+cygwin) only. Can you elaborate on that?
    c) why you're doing the if() if s/// simply not matching has the same
    effect.
    Just to be clear.
    Do be honest, it seems to obscure things only for someone who knows
    Perl. ("What's the significance of the extra condition? This must have
    been added for some effect!")

    Can you please just use a single s/.../.../m?
    Finally, could you add a somewhat more descriptive commit message? It's not
    clear to me and I believe that will apply to a lot of other people as well.
    Sure.
    Wow. That is indeed quite a long message now. Maybe skip the giant
    g++-linking part of the message.

    Best regards,
    Steffen
  • Reini Urban at Aug 24, 2010 at 2:47 pm

    2010/8/24 Steffen Mueller <smueller@cpan.org>:
    thanks for your reply and clarifications.

    Reini Urban wrote:
    I wonder
    a) what USEIMPORTLIB does in the first place (grep doesn't come up with
    copious docs)
    With -DUSEIMPORTLIB it simply fails, because the importlib symbolnames
    are used,
    e.g. __imp__PL_stack_sp and not the direct name _PL_stack_sp.
    So -DUSEIMPORTLIB / -UUSEIMPORTLIB has an effect on the symbol names. Okay.
    Does this affect only cygwin? Should this affect only cygwin? What's the
    significance on other platforms?
    It possibly affects every platform which adds DynaLoader static and
    uses importlibs.
    To my knowledge only AIX, cygwin and mingw do this.
    For cygwin we avoid importlibs for perl, but they are a nice to have, if
    someone does not know the exact dll name (though this is what libperl is for).
    On other POSIX platforms you do a symlink of libperl.so to the real
    so, so don't
    have to use the importlib jumps.
    b) if it is wise to more or less unconditionally remove it.
    Yes. Using the importlib names can only link against the importlib
    (the .dll.a), but not against the libperl objects directly.

    From outside linking against libperl (the dll) is faster, and more
    flexible. All modern gcc linkers
    can link directly against a dll. Only Module::Build links against the
    ..dll.a, all other extutils against libperl.
    I'm not an expert in these matters, hence my questions. With
    "unconditionally", I was at least partly wondering whether it should be
    applied to cygwin (or win32+cygwin) only. Can you elaborate on that?
    As said above. Linking statically with -DUSEIMPORTLIB is wrong, so it
    affects every platform. But I only got the linking error with cygwin.
    I guess mingw and AIX link in two steps, so they take the indirect route.
    Can some porter over there please comment?
    c) why you're doing the if() if s/// simply not matching has the same
    effect.
    Just to be clear.
    Do be honest, it seems to obscure things only for someone who knows Perl.
    ("What's the significance of the extra condition? This must have been added
    for some effect!")

    Can you please just use a single s/.../.../m? Ok.
    Finally, could you add a somewhat more descriptive commit message? It's
    not
    clear to me and I believe that will apply to a lot of other people as
    well.
    Sure.
    Wow. That is indeed quite a long message now. Maybe skip the giant
    g++-linking part of the message.
    But that's the important part :) I trimmed it to the essentials.
    --
    Reini Urban

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedAug 24, '10 at 8:39a
activeAug 24, '10 at 2:47p
posts5
users2
websiteperl.org

2 users in discussion

Reini Urban: 3 posts Steffen Mueller: 2 posts

People

Translate

site design / logo © 2022 Grokbase