Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add DynaLoader to perl.lib on Windows #13214

Closed
p5pRT opened this issue Aug 30, 2013 · 5 comments
Closed

Add DynaLoader to perl.lib on Windows #13214

p5pRT opened this issue Aug 30, 2013 · 5 comments
Labels
distro-mswin32 Feature Request type-install

Comments

@p5pRT
Copy link

p5pRT commented Aug 30, 2013

Migrated from rt.perl.org#119531 (status was 'open')

Searchable as RT119531$
@p5pRT
Copy link
Author

p5pRT commented Aug 30, 2013 •
edited by toddr

From @rurban

This is a bug report for perl from rurban@​cpanel.net,
generated with the help of perlbug 1.39 running under perl 5.19.4.

MSWin32 does not link DynaLoader.obj into the resulting perl*.dll

cygwin and all other platform do it. On Windows we have only
boot_DynaLoader exported, and any usage of those XS functions
  XS_DynaLoader_dl_error
  XS_DynaLoader_dl_find_symbol
  XS_DynaLoader_dl_install_xsub
  XS_DynaLoader_dl_load_file
  XS_DynaLoader_dl_undef_symbols
  XS_DynaLoader_dl_unload_file
must go through exceptionally ugly and slow eval_pv code via perl.

This is one of the main blockers for the new compiler release for Windows.

Perl Info 
-----------------------------------------------------------------
---
Flags:
category=install
severity=high
---
Site configuration information for perl 5.19.4:

Configured by rurban at Wed Aug 28 12:48:48 CDT 2013.

Summary of my perl5 (revision 5 version 19 subversion 4) configuration:
Commit id: 9d1b8531c075577f4961f374c1fe683ef9019c52
Platform:
osname=linux, osvers=3.9-1-amd64, archname=x86_64-linux-debug@9d1b8531
uname='linux reini 3.9-1-amd64 #1 smp debian 3.9.8-1 x86_64 gnulinux '
config_args='-de -Dusedevel -Uversiononly -Dinstallman1dir=none -Dinstallman3dir=none -Dinstallsiteman1dir=none -Dinstallsiteman3dir=none -DEBUGGING -Doptimize=-g3 -Uuseithreads -Accflags=''-msse4.2'' -Accflags=''-march=corei7'' -Dcf_email=''rurban@cpanel.net'' -Dperladmin=''rurban@cpanel.net'''
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-msse4.2 -march=corei7 -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-g3',
cppflags='-msse4.2 -march=corei7 -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.7.3', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.17'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -g3 -L/usr/local/lib -fstack-protector'


---
@INC for perl 5.19.4:
/usr/local/lib/perl5/site_perl/5.19.4/x86_64-linux-debug@9d1b8531
/usr/local/lib/perl5/site_perl/5.19.4
/usr/local/lib/perl5/5.19.4/x86_64-linux-debug@9d1b8531
/usr/local/lib/perl5/5.19.4
/usr/local/lib/perl5/site_perl/5.19.3
/usr/local/lib/perl5/site_perl/5.19.2
/usr/local/lib/perl5/site_perl/5.18.1
/usr/local/lib/perl5/site_perl/5.18.0
/usr/local/lib/perl5/site_perl/5.17.11
/usr/local/lib/perl5/site_perl/5.17.10
/usr/local/lib/perl5/site_perl/5.17.8
/usr/local/lib/perl5/site_perl/5.17.7
/usr/local/lib/perl5/site_perl/5.17.6
/usr/local/lib/perl5/site_perl/5.17.5
/usr/local/lib/perl5/site_perl/5.17.4
/usr/local/lib/perl5/site_perl/5.17.3
/usr/local/lib/perl5/site_perl/5.17.2
/usr/local/lib/perl5/site_perl/5.17.1
/usr/local/lib/perl5/site_perl/5.17.0
/usr/local/lib/perl5/site_perl/5.17
/usr/local/lib/perl5/site_perl/5.16.3
/usr/local/lib/perl5/site_perl/5.16.2
/usr/local/lib/perl5/site_perl/5.16.1
/usr/local/lib/perl5/site_perl/5.16.0
/usr/local/lib/perl5/site_perl/5.15.9
/usr/local/lib/perl5/site_perl/5.15.8
/usr/local/lib/perl5/site_perl/5.15.7
/usr/local/lib/perl5/site_perl/5.15.6
/usr/local/lib/perl5/site_perl/5.15.5
/usr/local/lib/perl5/site_perl/5.15.4
/usr/local/lib/perl5/site_perl/5.14.4
/usr/local/lib/perl5/site_perl/5.14.3
/usr/local/lib/perl5/site_perl/5.14.2
/usr/local/lib/perl5/site_perl/5.14.1
/usr/local/lib/perl5/site_perl/5.12.5
/usr/local/lib/perl5/site_perl/5.12.4
/usr/local/lib/perl5/site_perl/5.10.1
/usr/local/lib/perl5/site_perl/5.8.9
/usr/local/lib/perl5/site_perl/5.8.8
/usr/local/lib/perl5/site_perl/5.8.7
/usr/local/lib/perl5/site_perl/5.8.6
/usr/local/lib/perl5/site_perl/5.8.5
/usr/local/lib/perl5/site_perl/5.8.4
/usr/local/lib/perl5/site_perl/5.8.3
/usr/local/lib/perl5/site_perl/5.8.2
/usr/local/lib/perl5/site_perl/5.8.1
/usr/local/lib/perl5/site_perl/5.6.2
/usr/local/lib/perl5/site_perl
.

