Can I persuade EU::MM to compile a helper utility without looking for XS to build?
For example, given the following:
Makefile.PL
helper.c
example.pl
lib/App/Example.pm
... a make on the generated Makefile tries to work with a dynamic library:
$:- cat Makefile.PL
use ExtUtils::MakeMaker;
WriteMakefile(
NAME => 'App::Example',
VERSION_FROM => 'lib/App/Example.pm', # finds $VERSION
);
$:- perl Makefile.PL
Checking if your kit is complete...
Looks good
Writing Makefile for App::Example
$:- make
cp lib/App/Example.pm blib/lib/App/Example.pm
AutoSplitting blib/lib/App/Example.pm (blib/lib/auto/App/Example)
Running Mkbootstrap for App::Example ()
chmod 644 Example.bs
rm -f blib/arch/auto/App/Example/Example.so
gcc -shared .... Example.o -o blib/arch/auto/App/Example/Example.so \
\
gcc: Example.o: No such file or directory
gcc: no input files
make: *** [blib/arch/auto/App/Example/Example.so] Error 1
What I'd ultimately like is to have helper built and installed under /usr/bin, example.pl under /usr/sbin, and App::Example under $Config{vendorlib}. However, I need the pure perl modules "built" correctly first. Playing with C and EXE_FILES directives didn't change this behavior.
Related
(Disclaimer: I am not at all a computer science genius, far from that. I may use bad terminology and I appologize.)
I need to run some tests using the google test library and I was provided with a Makefile to handle the execution but it won't run on my Windows machine (I use Visual Studio). It was made for a Linux environment so I'm not sure what i would need to modify in order to run it. I have used MinGW to run Makefiles of my own making in the past.
Here's how the Makefile looks like:
CC=g++
CFLAGS=-c -Wall -ggdb -I.
LDFLAGS=
SOURCES=main.c singlelinklist.c
TESTS=single_test.cpp
#TODO: Need a more elegant way of specifying objects and tests
GTESTDIR=~/environment/googletest
OBJECTS=$(SOURCES:.cpp=.o)
FLAGS = -Iinclude
#all: $(SOURCES) $(EXECUTABLE)
# These next lines do a bit of magic found from http://stackoverflow.com/questions/2394609/makefile-header-dependencies
# Essentially it asks the compiler to read the .cpp files and generate the needed .h dependencies.
# This way if any .h file changes the correct .cpp files will be recompiled
depend: .depend
.depend: $(SOURCES)
rm -f ./.depend
$(CC) $(CFLAGS) -MM $^ >> ./.depend;
include .depend
# End .h file magic
#$(EXECUTABLE): $(OBJECTS)
# $(CC) $(LDFLAGS) $(OBJECTS) -o $#
#.cpp.o:
# $(CC) $(CFLAGS) $< -o $#
clean:
# rm -rf *o $(EXECUTABLE) test_executable
rm -f ./.depend
rm $(GTESTDIR)/libgtest.a
rm $(GTESTDIR)/gtest-all.o
# Google test section
$(GTESTDIR)/libgtest.a:
$(CC) -isystem $(GTESTDIR) -I $(GTESTDIR) -pthread -c $(GTESTDIR)/gtest/gtest-all.cc -o $(GTESTDIR)/gtest-all.o
ar -rv $(GTESTDIR)/libgtest.a $(GTESTDIR)/gtest-all.o
# This will also recompile if any source file is changed.
test_executable: $(GTESTDIR)/libgtest.a $(TESTS) depend
$(CC) -isystem $(GTESTDIR) -pthread -ggdb $(TESTS) $(GTESTDIR)/gtest/gtest_main.cc $(GTESTDIR)/libgtest.a -o test_executable
test: test_executable
./test_executable --gtest_print_time=0
And here's how my workspace is structured.
(Seems like I can't embed pictures).
I'm rebuilding a Windows 10 (64 bit) workstation from scratch, and I've hit a snag in building one particular CPAN module: true. This is a well-established module— it was last updated in 2011!— and I've used it for years on previous versions of Strawberry Perl, up to and including 5.26. I'm mystified as to what's going wrong.
I build the module as follows:
C:\Strawberry\cpan\build\true-0.18-0> perl Makefile.PL
Checking if your kit is complete...
Looks good
Generating a gmake-style Makefile
Writing Makefile for true
Writing MYMETA.yml and MYMETA.json
C:\Strawberry\cpan\build\true-0.18-0> gmake
cp lib/true/VERSION.pm blib\lib\true\VERSION.pm
cp lib/true.pm blib\lib\true.pm
Running Mkbootstrap for true ()
"C:\Strawberry\perl\bin\perl.exe" -MExtUtils::Command -e chmod -- 644 "true.bs"
"C:\Strawberry\perl\bin\perl.exe" -MExtUtils::Command::MM -e cp_nonempty -- true.bs blib\arch\auto\true\true.bs 644
"C:\Strawberry\perl\bin\perl.exe" "C:\Strawberry\perl\lib\ExtUtils/xsubpp" -typemap C:\STRAWB~1\perl\lib\ExtUtils\typemap true.xs > true.xsc
"C:\Strawberry\perl\bin\perl.exe" -MExtUtils::Command -e mv -- true.xsc true.c
gcc -c -IC:\Strawberry\perl\site\lib\B\Hooks\OP\Annotation\Install -IC:\Strawberry\perl\vendor\lib\B\Hooks\OP\Check\Install -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -D__USE_MINGW_ANSI_STDIO -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields -O3 -Wall -W -DVERSION=\"0.18\" -DXS_VERSION=\"0.18\" "-IC:\STRAWB~1\perl\lib\CORE" true.c
In file included from true.xs:4:0:
true.xs: In function 'true_leave':
C:\STRAWB~1\perl\lib\CORE/perl.h:174:22: warning: unused parameter 'my_perl' [-Wunused-parameter]
# define pTHX tTHX my_perl PERL_UNUSED_DECL
^
true.xs:25:24: note: in expansion of macro 'pTHX'
STATIC void true_leave(pTHX) {
^
"C:\Strawberry\perl\bin\perl.exe" -MExtUtils::Mksymlists \
-e "Mksymlists('NAME'=>\"true\", 'DLBASE' => 'true', 'DL_FUNCS' => { }, 'FUNCLIST' => [], 'IMPORTS' => { }, 'DL_VARS' => []);"
g++ true.def -o blib\arch\auto\true\true.xs.dll -mdll -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib" true.o "C:\STRAWB~1\perl\lib\CORE\libperl528.a" "C:\Strawberry\perl\site\lib\auto\B\Hooks\OP\Annotation\Annotation.a" "C:\Strawberry\perl\vendor\lib\auto\B\Hooks\OP\Check\Check.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libmoldname.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libkernel32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libuser32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libgdi32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libwinspool.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libcomdlg32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libadvapi32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libshell32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libole32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\liboleaut32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libnetapi32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libuuid.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libws2_32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libmpr.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libwinmm.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libversion.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libodbc32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libodbccp32.a" "C:\STRAWB~1\c\x86_64-w64-mingw32\lib\libcomctl32.a" -Wl,--enable-auto-image-base
"C:\Strawberry\perl\bin\perl.exe" -MExtUtils::Command -e chmod -- 755 blib\arch\auto\true\true.xs.dll
dlltool --def true.def --output-lib blib\arch\auto\true/true.a --dllname true.xs.dll blib\arch\auto\true\true.xs.dll
I don't know if the warning about pTHX is significant or ignorable. Anyhow, it does generate an output file true.xs.dll:
C:\Strawberry\cpan\build\true-0.18-0> dir blib\arch\auto\true\true.xs.dll
Volume in drive C is Local SSD Disk
Volume Serial Number is B4E3-5132
Directory of C:\Strawberry\cpan\build\true-0.18-0\blib\arch\auto\true
01/23/2019 09:53 17,920 true.xs.dll
1 File(s) 17,920 bytes
0 Dir(s) 873,458,094,080 bytes free
But the file is unusable:
C:\Strawberry\cpan\build\true-0.18-0> perl -I blib\arch\auto -Iblib\arch\auto\true -I blib\lib\auto -I blib\lib\ -Mtrue
Can't load 'blib\arch\auto\true/true.xs.dll' for module true: load_file:The specified module could not be found at C:/Strawberry/perl/lib/DynaLoader.pm line 193.
at - line 0.
Compilation failed in require.
BEGIN failed--compilation aborted.
The documentation on Dynaloader doesn't really help, but the code in Dynaloader.pm near line 193 does provide a hint:
# Many dynamic extension loading problems will appear to come from
# this section of code: XYZ failed at line 123 of DynaLoader.pm.
# Often these errors are actually occurring in the initialisation
# C code of the extension XS file. Perl reports the error as being
# in this perl code simply because this was the last perl code
# it executed.
So my working theory is that “something” changed in the latest Perl, causing code rot in the true module. But there's a flaw in my theory: at least one CPAN tester has successfully built true (although they did it with 32-bit perl).
I'm at a loss. Anyone got any ideas I can try?
I'm not sure whether to post this as an answer or not, but it is at least a resolution. After spending a day and a half of snooping through source code and trying various experiments, I gave up, removed the 64-bit Strawberry 5.28.1, and installed 32-bit Strawberry 5.28.1. Then true built, tested, and installed like a champ.
My only guess (and it's a wild guess) is that some part of the process was somehow finding and interacting with some 32-bit binaries on the network— although I expressly did not have PERL5LIB or other Perl env vars set, and nothing in my PATH pointed to any network Perl stuff.
But I don't have time to investigate this any further, and 32-bit Perl is good enough for what I do. A big thank you to #Corion and #ikegami for their time and comments.
I'm trying to build lstrip, a Lua utility for compressing Lua source code. I'm trying to build for Lua 5.1.3 on OS X v10.10.3.
I have downloaded and extracted the Lua 5.1.3 source code and modified the Makefile for lstrip to point to this directory. However, when I run make, I get this output:
cc -I/usr/local/src/lua-5.1.3/src -I/usr/local/src/lua-5.1.3/src -O2 -Wall -Wextra -O2 -c -o lstrip.o lstrip.c
lstrip.c:33:14: warning: unused parameter 'argc' [-Wunused-parameter]
int main(int argc, char* argv[])
^
1 warning generated.
sed '/void luaX_next/i#include "proxy.c"' /usr/local/src/lua-5.1.3/src/llex.c > llex.c
sed: 1: "/void luaX_next/i#inclu ...": command i expects \ followed by text
make: *** [llex.c] Error 1
This is what the relevant Makefile command looks like:
llex.c:
sed '/void luaX_next/i#include "proxy.c"' $(LUASRC)/$# > $#
I think that this is because the # in the sed command is being treated like an actual comment, but I'm not sure.
How can I fix the Makefile, or manually run the steps, to get lstrip built?
Full copy of the Makefile follows, in case it matters:
# makefile for lstrip
# change these to reflect your Lua installation (Lua 5.1!)
LUA= /usr/local/src/lua-5.1.3
LUAINC= $(LUA)/src
LUALIB= $(LUA)/src
LUASRC= $(LUA)/src
# no need to change anything below here
CFLAGS= $(INCS) $(WARN) -O2 $G
WARN= -O2 -Wall -Wextra
INCS= -I$(LUAINC) -I$(LUASRC)
LIBS= -L$(LUALIB) -llua -lm
MYNAME= lstrip
MYLIB= $(MYNAME)
T= $(MYNAME)
OBJS= $(MYNAME).o llex.o
TEST= test.lua
all: test
test: $T
$T $(TEST)
$T: $(OBJS)
$(CC) -o $# $(OBJS) $(LIBS)
llex.c:
sed '/void luaX_next/i#include "proxy.c"' $(LUASRC)/$# > $#
llex.o: proxy.c
clean:
-rm -f $(OBJS) core core.* a.out $(MYNAME)
# eof
Hand-build solution:
cp /usr/local/src/lua-5.1.3/src/llex.c .
Hand-edit llex.c to add the line #include "proxy.c" before the line starting with void luaX_next (line 446 for me).
Now run make, which will succeed.
You can find the answer in the sed manual, and it is in the Makefile lines
llex.c:
sed '/void luaX_next/i#include "proxy.c"' $(LUASRC)/$# > $#
Some variable expansion takes place here:
$(LUASRC) is expanded to the variable set above -> $(LUA)/src. Recurse as needed.
$# is replaced with the current target (llex.c)
So this recipe says:
In order to obtain the target llex.c (which will be processed later through other recipes), apply a stream editing command to the file $LUASRC/llex.c and write it to llex.c.
The stream editing command is: look for text "void luaX_next", before printing it, insert line "#include "proxy.c"".
Problem is, the command to do this is not "i" but "i\(newline)", which conflicts with a requirement of Makefiles that recipes must be on a single line.
I suspect that in order to fix your Makefile you need to use a different command than sed; awk can fit the bill although it's a bit more complex.
This line works in Mac OS X and in Linux:
sed '/void luaX_next/{h;s/.*/#include "proxy.c"/;p;g;}' $(LUASRC)/$# > $#
I am trying to install PAR::Packer on a Windows system. I tried "cpanm -n PAR::Packer --force" but got the following dump. I don't even understand what it is trying to do in my GnuPgp directory, but apparently there is a problem with blank spaces in its path?
Thanks!
Configuring PAR-Packer-1.019
Running Makefile.PL
Checking if your kit is complete...
Looks good
Prototype mismatch: sub main::prompt: none vs ($;$) at C:/Dwimperl/perl/lib/ExtUtils/MakeMaker.pm line 219
Writing Makefile for par.exe
Writing MYMETA.yml and MYMETA.json
Writing Makefile for PAR::Packer
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have Compress::Zlib 1.16 ... Yes (2.042)
Checking if you have Archive::Zip 1 ... Yes (1.30)
Checking if you have ExtUtils::MakeMaker 6.59 ... Yes (6.62)
Checking if you have Getopt::ArgvFile 1.07 ... Yes (1.11)
Checking if you have IO::Compress::Gzip 0 ... Yes (2.042)
Checking if you have PAR 1.005 ... Yes (1.007)
Checking if you have PAR::Dist 0.22 ... Yes (0.48)
Checking if you have ExtUtils::Embed 0 ... Yes (1.30)
Checking if you have File::Temp 0.05 ... Yes (0.22)
Checking if you have Win32::Process 0 ... Yes (0.14)
Checking if you have Parse::Binary 0.04 ... Yes (0.11)
Checking if you have Module::ScanDeps 1.09 ... Yes (1.13)
Checking if you have Win32::Exe 0.17 ... Yes (0.17)
Building PAR-Packer-1.019
cp lib/App/Packer/PAR.pm blib\lib\App\Packer\PAR.pm
cp lib/PAR/Packer.pm blib\lib\PAR\Packer.pm
cp lib/PAR/Filter/Obfuscate.pm blib\lib\PAR\Filter\Obfuscate.pm
cp lib/PAR/Filter/PodStrip.pm blib\lib\PAR\Filter\PodStrip.pm
cp lib/PAR/StrippedPARL/Base.pm blib\lib\PAR\StrippedPARL\Base.pm
cp lib/PAR/Filter.pm blib\lib\PAR\Filter.pm
cp lib/PAR/Filter/PatchContent.pm blib\lib\PAR\Filter\PatchContent.pm
cp lib/PAR/Filter/Bytecode.pm blib\lib\PAR\Filter\Bytecode.pm
cp lib/pp.pm blib\lib\pp.pm
cp lib/PAR/Filter/Bleach.pm blib\lib\PAR\Filter\Bleach.pm
C:\Dwimperl\perl\bin\perl.exe par_pl2c.pl my_par_pl < ..\script\par.pl > my_par_pl.c
C:\Dwimperl\perl\bin\perl.exe sha1.c.PL
gcc -c -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -I"C:\Dwimperl\perl\lib\CORE" -DPARL_EXE=\"parl.exe\" -s -O2 main.c
main.c: In function 'main':
main.c:121: warning: assignment discards qualifiers from pointer target type
windres -i winres/pp.rc -o ppresource.coff --input-format=rc --output-format=coff --target=pe-i386
g++ main.o ppresource.coff -s -s -L"C:\Dwimperl\perl\lib\CORE" -L"C:\Dwimperl\c\lib" C:\Dwimperl\perl\lib\CORE\libperl514.a C:\Dwimperl\c\i686-w64-mingw32\lib\libmoldname.a C:\Dwimperl\c\i686-w64-mingw32\lib\libkernel32.a C:\Dwimperl\c\i686-w64-mingw32\lib\libuser32.a C:\Dwimperl\c\i686-w64-mingw32\lib\libgdi32.a C:\Dwimperl\c\i686-w64-mingw32\lib\libwinspool.a C:\Dwimperl\c\i686-w64-mingw32\lib\libcomdlg32.a C:\Dwimperl\c\i686-w64-mingw32\lib\libadvapi32.a C:\Dwimperl\c\i686-w64-mingw32\lib\libshell32.a C:\Dwimperl\c\i686-w64-mingw32\lib\libole32.a C:\Dwimperl\c\i686-w64-mingw32\lib\liboleaut32.a C:\Dwimperl\c\i686-w64-mingw32\lib\libnetapi32.a C:\Dwimperl\c\i686-w64-mingw32\lib\libuuid.a C:\Dwimperl\c\i686-w64-mingw32\lib\libws2_32.a C:\Dwimperl\c\i686-w64-mingw32\lib\libmpr.a C:\Dwimperl\c\i686-w64-mingw32\lib\libwinmm.a C:\Dwimperl\c\i686-w64-mingw32\lib\libversion.a C:\Dwimperl\c\i686-w64-mingw32\lib\libodbc32.a C:\Dwimperl\c\i686-w64-mingw32\lib\libodbccp32.a C:\Dwimperl\c\i686-w64-mingw32\lib\libcomctl32.a -o par.exe
rem
C:\Dwimperl\perl\bin\perl.exe encode_append.pl Dynamic.in par.exe Dynamic.pm
C:\Dwimperl\perl\bin\perl.exe file2c.pl -c 30000 par.exe C:\Dwimperl\perl\bin\perl514.dll C:\Dwimperl\perl\bin\libgcc_s_sjlj-1.dll C:\Program Files (x86)\GNU\GnuPG\pub\libstdc++-6.dll > boot_embedded_files.c
open input file 'C:\Program': No such file or directory at file2c.pl line 43.
dmake: Error code 130, while making 'boot_embedded_files.c'
dmake: 'boot_embedded_files.c' removed.
dmake.exe: Error code 255, while making 'subdirs'
-> FAIL Installing PAR::Packer failed. See C:\Users\user\.cpanm\work\1406015074.8672\build.log for details. Retry with --force to force install it.
From your output, you can see the commands which the Makefile is executing. This one:
C:\Dwimperl\perl\bin\perl.exe file2c.pl -c 30000 par.exe C:\Dwimperl\perl\bin\perl514.dll C:\Dwimperl\perl\bin\libgcc_s_sjlj-1.dll C:\Program Files (x86)\GNU\GnuPG\pub\libstdc++-6.dll > boot_embedded_files.c
appears to attempt to pass this filename:
C:\Program Files (x86)\GNU\GnuPG\pub\libstdc++-6.dll
as a command-line argument, but does not quote it. The called program therefore attempts to open file C:\Program and fails. The fault probably lies somewhere within the build process, where a value should have been quoted, but wasn't. You might be able to work round it by executing the command correctly quoted:
C:\Dwimperl\perl\bin\perl.exe file2c.pl -c 30000 par.exe C:\Dwimperl\perl\bin\perl514.dll C:\Dwimperl\perl\bin\libgcc_s_sjlj-1.dll "C:\Program Files (x86)\GNU\GnuPG\pub\libstdc++-6.dll" > boot_embedded_files.c
and then rerunning make to allow it to build the rest. But this approach is not guaranteed to work.
However, the package seems to be being maintained, with the changelog for the most recent version here:
http://cpansearch.perl.org/src/RSCHUPP/PAR-Packer-1.020/ChangeLog
and evidence from the bug tracker that some issues are being resolved:
https://rt.cpan.org/Public/Dist/Display.html?Status=Resolved;Name=PAR-Packer
I suggest you report this bug there, and see whether the maintainers are able to provide a fix.
I'm trying to write a Makefile which should download some sources if and only if they are missing.
Something like:
hello: hello.c
gcc -o hello hello.c
hello.c:
wget -O hello.c http://example.org/hello.c
But of course this causes hello.c to be downloaded every time make command is run. I would like hello.c to be downloaded by this Makefile only if it is missing. Is this possible with GNU make and how to do this if it is?
My guess is that wget doesn't update the timestamp on hello.c, but retains the remote timestamp. This causes make to believe that hello.c is old and attempts to download it again. Try
hello.c:
wget ...
touch $#
EDIT: The -N option to wget will prevent wget from downloading anything unless the remote file is newer (but it'll still check the timestamp of the remote file, of course.)
Since the Makefile should be working as you want, you need to check a few unlikely cases:
1) Check that you don't have any .PHONY rules mentioning the source file.
2) Check that the source target name matches the file path you are downloading.
You could also try running make -d to see why make thinks it needs to 're-build' the source file.
The Makefile you wrote downloads hello.c only if it's missing. Perhaps you are doing something else wrong? See for example:
hello: hello.c
gcc -o hello hello.c
hello.c:
echo 'int main() {}' > hello.c
And:
% make
echo 'int main() {}' > hello.c
gcc -o hello hello.c
% rm hello
% make
gcc -o hello hello.c
% rm hello*
% make
echo 'int main() {}' > hello.c
gcc -o hello hello.c
(the echo command was not executed the second time)
If the prerequisite for hello.c has changed or is empty and Make continues to download the file when it exists, then one option to prevent Make from re-downloading the file is to use a flag in the body of the target to detect if the file exists:
hello.c:
test -f $# || wget -O hello.c http://example.org/hello.c
The test command will return true if the hello.c file exists, otherwise it will return false and the wget command will run.