I am on a Mac so of course I'm running into this huge problem with perl on the Mac where the OS is trying to protect me and it's a nightmare to install . The solution seems to be "make your own perl instead of using the one with the OS" so I've done that. I ran brew install perl and now I have this in my .bashrc
PATH="/Users/ericmueller/perl5/bin${PATH:+:${PATH}}"; export PATH;
PERL5LIB="/Users/ericmueller/perl5/lib/perl5${PERL5LIB:+:${PERL5LIB}}"; export PERL5LIB;
PERL_LOCAL_LIB_ROOT="/Users/ericmueller/perl5${PERL_LOCAL_LIB_ROOT:+:${PERL_LOCAL_LIB_ROOT}}"; export PERL_LOCAL_LIB_ROOT;
PERL_MB_OPT="--install_base \"/Users/ericmueller/perl5\""; export PERL_MB_OPT;
PERL_MM_OPT="INSTALL_BASE=/Users/ericmueller/perl5"; export PERL_MM_OPT;
eval "$(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib=$HOME/perl5)"
source ~/perl5/perlbrew/etc/bashrceval "$(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib=$HOME/perl5)"
Honestly, I have no idea what most of this is ;-) but it looks like I have my own perl in my folder and I see that I can run simple perl scripts so I guess all is good.
So now I want to install cpanminus and DBI.
I installed cpanminus (brew install cpanminus), without errors. But then when I run cpanm DBI it fails, and when I look at the log where it failed, I see this:
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- DBI.bs blib/arch/auto/DBI/DBI.bs 644
"/usr/bin/perl" -p -e "s/~DRIVER~/Perl/g" ./Driver.xst > Perl.xsi
"/usr/bin/perl" "/System/Library/Perl/5.18/ExtUtils/xsubpp" -typemap '/System/Library/Perl/5.18/ExtUtils/typemap' -typemap '/Users/ericmueller/.cpanm/work/1555346710.17160/DBI-1.642/typemap' Perl.xs > Perl.xsc
mv Perl.xsc Perl.c
cc -c -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector -Os -DVERSION=\"1.642\" -DXS_VERSION=\"1.642\" "-I/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE" -W -Wall -Wpointer-arith -Wbad-function-cast -Wno-comment -Wno-sign-compare -Wno-cast-qual -Wmissing-noreturn -Wno-unused-parameter Perl.c
In file included from Perl.xs:7:
./DBIXS.h:22:10: fatal error: 'EXTERN.h' file not found
#include <EXTERN.h>
^~~~~~~~~~
1 error generated.
make: *** [Perl.o] Error 1
This is totally the stupid Mac perl problem, and the issue appears to be that it's still trying to put the DBI library (or one of its dependencies) in /usr/bin/ which is a big no-no. Or maybe it's trying to use the system perl to do the installation, so that's also failing. I have my own perl5 installation in my home folder. That's where it should be putting things and working with them.
So if that is the issue (and I am really shitty at both perl and this kind of sysadmin stuff, so I'm not 100% sure!), how do I get cpanm to work with my perl in my home folder, instead of in /usr/bin/? I don't want ANYTHING to happen in /usr/bin/ since that is a non-starter!
** EDIT I removed everything but the PATH command from my bashrc, and now I get this when I run cpanm DBI
!
! Can't write to /Library/Perl/5.18 and /usr/local/bin: Installing modules to /Users/ericmueller/perl5
! To turn off this warning, you have to do one of the following:
! - run me as a root or with --sudo option (to install to /Library/Perl/5.18 and /usr/local/bin)
! - Configure local::lib in your existing shell to set PERL_MM_OPT etc.
! - Install local::lib by running the following commands
!
! cpanm --local-lib=~/perl5 local::lib && eval $(perl -I ~/perl5/lib/perl5/ -Mlocal::lib)
!
--> Working on DBI
Fetching http://www.cpan.org/authors/id/T/TI/TIMB/DBI-1.642.tar.gz ... OK
Configuring DBI-1.642 ... OK
Building and testing DBI-1.642 ... FAIL
! Installing DBI failed. See /Users/ericmueller/.cpanm/work/1555348167.22814/build.log for details. Retry with --force to force install it.
So the good news is that I am definitely using the cpanm that comes with my custom perl5 in my /Users folder. The bad news is, I'm still getting the exact same stupid problem.
yep ... MacOS Perl is something you should rather not touch.
yes ... You can do it.
but ... Common practice, https://perlbrew.pl
and ... Install some shinny perl
and ... follow the instructions on the website about cpanm
Related
I am labouring since a while, to get rid of a conflict between the system Perl (MacOS, Catalina: v5.18.4) and the Homebrew Perl (v5.30.1). The modules are installed in ~/perl5
But I am realising, that also the system Perl uses for the modules ~/perl5
Here are some infos from my Shell (zsh):
which perl
/usr/local/bin/perl
ls -l /usr/local/bin/perl
lrwxr-xr-x 1 mstep admin 30 11 Jan 19:17 /usr/local/bin/perl -> ../Cellar/perl/5.30.1/bin/perl
Thats the Perl from Homebrew (v5.30.1). Some other infos from the System-Perl and
env | grep PERL
PERL5LIB=/Users/mstep/perl5/lib/perl5
PERL_LOCAL_LIB_ROOT=/Users/mstep/perl5
PERL_MB_OPT=--install_base "/Users/mstep/perl5"
PERL_MM_OPT=INSTALL_BASE=/Users/mstep/perl5
/usr/bin/perl -V
...
%ENV:
PERL5LIB="/Users/mstep/perl5/lib/perl5"
PERL_LOCAL_LIB_ROOT="/Users/mstep/perl5"
PERL_MB_OPT="--install_base "/Users/mstep/perl5""
PERL_MM_OPT="INSTALL_BASE=/Users/mstep/perl5"
#INC:
/Users/mstep/perl5/lib/perl5/5.18.4/darwin-thread-multi-2level
/Users/mstep/perl5/lib/perl5/5.18.4
/Users/mstep/perl5/lib/perl5/darwin-thread-multi-2level
/Users/mstep/perl5/lib/perl5
/Library/Perl/5.18/darwin-thread-multi-2level
/Library/Perl/5.18
...
perl -e 'print join("\n",#INC)'
/Users/mstep/perl5/lib/perl5/5.30.1/darwin-thread-multi-2level
/Users/mstep/perl5/lib/perl5/5.30.1
/Users/mstep/perl5/lib/perl5/darwin-thread-multi-2level
/Users/mstep/perl5/lib/perl5
/usr/local/Cellar/perl/5.30.1/lib/perl5/site_perl/5.30.1/darwin-thread-multi-2level
/usr/local/Cellar/perl/5.30.1/lib/perl5/site_perl/5.30.1
/usr/local/Cellar/perl/5.30.1/lib/perl5/5.30.1/darwin-thread-multi-2level
/usr/local/Cellar/perl/5.30.1/lib/perl5/5.30.1
/usr/local/lib/perl5/site_perl/5.30.1
In my .zshrc file I tried everything to no avail; just for now, I commented everything out:
# PERL_MM_OPT="INSTALL_BASE=$HOME/perl5" cpan local::lib
# eval "$(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib=$HOME/perl5)"
# eval "$(perl -I$HOME/perl5/lib/perl5 -Mlocal::lib)"
# PATH="/Users/mstep/perl5/bin${PATH:+:${PATH}}"; export PATH;
# PERL5LIB="/Users/mstep/perl5/lib/perl5${PERL5LIB:+:${PERL5LIB}}"; export PERL5LIB;
# PERL_LOCAL_LIB_ROOT="/Users/mstep/perl5${PERL_LOCAL_LIB_ROOT:+:${PERL_LOCAL_LIB_ROOT}}"; export PERL_LOCAL_LIB_ROOT;
# PERL_MB_OPT="--install_base \"/Users/mstep/perl5\""; export PERL_MB_OPT;
# PERL_MM_OPT="INSTALL_BASE=/Users/mstep/perl5"; export PERL_MM_OPT;
# PERL_MM_OPT="INSTALL_BASE=/Users/mstep/perl5"; export PERL_MM_OPT;
# PERL_MM_OPT="INSTALL_BASE=$HOME/perl5" cpan local::lib
Every time I am starting my ZSH it starts with installing Running install for module 'local::lib' and ZSH is complaining, that YAML is not installed, finishing with the following error; if I leave some lines of perl5-definition in my .zshrc it is even issuing this error twice:
Dumper.c: loadable library and perl binaries are mismatched (got handshake key 0xc500080, needed 0xc400080)
How to educate the system perl, to use the right module folder? I would be very grateful for any help!
marek
ps: Thx for your answers:
find /Users/mstep/perl5/lib/perl5 -name '*Dumper*' /Users/mstep/perl5/lib/perl5/PPIx/Regexp/Dumper.pm
/Users/mstep/perl5/lib/perl5/PPIx/QuoteLike/Dumper.pm
/Users/mstep/perl5/lib/perl5/Module/Build/Dumper.pm
/Users/mstep/perl5/lib/perl5/darwin-thread-multi-2level/.meta/Data-Dumper-2.173
/Users/mstep/perl5/lib/perl5/darwin-thread-multi-2level/auto/Data/Dumper
/Users/mstep/perl5/lib/perl5/darwin-thread-multi-2level/auto/Data/Dumper/Dumper.bundle
/Users/mstep/perl5/lib/perl5/darwin-thread-multi-2level/DBI/ProfileDumper.pm
/Users/mstep/perl5/lib/perl5/darwin-thread-multi-2level/DBI/Gofer/Serializer/DataDumper.pm
/Users/mstep/perl5/lib/perl5/darwin-thread-multi-2level/DBI/ProfileDumper
/Users/mstep/perl5/lib/perl5/darwin-thread-multi-2level/Data/Dumper.pm
/Users/mstep/perl5/lib/perl5/YAML/Dumper.pm
/Users/mstep/perl5/lib/perl5/YAML/Dumper.pod
/Users/mstep/perl5/lib/perl5/YAML/Dumper
/Users/mstep/perl5/lib/perl5/PPI/Dumper.pm
I recently had this issue, so thought I'd post the solution here as I couldn't find it anywhere.
The issue was a broken cpanm install (recipe?) from brew - the first line of which (the shebang of /usr/local/bin/cpanm) was using the system perl.
I had to run
brew reinstall cpanm
because the problem is now fixed in that recipe, though the version was not bumped.
I could then reinstall my perl modules (e.g. cpanm --reinstall JSON::XS) to get things working.
I want to edit some code in cygwin1.dll for my project. So, I clone git repository from these two url:
https://github.com/mirror/newlib-cygwin.git
git://sourceware.org/git/newlib-cygwin.git
I've gcc, g++, make installed with cygwin and mingw-w64 (and also in WSL). But none of them generate DLL file. I also follow the commands ./configure & make. Command generates only object files. Is it possible to compile cygwin1.dll from its source code?
I had two different problems.
First, I followed the steps in cygwin FAQ: How do I build Cygwin on my own?. I forget to install mingww64_x86_64-gcc-g++ package. So, I installed those with the following commands:
setup-x86_64.exe -q -P gcc-g++ -P make -P perl -P cocom -P gettext-devel -P libiconv-devel -P zlib-devel
setup-x86_64.exe -q -P mingw64-x86_64-gcc-core -P mingw64-i686-gcc-g++ -P mingw64-i686-zlib
setup-x86_64.exe -q -P mingw64-x86_64-gcc-g++ -P mingw64-x86_64-zlib
Second, I logged the output from make command with make |& tee make.log. Thanks, #matzeri for the logging tip. Then I followed an error in make.log file as below:
../../.././winsup/cygwin/cygmagic: line 25: /usr/bin/awk: cannot
execute binary file: Exec format error
*** WARNING WARNING WARNING WARNING WARNING ***
*** ../../.././winsup/cygwin/child_info.h: magic number for
CHILD_INFO_MAGIC changed old 0xc96f5e9U != new
Somehow, the awk (hard linked with gawk) does not work in cygwin. So I installed awk package with setup-x86_64.exe. And now I can easily compile cygwin.dll.
Here is my case:
I am using Ubuntu 10.04 (Lucid Lynx). The system's default Python is v2.6.5, but I need Python v2.7. So I downloaded the source from python.org and tried to install it.
The first time I installed it, I ran:
cd Python2.7.4
./configure --prefix=/usr
make
su root
make install
This installs Python 2.7 to my system. It will create a link, "python", in /usr/bin linking to python2.7 also in /usr/bin. So when I type >python, the system will start Python 2.7.4 for me just like when I type >python2.7.
But when I install this way:
cd Python2.7.4
./configure --prefix=/usr
make
su root
make altinstall
The link "python" in /usr/bin still exists and links to python2.6 which is the default system version. Of course, I can remove it and create a new soft link linking to python2.7.
What is the difference between the command "make install" and "make altinstall", except for the link in /usr/bin?
Let's take a look at the generated Makefile!
First, the install target:
install: altinstall bininstall maninstall
It does everything altinstall does, along with bininstall and maninstall
Here's bininstall; it just creates the python and other symbolic links.
# Install the interpreter by creating a symlink chain:
# $(PYTHON) -> python2 -> python$(VERSION))
# Also create equivalent chains for other installed files
bininstall: altbininstall
-if test -f $(DESTDIR)$(BINDIR)/$(PYTHON) -o -h $(DESTDIR)$(BINDIR)/$(PYTHON); \
then rm -f $(DESTDIR)$(BINDIR)/$(PYTHON); \
else true; \
fi
(cd $(DESTDIR)$(BINDIR); $(LN) -s python2$(EXE) $(PYTHON))
-rm -f $(DESTDIR)$(BINDIR)/python2$(EXE)
(cd $(DESTDIR)$(BINDIR); $(LN) -s python$(VERSION)$(EXE) python2$(EXE))
... (More links created)
And here's maninstall, it just creates "unversioned" links to the Python manual pages.
# Install the unversioned manual pages
maninstall: altmaninstall
-rm -f $(DESTDIR)$(MANDIR)/man1/python2.1
(cd $(DESTDIR)$(MANDIR)/man1; $(LN) -s python$(VERSION).1 python2.1)
-rm -f $(DESTDIR)$(MANDIR)/man1/python.1
(cd $(DESTDIR)$(MANDIR)/man1; $(LN) -s python2.1 python.1)
TLDR: altinstall skips creating the python link and the manual pages links, install will hide the system binaries and manual pages.
Simply: The altinstall target will make sure the default Python on your machine is not touched, or to avoid overwriting the system Python.
When I run the make batch file in my Cygwin terminal I get the following output:
mparadis#A-082-MPARADI-0 ~/pepper_19/examples$ make
make -C dlopen
make[1]: Entering directory `/cygdrive/c/nacl_sdk/pepper_19/examples/dlopen' /cygdrive/c/nacl_sdk/pepper_19/toolchain/win_x86_glibc/bin/i686-nacl-g++ -o dlopen_x86_32.o -c
dlopen.cc -m32 -g -O0 -pthread -std=gnu++98 -Wno-long-long -Wall
Makefile:92: recipe for target `dlopen_x86_32.o' failed
make[1]: *** [dlopen_x86_32.o] Error 127
make[1]: Leaving directory `/cygdrive/c/nacl_sdk/pepper_19/examples/dlopen'
Makefile:33: recipe for target `dlopen_TARGET' failed
make: *** [dlopen_TARGET] Error 2
It took some time to get Python properly set up because I needed the language interpreter package for it and was not aware I didn't have it already. My env variable for Python is correctly set to C:\python27. I get the same results when compiling my co-workers code which, I can compile fine on a Mac or Linux box. Unfortunately, I need to get this working in my Cygwin environment as well.
Anybody with any experience using google native client or know why this is happening please advise. I've been at this for so long I'm staring cross-eyed at the computer screen.
UPDATE:
If I insert the --version flag into the referenced command within the makefile, I receive the same error as above. However, if I type the command, as is, from the same working directory as the make file I get the following:
mparadis#A-082-MPARADI-0 ~/pepper_19/examples/dlopen> $ /cygdrive/c/nacl_sdk/pepper_19/toolchain/win_x86_glibc/bin/i686-nacl-g++.exe -o dlopn_x86_32.o -c dlopen.cc -m32 -g -O0 -pthread -std=gnu++98 --version
mparadis#A-082-MPARADI-0 ~/pepper_19/examples/dlopen $
In other words, it simply thinks for a split second, then returns to the prompt.
tl;dr: your cygwin may be buggy and give this return code to all batch file. My does this. My cygwin version:
$ uname -srv
CYGWIN_NT-6.1-WOW64 1.7.17(0.262/5/3) 2012-10-19 14:39
From your comment, I see something called "make.bat":
mparadis#A-082-MPARADI-0 ~/pepper_19/examples/dlopen
$ ls dlopen.cc dlopen.html eightball.cc eightball.h make.bat Makefile
You can test your cygwin with this little bash script, too..
#!/bin/bash
echo echo foo %errorlevel% bar >temp.bat
./temp.bat
if [ $? -eq 127 ]; then echo "bug"; fi
If your make recipe for that target uses make.bat, and you have this bug, then this cygwin bug is causing the Error 127
When following instructions on Getting Started - The Go Programming Language, I get the code and try to run the all.bash script.
But I get this error after a lot of other successful looking output:
INSTALL FAIL net
CGOPKGPATH= cgo -- cgo_bsd.go cgo_unix.go
touch _obj/_cgo_run
6g -o _go_.6 dial.go dnsmsg.go fd_darwin.go hosts.go ip.go ipsock.go iprawsock.go lookup.go net.go parse.go pipe.go sock.go tcpsock.go udpsock.go unixsock.go newpollserver.go fd.go file.go dnsconfig.go dnsclient.go port.go _obj/cgo_bsd.cgo1.go _obj/cgo_unix.cgo1.go _obj/_cgo_gotypes.go
6c -FVw -I/Users/matryer/Work/go/pkg/darwin_amd64 -I . -o "_cgo_defun.6" _obj/_cgo_defun.c
gcc -m64 -I . -g -fPIC -O2 -o _cgo_main.o -c _obj/_cgo_main.c
gcc -m64 -I . -g -fPIC -O2 -o cgo_bsd.cgo2.o -c _obj/cgo_bsd.cgo2.c
gcc -m64 -I . -g -fPIC -O2 -o cgo_unix.cgo2.o -c _obj/cgo_unix.cgo2.c
gcc -m64 -I . -g -fPIC -O2 -o _cgo_export.o -c _obj/_cgo_export.c
gcc -m64 -g -fPIC -O2 -o _cgo1_.o _cgo_main.o cgo_bsd.cgo2.o cgo_unix.cgo2.o _cgo_export.o
cgo -dynimport _cgo1_.o >_obj/_cgo_import.c_ && mv -f _obj/_cgo_import.c_ _obj/_cgo_import.c
6c -FVw -I . -o "_cgo_import.6" _obj/_cgo_import.c
cgo_bsd.go:5[_obj/cgo_bsd.cgo1.go:8]: undefined: _Cconst_AI_MASK
cgo_unix.go:69[_obj/cgo_unix.cgo1.go:72]: undefined: _Cconst_AI_ALL
cgo_unix.go:69[_obj/cgo_unix.cgo1.go:72]: undefined: _Cconst_AI_V4MAPPED
cgo_unix.go:69[_obj/cgo_unix.cgo1.go:72]: undefined: _Cconst_AI_CANONNAME
make[1]: *** [_go_.6] Error 1
make: *** [net.install] Error 1
Has anybody else seen this and fixed it?
I am running Snow Leopard (10.6.7) build 10J869.
It's an open issue, relating to a new version of Xcode, for OS X 10.7 and 10.6.7.
Issue 1881: cgo const error on OS X 10.7
NOTE: Revision 142f0bc0d6e7 has been made to close issue 1881. To update Go for all changes up to and including this revision, run:
$ cd $GOROOT/src
$ hg pull
$ hg update 142f0bc0d6e7
$ ./all.bash
You don't indicate exactly which version of Go you are building. Note that it is a dynamic project where the versions change frequently.
I just ran hg pull and hg update in a directory where I've previously compiled Go successfully (on MacOS X 10.6.7). Then I ran sh all.bash and I didn't see any issues during the build or test phases (though it takes longer to build now than it did when Go was first announced).
FWIW, hg tags gives me:
tip 8715:599657138e00
weekly.2011-06-09 8703:c81944152e97
weekly 8703:c81944152e97
weekly.2011-06-02 8623:3418f22c39eb
weekly.2011-05-22 8483:c98449d685d2
release.r57.1 8294:95d2ce135523
And the end of the build cycle gives:
--- cd ../test
0 known bugs; 0 unexpected bugs
ALL TESTS PASSED
---
Installed Go for darwin/amd64 in /Users/jleffler/go.
Installed commands in /Users/jleffler/bin.
The compiler is 6g.
Therefore...
There is a chance that if you change the version of Go (possibly to a more recent one), then it will work for you, too.
And, another FWIW or FYI, I redid the build on a different machine also running MacOS X 10.6.7 this afternoon, and the tip version is slightly different, and there are apparently 2 known bugs.
--- cd ../test
2 known bugs; 0 unexpected bugs
ALL TESTS PASSED
---
Installed Go for darwin/amd64 in /Users/jleffler/External-Source-Repositories/hg/go.
Installed commands in /Users/jleffler/External-Source-Repositories/hg/go/bin.
*** You need to add /Users/jleffler/External-Source-Repositories/hg/go/bin to your $PATH. ***
The compiler is 6g.
On OS X the debuggers must be installed setgrp procmod.
Read and run ./sudo.bash to install the debuggers.
real 4m55.695s
user 2m52.436s
sys 1m10.222s
Osiris-9 JL: hg tags | sed 15q
tip 8716:164ef168486b
weekly.2011-06-09 8703:c81944152e97
weekly 8703:c81944152e97
weekly.2011-06-02 8623:3418f22c39eb
weekly.2011-05-22 8483:c98449d685d2
release.r57.1 8294:95d2ce135523
The timing information (just under 5 minutes for the build and test cycle) is from running:
time all.bash