---
Environment for perl 5.19.4:
HOME=/home/rurban
LANG=en_US.UTF-8
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/home/rurban/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
PERL_BADLANG (unset)
SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Aug 30, 2013

From @jandubois

On Fri, Aug 30, 2013 at 10​:59 AM, rurban@​cpanel.net
<perlbug-followup@​perl.org> wrote​:

MSWin32 does not link DynaLoader.obj into the resulting perl*.dll

cygwin and all other platform do it. On Windows we have only
boot_DynaLoader exported, and any usage of those XS functions
XS_DynaLoader_dl_error
XS_DynaLoader_dl_find_symbol
XS_DynaLoader_dl_install_xsub
XS_DynaLoader_dl_load_file
XS_DynaLoader_dl_undef_symbols
XS_DynaLoader_dl_unload_file
must go through exceptionally ugly and slow eval_pv code via perl.

This does not make any sense to me. These functions are all in the
same compilation unit, so if boot_DynaLoader is there, then the file
must be included in perl*.dll.

Now, the XS_* symbols are indeed not exported, which is generally true
for *all* modules. It also generally doesn't make sense to export the
XS_* symbols, because they can't be called simply from C code anyways;
you want the corresponding plain C function without the XS wrapping.

There are multiple ways to get those symbols exported​:

* mark them with __declspec(dllexport) (I think we have a macro for that)
* export them via makedef.pl
* add them to FUNCLIST in the WriteMakefile() call

The symbols should get a Perl_ prefix and they should then also be
marked in embed.fnc as a public API, because that is what you are
proposing.

Cheers,
-Jan

@p5pRT
Copy link
Author

p5pRT commented Aug 30, 2013

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2013

From @bulk88

On Fri Aug 30 16​:08​:53 2013, jdb wrote​:

On Fri, Aug 30, 2013 at 10​:59 AM, rurban@​cpanel.net
<perlbug-followup@​perl.org> wrote​:

MSWin32 does not link DynaLoader.obj into the resulting perl*.dll

cygwin and all other platform do it. On Windows we have only
boot_DynaLoader exported, and any usage of those XS functions
XS_DynaLoader_dl_error
XS_DynaLoader_dl_find_symbol
XS_DynaLoader_dl_install_xsub
XS_DynaLoader_dl_load_file
XS_DynaLoader_dl_undef_symbols
XS_DynaLoader_dl_unload_file
must go through exceptionally ugly and slow eval_pv code via perl.

This does not make any sense to me. These functions are all in the
same compilation unit, so if boot_DynaLoader is there, then the file
must be included in perl*.dll.

Now, the XS_* symbols are indeed not exported, which is generally true
for *all* modules. It also generally doesn't make sense to export the
XS_* symbols, because they can't be called simply from C code anyways;

They can be called from C without going through libperl (call_*) but its
undocumented/unrecommended.

PUSHMARK(SP); XS_foo(aTHX_ some_cv_not_necessarily_foo);

Instead of exporting them, just do a get_cv(), check for null, then
check CvISXSUB, then do a CvXSUB(). Now you have the XSUB pointer. No
export table overhead in the perl dll.

--
bulk88 ~ bulk88 at hotmail.com

@toddr toddr added the Closable? We might be able to close this ticket, but we need to check with the reporter label Jan 31, 2020
@toddr toddr added Feature Request and removed Severity High distro-Linux Closable? We might be able to close this ticket, but we need to check with the reporter labels Feb 12, 2020
@toddr
Copy link
Member

toddr commented Feb 12, 2020

@bulk88 and @jandubois provided alternate fixes and no reply came after. Not seeing anything actionable here, I'm closing this.

@toddr toddr closed this as completed Feb 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
distro-mswin32 Feature Request type-install
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jkeenan @toddr @p5pRT