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

Making GDBM_File, NDBM_File and ODBM_File dual live #14338

Closed
p5pRT opened this issue Dec 16, 2014 · 5 comments
Closed

Making GDBM_File, NDBM_File and ODBM_File dual live #14338

p5pRT opened this issue Dec 16, 2014 · 5 comments
Labels
distro-mswin32 type-core

Comments

@p5pRT
Copy link

p5pRT commented Dec 16, 2014

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

Searchable as RT123437$
@p5pRT
Copy link
Author

p5pRT commented Dec 16, 2014

From @kmx

Created by @kmx

I would like to suggest $SUBJECT

The fact that GDBM_File, NDBM_File and ODBM_File are core only makes them
hard to build especially on MS Windows because you have to do an undocumented
manual patching of win32\FindExt.pm

For non-Windows users the trouble with these modules is that you have to have
required external library (gdbm) available at the time when you build perl
core as there is no chance to install these modules later from CPAN.

I have found related comments in this thread​:
http​://www.nntp.perl.org/group/perl.perl5.porters/2013/05/msg202474.html

--
kmx

Perl Info 

Flags:
     category=core
     severity=low

Site configuration information for perl 5.20.1:

Configured by strawberry-perl at Mon Sep 15 13:28:28 2014.

Summary of my perl5 (revision 5 version 20 subversion 1) configuration:

   Platform:
     osname=MSWin32, osvers=6.3, archname=MSWin32-x64-multi-thread
     uname='Win32 strawberry-perl 5.20.1.1 #1 Mon Sep 15 13:26:45 2014 x64'
     config_args='undef'
     hint=recommended, useposix=true, d_sigaction=undef
     useithreads=define, usemultiplicity=define
     use64bitint=define, use64bitall=undef, uselongdouble=undef
     usemymalloc=n, bincompat5005=undef
   Compiler:
     cc='gcc', ccflags =' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE 
-DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS 
-DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields',
     optimize='-s -O2',
     cppflags='-DWIN32'
     ccversion='', gccversion='4.8.3', gccosandvers=''
     intsize=4, longsize=4, ptrsize=8, doublesize=8, byteorder=12345678
     d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
     ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='long 
long', lseeksize=8
     alignbytes=8, prototype=define
   Linker and Libraries:
     ld='g++.exe', ldflags ='-s -L"C:\tmp64\perl\lib\CORE" -L"C:\tmp64\c\lib"'
     libpth=C:\tmp64\c\lib C:\tmp64\c\x86_64-w64-mingw32\lib 
C:\tmp64\c\lib\gcc\x86_64-w64-mingw32\4.8.3
     libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr 
-lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
     perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr 
-lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
     libc=, so=dll, useshrplib=true, libperl=libperl520.a
     gnulibc_version=''
   Dynamic Linking:
     dlsrc=dl_win32.xs, dlext=xs.dll, d_dlsymun=undef, ccdlflags=' '
     cccdlflags=' ', lddlflags='-mdll -s -L"C:\tmp64\perl\lib\CORE" 
-L"C:\tmp64\c\lib"'



@INC for perl 5.20.1:
     C:/tmp64/perl/site/lib
     C:/tmp64/perl/vendor/lib
     C:/tmp64/perl/lib
     .


Environment for perl 5.20.1:
     HOME=C:\tmp64\data
     LANG (unset)
     LANGUAGE (unset)
     LD_LIBRARY_PATH (unset)
     LOGDIR (unset)
PATH=C:\tmp64\perl\site\bin;C:\tmp64\perl\bin;C:\tmp64\c\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
     PERL_BADLANG (unset)
     SHELL (unset)

@p5pRT
Copy link
Author

p5pRT commented Jan 7, 2015 •
edited by toddr

From @tonycoz

Are you volunteering to package them for CPAN?

If you are, I think it's only permissions and moving some files around.

You'd need permissions on PAUSE for the modules to appear in the index and we'd need to move the dists into dist/ or cpan/, depending on whether you'd prefer them to be blead or CPAN upstream.

You should be able to upload dists before you have permissions, and then Force Reindexing once you have the permissions.

I can't think of any reason not to have them on CPAN.

Tony

@p5pRT
Copy link
Author

p5pRT commented Jan 7, 2015

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

@toddr
Copy link
Member

toddr commented Feb 13, 2020 •
edited

Comment from Nicholas Clark on the topic.

I believe in the past it's been mentioned that GDBM_File, NDBM_File and
ODBM_File not being dual life is a pain because you can't build them
after you've already installed perl. Which can matter, if you installed
perl before you realised that you didn't have the development headers in
place (or your upstream binary provider did not).

SDBM_File does not have this problem as it has no external dependencies.
AnyDBM_file needs to stay in the core as it's part of the implementation
of dbmopen.

In relation to this, previously I'd said that it would be fine if someone
wanted to make GDBM_File, NDBM_File and ODBM_File dual life.

No-one volunteered.

@toddr
Copy link
Member

toddr commented Feb 13, 2020

I think the answer on this is no until someone steps up. I conclude there's nothing left to do in this case.

@toddr toddr closed this as completed Feb 13, 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 type-core
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@toddr @p5pRT