I am install Oracle Instant Client: Basic, SDK and SQL*Plus packages v 12.1.0.1 for gem "ruby-oci8" than i realize that i need use Oracle Instant Client v 10.2.0.4. But whan i try to install rpm -ivh oracle-instantclient-sqlplus-10.2.0.4-1.i386.rpm i have error:
Preparing... ########################################### [100%]
file /usr/bin/sqlplus from install of oracle-instantclient-sqlplus-10.2.0.4-1.i386 conflicts with file from package oracle-instantclient12.1-sqlplus-12.1.0.1.0-1.i386
How to resolve this issue?
You are trying to have two different versions of Oracle client libs (10g and 12c).
You can use:
replace -i with -U (U stands for upgrade)
remove ver. 10 first (rpm -e)
If you insist on having two differt client versions remove .rpm packages. And use .zip packges. And simply unpack them into /opt
ldd sqlplus
linux-gate.so.1 => (0x006bf000)
libsqlplus.so => /usr/lib/oracle/10.2.0.4/client/lib/libsqlplus.so (0x00110000)
libclntsh.so.10.1 => /usr/lib/oracle/10.2.0.4/client/lib/libclntsh.so.10.1 (0x006c0000)
libnnz10.so => /usr/lib/oracle/10.2.0.4/client/lib/libnnz10.so (0x00218000)
libdl.so.2 => /lib/libdl.so.2 (0x001c4000)
libm.so.6 => /lib/libm.so.6 (0x001c9000)
libpthread.so.0 => /lib/libpthread.so.0 (0x0041e000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00439000)
libc.so.6 => /lib/libc.so.6 (0x00469000)
/lib/ld-linux.so.2 (0x001f8000)
and ldd libclntsh.so
ldd: ./libclntsh.so: No such file or directory
Related
Yesterday I upgraded pyenv via brew from 1.2.24.1 -> 2.0.3. Since that time now when I open any new terminal window, python is linked to the built in system Python 2 instead of my global pyenv python.
If I do a pyenv virtualenvwrapper in a terminal window, and then create and activate a virtual environment (mkvirtualenv foobar and workon foobar) then my global pyenv Python is activated correctly. Ex:
$ pyenv global
3.9.6
$ which python
/usr/bin/python
$ python
WARNING: Python 2.7 is not recommended.
This version is included in macOS for compatibility with legacy software.
Future versions of macOS will not include Python 2.7.
Instead, it is recommended that you transition to using 'python3' from within Terminal.
Python 2.7.16 (default, Mar 25 2021, 03:11:28)
[GCC 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.29.20) (-macos10.15-objc- on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ pyenv virtualenvwrapper
$ mkvirtualenv foobar
created virtual environment CPython3.9.6.final.0-64 in 346ms
creator CPython3Posix(dest=/Users/adam.parkin/.envs/foobar, clear=False, no_vcs_ignore=False, global=False)
seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/Users/adam.parkin/Library/Application Support/virtualenv)
added seed packages: pip==21.1.3, setuptools==57.1.0, wheel==0.36.2
activators BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator
virtualenvwrapper.user_scripts creating /Users/adam.parkin/.envs/foobar/bin/predeactivate
virtualenvwrapper.user_scripts creating /Users/adam.parkin/.envs/foobar/bin/postdeactivate
virtualenvwrapper.user_scripts creating /Users/adam.parkin/.envs/foobar/bin/preactivate
virtualenvwrapper.user_scripts creating /Users/adam.parkin/.envs/foobar/bin/postactivate
virtualenvwrapper.user_scripts creating /Users/adam.parkin/.envs/foobar/bin/get_env_details
$ workon foobar
$ python
Python 3.9.6 (default, Jul 19 2021, 19:04:48)
[Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
But I don't understand why a new fresh terminal isn't using the Pyenv python instead of the system default python?
My path seems to be pointing to the shims directory before /usr/bin, yet a which python is pointing to /usr/bin/python. My path:
$ echo $PATH
/usr/local/Cellar/pyenv-virtualenv/1.1.5/shims:/Users/adam.parkin/.pyenv/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/adam.parkin/.local/bin:/Users/adam.parkin/bin
As you can see I have the pyenv-virtualenv plugin installed.
The output from the brew upgrade pyenv command when I upgraded can be found in this gist: https://gist.github.com/pzelnip/ca99bf955fe15f66225a41f597501dff
My .bashrc contains the following lines related to pyenv (these are the last 3 lines of my bashrc):
export PATH="$HOME/.pyenv/bin:$PATH"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"
If I do a PYENV_DEBUG=1 pyenv init -, the output can be seen in this gist: https://gist.github.com/pzelnip/641a862c19f35571c20fb7d2cb1aabe8
Change eval "$(pyenv init -)" to eval "$(pyenv init --path)" and start a new shell.
Seems like this was a change that was introduced in 2.0
Have been running around this issue since 2-3 days now with no luck. Hope someone guides me and help resolve this issue here.
I am running a Python application from /home/admin/app/example.py directory in a 3 node Ubuntu 18.04 clustered environment which is supposed to connect to NetSuite via ODBC and read list of tables. The code and directory setup is same across all 3 nodes. There's a load balancer routing request to all these 3 nodes.
Here's example how the connection is made via PyODBC module:
import pyodbc
cnxn = pyodbc.connect('DSN=NetSuite;UID=user;PWD=pass'.format(dsn, uid, pwd), autocommit=True)
cursor=cnxn.cursor()
tables_list = []
for row in cursor.tables():
tables_list.append(row.table_name)
print (tables_list)
However, while running the python application on cluster, I am always getting error as:- Can't open lib '/opt/netsuite/odbcclient/lib64/ivoa27.so; even though the driver file, all its dependencies (via ldd command) and all the path variables i.e. $LD_LIBRARY_PATH, $ODBCINI and $OASDK_ODBC_HOME exists and is set to be available system-wide (added under /etc/environment file) as below on all the 3 nodes:
PYTHON_APP_HOME=/home/admin/app/
LD_LIBRARY_PATH="/opt/netsuite/odbcclient/lib64"
ODBCINI="/opt/netsuite/odbcclient/odbc64.ini"
OASDK_ODBC_HOME="/opt/netsuite/odbcclient/lib64"
Here's the output from "ldd" command for driver dependencies:
-rwxr-xr-x 1 root root 3277375 Jul 25 16:03 ivoa27.so
/opt/netsuite/odbcclient/lib64$ ldd /opt/netsuite/odbcclient/lib64/ivoa27.so
linux-vdso.so.1 (0x00007fff401a2000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fee1d589000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fee1d385000)
libicuuc.so.42 => /opt/netsuite/odbcclient/lib64/libicuuc.so.42 (0x00007fee1d12b000)
libicudata.so.42 => /opt/netsuite/odbcclient/lib64/libicudata.so.42 (0x00007fee1c0e6000)
libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007fee1bed8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fee1bcb9000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fee1b930000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fee1b592000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fee1b37a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fee1af89000)
/lib64/ld-linux-x86-64.so.2 (0x00007fee1db3c000)
libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007fee1ad60000)
libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007fee1ab5b000)
Below is how the steps were performed as per Netsuite driver README.txt instructions and the ODBC driver is setup similarly across all the 3 nodes on Ubuntu 18.04 OS.
The Netsuite 64bit Linux driver files/folders are unpacked and copied at location:
$cd /opt/netsuite/odbcclient/*. This entire dir,sub-dir & files within have both r+x permissions.
Installed libraries $sudo apt install unixodbc && apt-get install unixodbc-dev
Executed script/command provided by Netsuite from dir /opt/netsuite/odbcclient:- $source oaodbc64.sh (since it's a bash shell). This sets up the same variables as shown above.
From the same directory/folder ran below command for registering it as system-wide Driver:
$sudo odbcinst -i -d -f /opt/netsuite/odbcclient/odbcinst.ini
which returned message as:
odbcinst: Driver installed. Usage count increased to 1.
Target directory is /etc
odbcinst: Driver installed. Usage count increased to 1.
Target directory is /etc
Then ran below command also for installing it as system DSN:-
$sudo odbcinst -i -s -l -f /opt/netsuite/odbcclient/odbc64.ini
After this, checked /etc directory where both odbc.ini and odbcinst.ini files where created/registered. Both *.ini files were also given execute permissions to all.
-rwxr-xr-x 1 root root 500 Jul 24 10:31 odbc.ini
-rwxr-xr-x 1 root root 199 Jul 24 10:31 odbcinst.ini
$odbcinst -j
unixODBC 2.3.4
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
FILE DATA SOURCES..: /etc/ODBCDataSources
USER DATA SOURCES..: /opt/netsuite/odbcclient/odbc64.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8
$odbcinst -q -d
[ODBC Drivers]
[NetSuite ODBC Drivers 8.1]
$odbcinst -q -s
[NetSuite]
[ODBC]
I am also able to connect from each individual nodes via isql and also by running the example.py via python shell locally.
$isql -v 'NetSuite' 'user' 'pass'
+---------------------------------------+
| Connected! |
| |
| sql-statement |
| help [tablename] |
| quit |
| |
+---------------------------------------+
SQL>
But when running the same on cluster, it gives same error always. Please help. I am sure am missing something.
Here's the output of odbc.ini and odbcinst.ini files from /etc directory:
/etc$ more odbcinst.ini
[ODBC Drivers]
NetSuite ODBC Drivers 8.1=Installed
UsageCount=1
[NetSuite ODBC Drivers 8.1]
APILevel=1
ConnectFunctions=YYN
Driver=ivoa27.so
DriverODBCVer=03.52
FileUsage=0
SQLLevel=1
UsageCount=1
/etc$ more odbc.ini
[ODBC Data Sources]
NetSuite=NetSuite ODBC Drivers 8.1
[NetSuite]
Driver=/opt/netsuite/odbcclient/lib64/ivoa27.so
Description=Connect to your NetSuite account
Host=XXXXX.connect.api.netsuite.com
Port=1708
ServerDataSource=NetSuite.com
Encrypted=1
Truststore=/opt/netsuite/odbcclient/cert/ca3.cer
CustomProperties=AccountID=XXXXX;RoleID=XXXX
[ODBC]
Trace=0
IANAAppCodePage=4
TraceFile=odbctrace.out
TraceDll=/opt/netsuite/odbcclient/lib64/ddtrc27.so
InstallDir=/opt/netsuite/odbcclient
Tried below other things that didn't work:
Added ODBC variable paths within .profile,.bashrc ,/etc/profile,/etc/bash.bashrc other than /etc/environment.
Changed the owner of /lib64/ folder and all files within it and *.ini files under /etc from root to admin.
By creating symbolic links:
sudo ln -s /etc/odbcinst.ini /usr/local/etc/odbcinst.ini
sudo ln -s /etc/odbc.ini /usr/local/etc/odbc.ini
Thanks !!
UPDATE - SOLVED !! One important step that was missing from our end was the reboot/restart of all the nodes for those 3 variables to take into system-wide effect after it had been added into /etc/environment file(s).
In order to investigate, we printed below additional things into our code to ensure that it indeed is a 64 bit platform/architecture, drivers and datasources are registered and listed. However, the variables were still showing blanks/none. That verified that although the variable path was set/effective locally when running from individual nodes. However, when running from outside/via remote session, the variable values didn't get apply.
import os
import pyodbc
import platform
print(platform.architecture())
print (pyodbc.drivers())
print(pyodbc.dataSources())
print(os.environ["LD_LIBRARY_PATH"])
print(os.environ["ODBCINI"])
print(os.environ["OASDK_ODBC_HOME"])
Before reboot:
[2020-07-27 18:46:51,948] {logging_mixin.py:112} INFO - ('64bit', 'ELF')
[2020-07-27 18:46:51,949] {logging_mixin.py:112} INFO - ['ODBC Drivers', 'NetSuite ODBC Drivers 8.1']
[2020-07-27 18:46:51,950] {logging_mixin.py:112} INFO - {'NetSuite': '/opt/netsuite/odbcclient/lib64/ivoa27.so', 'ODBC': ''}
[2020-07-27 18:46:51,950] {logging_mixin.py:112} INFO - Error: 'LD_LIBRARY_PATH'
After reboot:
[2020-07-28 06:11:59,961] {logging_mixin.py:112} INFO - ('64bit', 'ELF')
[2020-07-28 06:11:59,963] {logging_mixin.py:112} INFO - ['ODBC Drivers', 'NetSuite ODBC Drivers 8.1']
[2020-07-28 06:11:59,965] {logging_mixin.py:112} INFO - {'NetSuite': '/opt/netsuite/odbcclient/lib64/ivoa27.so', 'ODBC': ''}
[2020-07-28 06:11:59,965] {logging_mixin.py:112} INFO - /opt/netsuite/odbcclient/lib64
[2020-07-28 06:11:59,965] {logging_mixin.py:112} INFO - /opt/netsuite/odbcclient/odbc64.ini
[2020-07-28 06:11:59,965] {logging_mixin.py:112} INFO - /opt/netsuite/odbcclient/lib64
I want to use sha256 in my openresty code so tried installing lua-resty-string.
I am clearly missing some other package(s), but have no idea which ones. The lua-resty-string homepage offers no clue that I can see.
$ docker run --rm -it openresty/openresty bash
# apt-get update && apt-get install luarocks
# luarocks install lua-resty-string
Installing https://luarocks.org/lua-resty-string-0.09-0.rockspec
lua-resty-string 0.09-0 is now installed in /usr/local (license: )
root#28fe64c51c5a:/# luajit
LuaJIT 2.1.0-beta3 -- Copyright (C) 2005-2017 Mike Pall. http://luajit.org/
JIT: ON SSE2 SSE3 SSE4.1 fold cse dce fwd dse narrow loop abc sink fuse
> resty_sha256 = require "resty.sha256"
> sha256 = resty_sha256:new()
/usr/local/share/lua/5.1/resty/sha256.lua:41: luajit: undefined symbol: SHA256_Init
stack traceback:
[C]: in function '__index'
/usr/local/share/lua/5.1/resty/sha256.lua:41: in function 'new'
stdin:1: in main chunk
[C]: at 0x55cd1fdaf250
I would be more convinced that luarocks if it would build or install software correctly.
What I am missing (this time)?
It seems that the lua-resty-string package only works when code is executed by the nginx server.
root#62817b2fe1b2:/# ldd `which nginx`
linux-vdso.so.1 (0x00007ffe3b1db000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa367a81000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa367a60000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fa367a26000)
libluajit-5.1.so.2 => /usr/local/openresty/luajit/lib/libluajit-5.1.so.2 (0x00007fa3679a3000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa367820000)
libpcre.so.1 => /usr/local/openresty/pcre/lib/libpcre.so.1 (0x00007fa3677ad000)
libssl.so.1.1 => /usr/local/openresty/openssl/lib/libssl.so.1.1 (0x00007fa367739000)
libcrypto.so.1.1 => /usr/local/openresty/openssl/lib/libcrypto.so.1.1 (0x00007fa3674ad000)
libz.so.1 => /usr/local/openresty/zlib/lib/libz.so.1 (0x00007fa367490000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa3672cf000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa367c97000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa3672b5000)
root#62817b2fe1b2:/# nm -D /usr/local/openresty/openssl/lib/libcrypto.so.1.1 | grep SHA256_Init
00000000001b12a0 T SHA256_Init
And that library comes with openresty:
root#62817b2fe1b2:/# dpkg -S /usr/local/openresty/openssl/lib/libcrypto.so.1.1
openresty-openssl: /usr/local/openresty/openssl/lib/libcrypto.so.1.1
So the real question I suppose it how do you tell luajit to load that library so that it can resolve SHA256_Init when resty.sha256 is imported.
And that it seems can be done with ffi:
local ffi = require("ffi")
local crypto = ffi.load("/usr/local/openresty/openssl/lib/libcrypto.so.1.1", true)
I have built a custom toolchain from scratch for a MIPS 24kc (dragino) target platform, using gcc-6.3.0, musl-1.1.16 and binutils-2.27. That toolchain is completely functional.
However, the size of my-custom toolchain is five times bigger than size of equivalent OpenWRT generated toolchain (557M vs 113M). Toolchain binaries generated by OpenWRT (mips-openwrt-linux-musl-*) are dynamically linked against libstdc++ and libgcc_s libraries. However, my toolchain binaries are linked with these libs statically:
$ ldd mips-openwrt-linux-musl-gcc-5.3.0
linux-vdso.so.1 => (0x00007ffc4d534000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f878936f000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8789159000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8788d8f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8788a86000)
/lib64/ld-linux-x86-64.so.2 (0x000055df3ef8b000)
$ ldd mips-linux-musl-gcc-6.3.0
linux-vdso.so.1 => (0x00007ffd40940000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2de4b8f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2de47c6000)
/lib64/ld-linux-x86-64.so.2 (0x0000560bba4b6000)
The same linking issue happens with cc1 and cc1plus. Sizes of these two binaries are huge (cc1 is 124MB, cc1plus is 134MB).
My question is: what is the proper way to setup the cross-toolchain generation to get a cross-platform toolchain as small as the OpenWRT generated toolchain?
Bellow you can find the steps I'm doing to build my-custom toolchain for reference:
Download sources:
wget http://ftpmirror.gnu.org/binutils/binutils-2.27.tar.bz2
wget http://ftpmirror.gnu.org/gcc/gcc-6.3.0/gcc-6.3.0.tar.bz2
wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.12.6.tar.bz2
wget https://www.musl-libc.org/releases/musl-1.1.16.tar.gz
wget http://ftpmirror.gnu.org/mpfr/mpfr-3.1.5.tar.bz2
wget http://ftpmirror.gnu.org/gmp/gmp-6.1.2.tar.bz2
wget http://ftpmirror.gnu.org/mpc/mpc-1.0.2.tar.gz
Setup build environment:
export ROOTDIR="${HOME}/custom-toolchains/MIPS"
export NATIVE_PREFIX="${ROOTDIR}/opt/native"
export CROSS_PREFIX="${ROOTDIR}/opt/cross"
export TARGET_MACHINE=mips
export CPU=mips
export ARCH=24kc
export CLIB=musl
export TARGET_TRIPLET=${CPU}-linux-${CLIB}
Build native binutils:
cd ${ROOTDIR}/src
mkdir build-binutils
cd build-binutils
../binutils-2.27/configure --prefix="${NATIVE_PREFIX}" --disable-nls --disable-werror --disable-multilib
make
make install
Build native gcc:
cd ${ROOTDIR}/src/gcc-6.3.0
ln -s ../mpfr-3.1.5 mpfr
ln -s ../gmp-6.1.2 gmp
ln -s ../mpc-1.0.3 mpc
cd ..
mkdir build-gcc
cd build-gcc
../gcc-6.3.0/configure --prefix=${NATIVE_PREFIX} --disable-nls --enable-languages=c --disable-multilib
make
make install
Build cross-binutils:
cd ${ROOTDIR}/src
mkdir build-${CPU}-binutils
cd build-${CPU}-binutils
../binutils-2.27/configure --target=${TARGET_TRIPLET} --prefix=${CROSS_PREFIX} --with-sysroot --disable-nls --disable-werror --disable-multilib
make
make install
Install kernel headers:
cd ${ROOTDIR}/src
cd linux-3.12.6
make ARCH=${TARGET_MACHINE} INSTALL_HDR_PATH=${CROSS_PREFIX}/${TARGET_TRIPLET} headers_install
Build cross-gcc (stage 1)
cd ${ROOTDIR}/src
mkdir build-bootstrap-${CPU}-gcc
cd build-bootstrap-${CPU}-gcc
../gcc-6.3.0/configure --target=${TARGET_TRIPLET} --prefix=${CROSS_PREFIX} --disable-nls --enable-languages=c --disable-multilib --disable-threads --disable-shared --with-float=soft --with-arch=${ARCH}
make all-gcc install-gcc
make all-target-libgcc install-target-libgcc
Build cross-musl
cd ${ROOTDIR}/src
mkdir build-${CLIB}
cd build-${CLIB}
CC=${TARGET_TRIPLET}-gcc CFLAGS=-Wa,-msoft-float ../musl-1.1.16/configure --prefix=${CROSS_PREFIX}/${TARGET_TRIPLET}/ --enable-optimize CROSS_COMPILE=${TARGET_TRIPLET}-
make
make install
Build cross-gcc (stage 2)
cd ${ROOTDIR}/src
mkdir build-${CPU}-gcc
cd build-${CPU}-gcc
../gcc-6.3.0/configure --target=${TARGET_TRIPLET} --prefix=${CROSS_PREFIX} --disable-nls --enable-languages=c,c++ --disable-multilib --enable-threads --enable-shared --with-float=soft --with-arch=${ARCH} --enable-target-optspace --disable-libgomp --disable-libmudflap --without-isl --without-cloog --disable-decimal-float --disable-libssp --disable-libsanitizer --enable-lto --with-host-libstdcxx=-lstdc++
make
make install
Thank you for all your comments in advance!
Fixing this issue has been simpler than expected... All toolchain binaries are installed non-stripped. So this can be fixed calling
$ make install-strip
instead of
$ make install
when you install cross-gcc (stage 2).
Size of generated toolchain is 122MB, what is nice compared with 557M of the original toolchain. So this issue is fixed! Hope this information will be useful for somebody else in the future. Thank you!
I am attempting to rebuild my development/test environment on a new laptop running windows7 32 bit. imageMagick is one of the modules I had installed in an (ancient) version on my old laptop. I have downloaded and installed perl from dwimperl, which is v5.14.2 and had a couple modules install, and several did not.
cpanm Image::Magick - failed
cpanm DB_File - failed
cpanm Time::HiRes - failed
I searched around and found a discussion on magick failing to install on v5.12, but couldn't tell if that was supposed to have been fixed, or if I need to attempt to recreate the fix discussed for 5.12
should I try installing perl from Strawberry? looks like it is a little newer v5.18 ?
is there something I can tweak and re-run cpan installs?
I installed the binaries from imagemagick, from Link first, then cpan again, and cpan still fails....
This is the top part of the build log down to where it really goes south and starts kicking out errors:
cpanm (App::cpanminus) 1.6941 on perl 5.014002 built for MSWin32-x86-multi-thread
Work directory is C:\Users\dtbaker/.cpanm/work/1377281741.8420
You have make C:\Dwimperl\c\bin\dmake.exe
You have LWP 6.03
Falling back to Archive::Tar 1.80
Searching Image::Magick on cpanmetadb ...
--> Working on Image::Magick
Fetching http://www.cpan.org/authors/id/J/JC/JCRISTY/PerlMagick-6.86.tar.gz
-> OK
Unpacking PerlMagick-6.86.tar.gz
Entering PerlMagick-6.86
META.yml/json not found. Creating skelton for it.
Configuring PerlMagick-6.86
Running Makefile.PL
################################### WARNING! ###################################
# It seems that you are trying to install Perl::Magick on a MS Windows box with
# perl + gcc compiler (e.g. strawberry perl), however we cannot find ImageMagick
# binaries installed on your system.
#
# Please check the following prerequisites:
#
# 1) You need to have installed ImageMagick Windows binaries from
# http://www.imagemagick.org/script/binary-releases.php#windows
#
# 2) We only support dynamic (DLL) ImageMagick binaries
# note: it is not possible to mix 32/64-bit binaries of perl and ImageMagick
#
# 3) During installation select that you want to install ImageMagick's
# development files (libraries+headers)
#
# 4) You also need to have ImageMagick's directory in your PATH
# note: we are checking the presence of convert.exe and/or identify.exe tools
#
# 5) You might need Visual C++ Redistributable Package installed on your system
# see instructions on ImageMagick's Binary Release webpage
#
# We are gonna continue, but chances for successful build are very low!
################################################################################
Checking if your kit is complete...
Looks good
Note (probably harmless): No library found for -lMagickCore-6.Q16
Writing Makefile for Image::Magick
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.62)
Building and testing Image-Magick-6.86
cp Magick.pm blib\lib\Image\Magick.pm
AutoSplitting blib\lib\Image\Magick.pm (blib\lib\auto\Image\Magick)
C:\Dwimperl\perl\bin\perl.exe C:\Dwimperl\perl\lib\ExtUtils\xsubpp -typemap C:\Dwimperl\perl\lib\ExtUtils\typemap -typemap typemap Magick.xs > Magick.xsc && C:\Dwimperl\perl\bin\perl.exe -MExtUtils::Command -e mv -- Magick.xsc Magick.c
gcc -c -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -s -O2 -DVERSION=\"6.86\" -DXS_VERSION=\"6.86\" "-IC:\Dwimperl\perl\lib\CORE" -D_LARGE_FILES=1 -DHAVE_CONFIG_H Magick.c
Magick.xs:60:31: error: magick/MagickCore.h: No such file or directory
Magick.xs:167: error: expected specifier-qualifier-list before 'MagickRealType'
Magick.xs:188: error: expected specifier-qualifier-list before 'ImageInfo'
Magick.xs:210: error: 'MagickNoiseOptions' undeclared here (not in a function)
however we cannot find ImageMagick binaries installed on your system.
Is ImageMagick is in your path, as recommanded in the 4) point? Open cmd.exe and type convert -v or convert.exe -v. If you don't see informations about Image Magick (Windows have a built-in convert command), it is very likely you have to add it to your path.
You also have to check points 1), 3), and 5). After that try again to run installation process through cpanm.
Trying to install for Citrus Perl, I discovered on debugging through the Perl part of the install that the mingw64 install had not included 'pexports.exe'. Downloading that from https://sourceforge.net/projects/mingw/files/MinGW/Extension/pexports/
and placing it in the mingw64 directory was necessary to solve the problem of a long list of library export symbols not found.
Prior to that I had also set the environment variables CPATH, C_INCLUDE_PATH, and CPLUS_INCLUDE_PATH to point to the "include" directory of the ImageMagick install include directory in C:\Program Files (x86). (When you install ImageMagick you should check the box to install also for Strawberry Perl.)