I am Arch GNU/Linux user who usually manages almost every package with pacman; I manage TeX and LaTeX-related things with tlmgr. I installed tlmgr from source.
I am writing paper. I would like to use bibliography.
When I tried latexmk -pdflua main.ltx:
Rc files read:
latexmkrc
Latexmk: This is Latexmk, John Collins, 20 November 2021, version: 4.76.
Latexmk: applying rule 'biber main'...
Rule 'biber main': The following rules & subrules became out-of-date:
'biber main'
------------
Run number 1 of rule 'biber main'
------------
------------
Running 'biber "main.bcf"'
------------
biber: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
Latexmk: Errors, so I did not complete making targets
Collected error summary (may duplicate other messages):
biber main: Could not open biber log file for 'main'
Latexmk: Use the -f option to force complete processing,
unless error was exceeding maximum runs, or warnings treated as errors.
libcrypt.so* on my environment
$ pacman -Qo /usr/lib/libcrypt*
/usr/lib/libcrypto.so is owned by openssl 1.1.1.m-1
/usr/lib/libcrypto.so.1.1 is owned by openssl 1.1.1.m-1
/usr/lib/libcryptsetup.so is owned by cryptsetup 2.4.3-2
/usr/lib/libcryptsetup.so.12 is owned by cryptsetup 2.4.3-2
/usr/lib/libcryptsetup.so.12.7.0 is owned by cryptsetup 2.4.3-2
/usr/lib/libcrypt.so is owned by libxcrypt 4.4.28-1
/usr/lib/libcrypt.so.2 is owned by libxcrypt 4.4.28-1
/usr/lib/libcrypt.so.2.0.0 is owned by libxcrypt 4.4.28-1
What I tried else
I uninstalled and re-installed biber on tlmgr but did not work.
# ln -s /usr/lib/libcrypt.so /usr/lib/libcrypt.so.1
$ latexmkrc -pdflua main.ltx
Rc files read:
latexmkrc
Latexmk: This is Latexmk, John Collins, 20 November 2021, version: 4.76.
Latexmk: applying rule 'biber main'...
Rule 'biber main': The following rules & subrules became out-of-date:
'biber main'
------------
Run number 1 of rule 'biber main'
------------
------------
Running 'biber "main.bcf"'
------------
/tmp/par-716861/cache-0e6aa298f0c2e7a775de99938825b2d56bd2027f/biber: /usr/lib/libcrypt.so.1: version `GLIBC_2.2.5' not found (required by /tmp/par-716861/cache-0e6aa298f0c2e7a775de99938825b2d56bd2027f/biber)
Latexmk: Errors, so I did not complete making targets
Collected error summary (may duplicate other messages):
biber main: Could not open biber log file for 'main'
Latexmk: Use the -f option to force complete processing,
unless error was exceeding maximum runs, or warnings treated as errors.
File source
latexmkrc:
$latex='lualatex %O -synctex=1 -interaction=nonstopmode %S';
#$bibtex='upbibtex %O %B';
$bibtex='biber %O %B';
$makeindex='upmendex %O -o %D %S';
$pdf_mode=3;
Install libxcrypt-compat from the Core (1) repository, as suggest in this answer.
This made my biber from TeX Live 2020 work again. The interesting question is if newer TeX distributions will require this package, too.
(1) Thanks to #samueldy for the hint that the package was moved from the AUR to Core.
Adding on to #Christoph90's answer, as of 25 May 2022 the libxcrypt-compat package is still required in TeX Live 2022 in order for biber to function on Manjaro 21.2.6. However, the package has moved to core/libxcrypt-compat, so install by doing
sudo pacman -S libxcrypt-compat
Related
The pdflatex: gave an error:
$ latexmk -pdf std
Rc files read:
latexmkrc
Latexmk: This is Latexmk, John Collins, 18 Nov. 2022. Version 4.78, version: 4.78.
Latexmk: Nothing to do for 'std.tex'.
Latexmk: All targets () are up-to-date
Collected error summary (may duplicate other messages):
pdflatex: gave an error
Latexmk: If appropriate, the -f option can be used to get latexmk
to try to force complete processing.
Maybe I miss something, but where is the error's description? Where is to see it? How do I know what the error is? Confused.
I am new to EDK2.
For porting ekd2 firmware to a new ARM64 platform, it would be good to first get a minimum edk2 port which can run UEFI Shell at least, improvements can be added gradually based on that.
It seems that the first step is rather steep, e.g., how to determine a minimal set of "items" in .dsc and .fdf file for a platform? In my case, I would like to build the .fd for my platform and treat it as BL33 of TF-A, effectively I would like to build an edk2 firmware to replace u-boot.
It seems that such a guide is hard to find on the web. I found a old version of edk2 which contains some instructions, but apparently they are obsolete (not exist in latest master branch, while can be found in UDK branches such as UDK2014), and I am not sure why those documents are removed from master branch.
Currently I can build .fd for FVP (edk2-platforms/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc), and it seems that the build output FVP_AARCH64_EFI.fd is supposed to be treated as BL33. Theoretically this could be a prototype for my new ARM64 platform, but to me it's too complex to start with: the firmware is about 2.5MiB in size (as compare to 500K of u-boot), so I guess it's far from a "minimum" version. but it's hard to figure out what features to be removed (and how).
I am wondering if there is a detailed guide on such topic...
After 1 month of trial and error, today I managed to bring my ARM64 platform into a UEFI Shell environment. I treat it as my 1st milestone on the EDK2 journey. Below I will try to summarize the steps I took so far, as a tentative answer to my question above. Guidance/corrections/comments are welcomed.
Get familiar with UEFI/PI spec and EDK2 implementation by reading books/specs/articles. Well, UEFI/PI specs are thousands of pages long...how to start? My main reading list is:
"Beyond Bios--Developing with the Unified Extensible Firmware Interface", 3rd ed, by Vincent Zimmer, et al. As the authors explained, the book is a kind of high level summary of the thousands-paged specs. And I find that the book is well organized for a new comer to get familiar with various UEFI related concepts. The main purpose of the 1st read (before playing with edk2 code base) is to get familiar with concepts and architectural ideas, not the details yet. Related sections need to be consulted later when reading EDK2 implementations.
EDK2 specs, including:
EDKII User Manual
EDKII Build Specification
EDKII DSC/FDF/DEC/INF File Specification
Various articles on the web...
Get a reference platform which can correctly boot a FD image built from latest EDK2 source, and play with the boot manager and Shell environment a bit. In my case, I chose RPi4B. For me, this is very important, as the reference platform serves as a handrail during the whole process, that whenever I encounter bugs or have doubts, I check the source/log of the reference platform. This solves most of the problems I encountered. Btw, always generating "build log" and "build report" for both reference platform and the target platform, as the two files contains very detailed information for comparison and check. Consult the EDK2 build spec on how to generate these two files during build.
I use the following script to build for RPi4B platform:
#!/bin/bash
# https://github.com/tianocore/edk2-platforms#how-to-build-linux-environment
export WORKSPACE=/home/bruin/work/tianocore
export PACKAGES_PATH=$WORKSPACE/edk2:$WORKSPACE/edk2-platforms:$WORKSPACE/edk2-non-osi
pushd $WORKSPACE
rm -rf ./Build/RPi4
source edk2/edksetup.sh
echo "Building BaseTools..."
make -C edk2/BaseTools all
#sudo apt install acpica-tools # iasl
# pip install antlr4-python3-runtime # -Y EXECUTION_ORDER
echo "Building firmware for Pi4B..."
GCC5_AARCH64_PREFIX=aarch64-none-linux-gnu- build \
-n 4 \
-a AARCH64 \
-p Platform/RaspberryPi/RPi4/RPi4.dsc \
-t GCC5 \
-b NOOPT \
-v -d 9 -j RPi4-build.log \
-y RPi4-build-report.txt \
-Y PCD \
-Y LIBRARY \
-Y DEPEX \
-Y HASH \
-Y BUILD_FLAGS \
-Y FLASH \
-Y FIXED_ADDRESS \
-Y EXECUTION_ORDER \
all
How to use the build result RPI_EFI.fd on RPi4B, consult the following:
edk2-platforms/Platform/RaspberryPi/RPi4/Readme.md
readme.md inside https://github.com/pftf/RPi4/releases/download/v1.17/RPi4_UEFI_Firmware_v1.32.zip. btw, I need to replace the original start4.elf and fixup4.dat with the ones in the zip file, otherwise, the boot of RPi4 will fail, complaining something like below:
RpiFirmwareGetClockRate: Get Clock Rate return: ClockRate=0 ClockId=C
ASSERT [ArasanMMCHost] /home/bruin/work/tianocore/edk2-platforms/Platform/RaspberryPi/
Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c(263): BaseFrequency != 0
It's worth to analysis the RPI_EFI.fd content to some extend, by using some UEFI utilities. I mainly use the GUI version UEFITool of sudo apt install uefitool uefitool-cli. Other tools are also available. The anotomy of RPI_EFI.fd is of help when reading EDK2 build specs for checking understanding of the concepts.
One special aspect of RPI_EFI.fd is that the 1st 128K is bl31.bin binary from ATF. I guess this is due to the special booting connfiguration methods for RPi. For my platform, I don't need such kind of packaging, I only need to build the UEFI image MY.fd, which is treated as BL33 image and packaged into fip.bin togehter with BL2 and BL31 images by ATF build script.
Another aspect to notice is the "reset vector" in the begining of the .fd file. This related to the entry point of UEFI image (and entry point of each EDK2 modules), as well as interpreting the BL instruction for AArch64. Basically, it can be summarized as below:
The first [Components] in RPI_EFI.fd is ArmPlatformPkg/PrePi/PeiUniCore.inf, which is of MODULE_TYPE = SEC.
What's this component: this is the first (and only) SEC (Security) module in RPi4. What the name PrePi and Pei implies?
... the PI spec is not tied to edk2 PEIMs, and I don't see where EDKII PEI modules are currently the only "acknowledged" silicon init environment. The edk2 tree itself seems to contain platforms that don't use the edk2 PEI module set at all, but (IIRC) jump from SEC to DXE. I believe "ArmPlatformPkg/PrePi" and "ArmVirtPkg/PrePi" are related to this.
--- https://listman.redhat.com/archives/edk2-devel-archive/2020-November/msg00021.html
Its entry point: all UEFI components have the same entry point (_ModuleEntryPoint).
By "component", it means either a UEFI driver and UEFI app, both are PE32 executables, usually with suffix .efi.
The .efis are converted from ELF executables (.dll) by GenFw tool: modifying the file headers.
To verify that "all components' entry point is _ModuleEntryPoint":
Check the .dll generating command line in build report (build -y <BUILD_REPORT_FILE>), we have two flags "aarch64-none-linux-gnu-gcc" -o xxx.dll -u _ModuleEntryPoint -Wl,-e,_ModuleEntryPoint ...:
-u: gcc --help -v|grep "undefined SYMBOL" gives -u SYMBOL --undefined SYMBOL: star with undefined reference to SYMBOL.
Wl,-e: ld --help|grep "entry" gives -e ADDRESS, --entry ADDRESS Set start address.
Check all .dll files that Entry point address == _ModuleEntryPoint: find . -type f -name "*.dll" -exec sh -c "readelf -a {} |grep -E 'Entry point address|_ModuleEntryPoint'" \;
Its entry point is the entry point of whole UEFI FD image (i.e., from bl33_base_addr jump to this _ModuleEntryPoint):
Topology of the UEFI Firmware File
A UEFI Firmware File (actually a UEFI Firmware Device - FD file) is a collection of UEFI binaries encapsulated into a single image. The format of this image is defined by the Platform Initialization Specification Volume 3. A Vector Table is located at the base of this file. A 'BL' branch instruction at the base of the firwmare (location of the Reset Entry into the Vector Table) will jump to the first 'SEC' module of the UEFI Firmware Image.
--- https://github.com/lzeng14/tianocore/wiki/ArmPkg-Debugging
To verify the statements above:
Disassember the reset vector (i.e., the 1st word) of generated .FD (we got offset=0x360):
$ xxd -l 4 -e TEST.fd <== dump 4 bytes in little endian
00000000: 140000d8 <== BL {PC}+(0xd8<<2); offset=0x360
Check the Entry point in .dll (we got offset=0x240):
$ aarch64-none-elf-objdump -t ArmPlatformPrePiUniCore.dll|grep _ModuleEntryPoint
0000000000000240 g F .text 0000000000000000 _ModuleEntryPoint
$ readelf -h ArmPlatformPrePiUniCore.dll|grep Entry
Entry point address: 0x240
Compare contents of two files at different offset (we got identicial content):
$ xxd -s 0x360 -l 64 TEST.fd <== skip 0x360 bytes, dump 64 bytes
00000360: 901e 0094 050a 0094 ea03 00aa a1cd 0a58 ...............X
00000370: 0200 e0d2 2200 c0f2 0240 a0f2 0200 80f2 ...."....#......
00000380: c303 a0d2 e3ff 9ff2 6304 00d1 6300 028b ........c...c...
00000390: 0400 a1d2 0400 80f2 2000 03eb 8400 0054 ........ ......T
$ xxd -s 0x240 -l 64 ArmPlatformPrePiUniCore.dll <== skip 0x240 bytes
00000240: 901e 0094 050a 0094 ea03 00aa a1cd 0a58 ...............X
00000250: 0200 e0d2 2200 c0f2 0240 a0f2 0200 80f2 ...."....#......
00000260: c303 a0d2 e3ff 9ff2 6304 00d1 6300 028b ........c...c...
00000270: 0400 a1d2 0400 80f2 2000 03eb 8400 0054 ........ ......T
Prepare an empty pkg, and make it build ok. The main purpuse is to do some exercise with EDK2 build system, and use the empty pkg as the start point for the new platform.
Make a copy of RaspberryPi.dec, change all gRaspberry to gMyPlatform.
Make a copy of RPi4.dsc and RPi4.fdf, and comment out all stuff in DSC and FDF file.
Replace all GUIDs in DSC/FDF/DEC files, generating new ones using online guid generator.
Note that PCD are declared in DEC files, and DEC files are refered by modules (INF files). As the empty package contains no module, no PCD definition will be available in FDF. So for a success build of the empty package, we need to comment out all PCD reference in FDF.
The NOOPT build command for MyPlatform is as below:
#!/bin/bash
export WORKSPACE=/home/bruin/work/tianocore
export PACKAGES_PATH=$WORKSPACE/edk2:$WORKSPACE/edk2-platforms:$WORKSPACE/edk2-non-osi
pushd $WORKSPACE
source edk2/edksetup.sh
echo "Building BaseTools..."
make -C edk2/BaseTools all
echo "Building UEFI firmware for MyPlatform..."
GCC5_AARCH64_PREFIX=aarch64-none-linux-gnu- build \
-n 4 \
-a AARCH64 \
-p Platform/MyCorp/MyPlatform/MyPlatform.dsc \
-t GCC5 \
-b NOOPT \
-v -d 9 -j MyPlatform-build.log \
-y MyPlatform-build-report.txt \
-Y EXECUTION_ORDER \
-Y PCD \
-Y LIBRARY \
-Y DEPEX \
-Y HASH \
-Y BUILD_FLAGS \
-Y FLASH \
-Y FIXED_ADDRESS \
all
popd
Add the 1st component ArmPlatformPrePiUniCore. This component is to prepare the HOBs for DXE phae. The main purpose is to get serial port working and memory config correct. Another purpose of this step is to familiar with steps for adding a component/module/lib. Below is a brief summary of the steps:
Uncomment the module's INF into both DSC ([Components] section), and FDF ([FV.FVMAIN_COMPACT]).
Rebuild the pkg, and resolve all Instance of library class [xxxLib] is not found errors reported, by updating [LibraryClasses] sections of DSC.
This step is a repeating process for dozens of times.
Some lib-class has multiple lib-instances, making sure choose the appropriate lib-instance (ref the build-report of RPi4).
if encounter ModuleEntryPoint.iiii:31: Error: immediate out of range: enable gArmTokenSpaceGuid.PcdFdBaseAddress and gArmTokenSpaceGuid.PcdFdSize in FDF.
if encounter undefined reference to _gPcd_BinaryPatch_PcdSerialClockRate: set PcdSerialClockRate in [PcdsPatchableInModule] section in DSC. FIXME: why? ref.
Check the PCDs listed in build log: inspect any abnormal PCD values, and supply correct values.
Customize platform-specific drivers or libraries.
SerialPortLib: locate the lib-class header file (MdePkg/Include/Library/SerialPortLib.h) by find edk2 -type f -name "*.dec" -exec grep -Hn SerialPortLib. The following functions are required:
SerialPortInitialize()
SerialPortWrite()
SerialPortRead()
SerialPortPoll()
SerialPortSetControl(): RETURN_UNSUPPORTED
SerialPortGetControl(): RETURN_UNSUPPORTED
SerialPortSetAttributes(): RETURN_UNSUPPORTED
ArmPlatformLib: interface header at Include/Library/ArmPlatformLib.h. The following functions are required:
ArmPlatformGetCorePosition(): return cpu idx in the cluster given the MPIDR value. this function is used in _ModuleEntryPoint for setting stack for secondary cores. Assuming one cluster for now.
ArmPlatformIsPrimaryCore()
ArmPlatformGetPrimaryCoreMpId()
ArmPlatformGetBootMode()
ArmPlatformPeiBootAction()
ArmPlatformInitialize()
ArmPlatformGetVirtualMemoryMap()
ArmPlatformGetPlatformPpiList()
etc...
Uncomment more modules in DSC/FDF, module by module...For driver/libs which are RPi platform specific, we can:
either search the edk2/edk2-platform for similiar driver or lib instances, or
copy the RPi4 implementation and comment out most of the content, make the pkg build success first, and then bug fixing.
Debugging: my current main debugging method is through adding "printf()", i.e., the edk2 macro DEBUG((DEBUG_INFO,)). One needs to set gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel to an appropriate value to see more debug info.
Issue: Problem compiling bitcoin source code from https://github.com/bitcoin/bitcoin
Building bitcoin code requires Berkeley DB 4.8( https://github.com/tinybike/get-bdb-4.8).
No problem with that.
My system is running on Ubuntu 20.04.
$ cpp --version
cpp (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ --version
g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
When compiling the bitcoin code, after running 'configure' and 'make' an error occurs indicating that it could not find iostream.h
...
CXX libbitcoin_server_a-txrequest.o
CXX libbitcoin_server_a-txmempool.o
CXX libbitcoin_server_a-validation.o
CXX libbitcoin_server_a-validationinterface.o
CXX libbitcoin_server_a-versionbits.o
CXX wallet/libbitcoin_server_a-init.o
In file included from ./wallet/bdb.h:27,
from wallet/init.cpp:19:
/bitcoin/src/bdb/build_unix/build/include/db_cxx.h:59:10: fatal error: iostream.h: No such file or directory
59 | #include <iostream.h>
| ^~~~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:8933: wallet/libbitcoin_server_a-init.o] Error 1
make[2]: Leaving directory '/bitcoin/src'
make[1]: *** [Makefile:15214: all-recursive] Error 1
make[1]: Leaving directory '/bitcoin/src'
make: *** [Makefile:809: all-recursive] Error 1
On examining the header files location /usr/include/c++/9 I could not locate iostream.h
Is this a compiler package issue or bitcoin not using c++ iostream header file
I would guess you tried to build the "depends" BDB before installing the required system packages, and that produced an invalid/unusuable build.
Try removing your current "depends" builds and doing them over.
Alternatively, you could just use my db48 PPA for Ubuntu: https://launchpad.net/~luke-jr/+archive/ubuntu/db48
i got the same error,but it came when i build zero-ice with berkeley db. I found some usages about libdb and most of them add #define HAVE_CXX_STDHEADERS at the begining of codes, so i tried add this definition in ICEDIR/cpp/include/IceUtil/Config.h. It works.Wish it works for you.
something was completely wrong during db4.8 compilation
but as temporary fix, you may add in
include/db_cxx.h
#define HAVE_CXX_STDHEADERS 1
this may help, but depends.
imho
most correct way to build db-4.8 for bitcoin
wget http://download.oracle.com/berkeley-db/db-4.8.30.NC.tar.gz
tar zxvf db-4.8.30.NC.tar.gz
cd db-4.8.30.NC
build_unix/
../dist/configure --prefix=/usr/local/db48 --enable-cxx --with-pic --disable-replication --disable-shared
make install
cd ../bitcoin-x.x
export BDB_PREFIX=/usr/local/db48
export BDB_LIBS="-L/usr/local/db48/lib -ldb_cxx-4.8"
export BDB_CFLAGS="-I/usr/local/db48/include"
./configure
and etc.
I tried to update nix-env but it is not showing latest packages:
a_user[~]$ nix-channel --update
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US",
LC_ALL = "en_US",
LC_COLLATE = "C",
LANG = "en_US"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
downloading Nix expressions from âhttps://nixos.org/releases/nixpkgs/nixpkgs-16.03pre71923.3087ef3//nixexprs.tar.xzâ...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US",
LC_ALL = "en_US",
LC_COLLATE = "C",
LANG = "en_US"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
unpacking channels...
a_user[~]$
a_user[~]$
a_user[~]$ nix-env -qa | grep baobab
baobab-3.16.1
a_user[~]$
a_user[~]$
a_user[~]$ nix-env -qa | grep dicom
a_user[~]$
a_user[~]$
a_user[~]$ nix-env -qa | grep grassroot
a_user[~]$
a_user[~]$
grassroot-dicom is available: https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93&q=dicom
Also, baobab version 3.18 is available: https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93&q=baobab
Why this discrepancy and how can I resolve this?
Also, how to correct locale settings in Slackware? Thanks.
Your search result for "dicom" found that string in the description of a package, alright, but that package is not called "dicom": it's called gdcm. You can do a similar search with nix-env as follows:
nix-env -qaP --description | grep -i dicom
gdcm gdcm-2.4.4 The grassroots cross-platform DICOM implementation
The output has three columns. The first one is the attribute path to the package, which you can use to install the package with nix-env -iA. The second column shows the package's name, which you can use to install it with nix-env -i. The third column is the short description of the package, which has no relevant inside of Nix; it's intended just for humans.
Now, to install the package, run nix-env -i gdcm or nix-env -iA gdcm. Both commands will work, but the latter one (the one using the attribute path) is usually faster.
The package baobab-3.18.0 is available in the master branch of the Nixpkgs git repository, but it's not yet available in the nixos-unstable channel. The channel hasn't advanced to the latest version of master yet, because there are regression test failures that need to be fixed before the channel is updated. The new version of baobab will show up in the channel in a couple of days (state of 2015-11-26). Simply put, the channel updates every time an entire column in the build set https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents is green, and this hasn't happened in a while: https://github.com/NixOS/nixpkgs/issues/11097 has more details.
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.)