We've been using PDFlib to generate PDFs from text files. It has worked fine until we upgraded our Macs to Lion. PDFLib fails now generating this message:
Can't load '/[path to directory]/pdflib_pl.dylib' for module pdflib_pl:
dlopen(/[path to directory]/pdflib_pl.dylib, 1): no suitable image found. Did find:
/[path to directory]/pdflib_pl.dylib: mach-o, but wrong architecture
at /usr/local/ActivePerl-5.14/lib/DynaLoader.pm line 195.
at /[path to directory]/perl586/pdflib_pl.pm line 22
Compilation failed in require
at /[path to directory]/reportpdf.pl line 11.
BEGIN failed--compilation aborted at /[path to directory]/reportpdf.pl line 11
The dylib's architecture is i386 according to lipo:
$ lipo -info pdflib_pl.dylib
Non-fat file: pdflib_pl.dylib is architecture: i386
That dylib is from version 7 (or earlier?) of PDFlib. It was was installed by a previous developer, so I don't know exactly where it came from. The upgraded version of PDFLib, version 8, does not seem to have a dylib included for perl. Should I compile a new dylib? Source is available from PDFlib for their lite version at least, and I'm comfortable with compiling stuff, but I'm hoping there is simpler solution.
thanks!
Did you try?
>> perl -MCPAN -e 'install PDFLib'
Related
Using perlbrew to move from perl 5.16.0 to 5.22.2
Running on a MacBook Pro, OS X El Capitan
Install of new version of perl seemed to work just fine. However when I switch to 5.22.2 and attempt to run any of my scripts I see this error message.
dyld: lazy symbol binding failed: Symbol not found:
_Perl_xs_apiversion_bootcheck Referenced from: /Users/davidartus/perl5/lib/perl5/darwin-2level/auto/List/Util/Util.bundle
Expected in: dynamic lookup
dyld: Symbol not found: _Perl_xs_apiversion_bootcheck Referenced
from:
/Users/davidartus/perl5/lib/perl5/darwin-2level/auto/List/Util/Util.bundle
Expected in: dynamic lookup
Trace/BPT trap: 5
I've seen that some folks have had similar errors when their paths have been incorrect. My path is set by perlbrew and looks plausible to me.
/Users/me/perl5/perlbrew/bin:/Users/me/perl5/perlbrew/perls/perl-5.22.2/bin:/Users/me/perl5/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Suggestions please.
I've been following the "Getting Started" tutorial on http://swift.org. Upon creating new Swift "Hello World" project, I ran shell command:
$ swift build
and got the following output:
Compiling Swift Module 'MyProject' (1 sources)
Linking MyProject
ld: library not found for -lobjc
<unknown>:0: error: build had 1 command failures
error: exit(1): /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-02-25-a.xctoolchain/usr/bin/swift-build-tool -f /Users/petrmanek/Projekty/MyProject/.build/debug.yaml default
I'm assuming that ld: library not found for -lobjc means that the linker can't find the Objective-C standard library, however I find that hard to believe as both files /usr/lib/libobjc.A.dylib and /usr/lib/libobjc.dylib are present on my file system.
What do I do now?
My configuration is:
Hardware: Mac mini (Late 2012)
OS: Mac OS 10.11 El Capitan
uname -a
Darwin tywin 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
swift --version
Apple Swift version 3.0-dev (LLVM b361b0fc05, Clang 11493b0f62, Swift fc261045a5)
Target: x86_64-apple-macosx10.9
I think I have solved it. Here's my solution if anyone's interested.
Looking at the swift-build --help option list, I have discovered the option -Xlinker which allows me to specify flags directly for ld. I used this option to tell it to be more verbose with command:
$ swift build -Xlinker -v
The output was:
Linking MyProject
#(#)PROGRAM:ld PROJECT:ld64-242
configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m armv7k arm64
Library search paths:
/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-02-25-a.xctoolchain/usr/lib/swift/macosx
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib
Framework search paths:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/
ld: library not found for -lobjc
<unknown>:0: error: build had 1 command failures
error: exit(1): /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-02-25-a.xctoolchain/usr/bin/swift-build-tool -f /Users/petrmanek/Projekty/MyProject/.build/debug.yaml default
This was quite messy but we can see that /usr/lib is not among the library search paths. I had two options:
add /usr/lib as a search path - that didn't work because ld strives to add /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/ prefix in front of every search path I add using the -L flag
link `libobjc.dylib - that worked
Here are the shell commands I used (I did the same thing for libSystem because it required the same treatment):
$ cd /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-02-25-a.xctoolchain/usr/lib/swift/macosx
$ sudo ln -s /usr/lib/libobjc.dylib
$ sudo ln -s /usr/lib/libSystem.dylib
The swift build command is working now and the product runs correctly. However, I don't believe that is user-friendly installation process, Apple.
I have tried to install the libsvm package with
mex -setup
(since "make" resulted in an error). This was followed by one choice for a compiler, so I chose "1".
Afterwards I typed in "make" got the following error though:
xcrun: error: SDK "macosx10.7" cannot be located
clang: warning: no such sysroot directory: '-mmacosx-version-min=10.7'
libsvmread.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^
1 error generated.
mex: compile of ' "libsvmread.c"' failed.
If make.m fails, please check README about detailed instructions.
What can I do?
I think the following answer from the matlab support might be helpful (http://www.mathworks.com/matlabcentral/answers/103904-can-i-use-xcode-5-as-my-c-or-c-compiler-in-matlab-8-1-r2013a-or-matlab-8-2-r2013b):
The Mac OS X 10.7 SDK, available in Xcode 4.1 through 4.6, is used by
MEX and related capabilities. This SDK is no longer available in Xcode
5, resulting in errors similar to the following when compiling:
xcodebuild: error: SDK "macosx10.7" cannot be located.
xcrun: error: unable to find utility "clang", not a developer tool or
in PATH
The simplest solution is to avoid updating Xcode to version 5 if you
are using R2013a or R2013b. If you need Xcode 5, or you have already
irreversibly upgraded to it, you can update MEX to use the 10.8 SDK:
In the MATLAB Command Window, execute the following commands:
cd(matlabroot)
cd bin
edit mexopts.sh
Save a backup copy of this file somewhere in case you make a mistake and you need to revert your changes.
Scroll down to the Mac (“maci64”) section of this file, beginning around line 120.
Replace all instances of 10.7 with 10.8; there are four of these in all (a fifth may be found in comments only)
Save the file, then execute the following command in the MATLAB Command Window:
mex -setup
Please note that this workaround links MEX files with a different SDK
than with which MATLAB was tested. Although there are no known
compatibility issues, support may be limited.
I have 64-bit Mac, OS X 10.8.5, and I have xcode installed. I can also verify gcc works from the command line. When I type mex -setup I get
The options files available for mex are:
1: /Applications/MATLAB_R2013a.app/bin/mexopts.sh :
Template Options file for building MEX-files
0: Exit with no changes
This is unhelpful. And when I type make, with all of the relevant libsvm files in my folder of choice, I get
make
xcodebuild: error: SDK "macosx10.7" cannot be located.
xcrun: error: unable to find utility "clang", not a developer tool or in PATH
mex: compile of ' "libsvmread.c"' failed.
If make.m fails, please check README about detailed instructions.
Is anyone able to help me with this?
The quickest thing is to edit the mexopts.sh file directly, using your favorite text editor (you may need to do this with "Administrator Privileges"). The file:
/Applications/MATLAB_R2013a.app/bin/mexopts.sh
defines a bunch of paths and flags for invoking the C/C++ compiler on your system. It tends not to keep up with revisions to the MacOS.
On my system, I had to make the following changes:
lines 258-260
CC='gcc'
SDKROOT='/Developer/SDKs/MacOSX10.6.sdk'
MACOSX_DEPLOYMENT_TARGET='10.6'
line 273
CXX=g++
There will be many references to "CC=" in the file; you're looking for the ones that follow the line
maci64)
But the correct values for your system depend on which gcc/g++ you have and where they are installed. As you can see, I have the MacOS 10.6 Developer tools installed under /Develop. You will need an install of the Developer tools (XCode) - see
How to use/install gcc on Mac OS X 10.8 / Xcode 4.4
In more recent versions of the XCode tools, the path might look more like:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
But compiling MEX code with more recent versions of XCode might cause other problems - I had issues with char16_t, see:
MEX compile error: unknown type name 'char16_t'
I've been trying to get SVN to connect to Atlassian Crowd for authentication but have been running into issues with OS X Leopard Server (10.5.8) and Perl's Digest::SHA1.
I've installed it from the source (http://metacpan.org/pod/Digest::SHA1) and if I call it directly from a Perl script it works fine, but in my apache logs I get this error:
failed to resolve handler `Apache::CrowdAuth': Can't load '/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Digest/SHA1/SHA1.bundle' for module Digest::SHA1: dlopen(/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Digest/SHA1/SHA1.bundle, 1): no suitable image found. Did find:
/Library/Perl/5.8.8/darwin-thread-multi-2level/auto/Digest/SHA1/SHA1.bundle: no matching architecture in universal wrapper at /System/Library/Perl/5.8.8/darwin-thread-multi-2level/DynaLoader.pm line 230.
at /Library/Perl/5.8.8/Cache/FileBackend.pm line 15
Compilation failed in require at /Library/Perl/5.8.8/Cache/FileBackend.pm line 15.
BEGIN failed--compilation aborted at /Library/Perl/5.8.8/Cache/FileBackend.pm line 15.
Compilation failed in require at /Library/Perl/5.8.8/Cache/FileCache.pm line 20.
BEGIN failed--compilation aborted at /Library/Perl/5.8.8/Cache/FileCache.pm line 20.
Compilation failed in require at /Library/Perl/5.8.8/Apache/CrowdAuth.pm line 8.
BEGIN failed--compilation aborted at /Library/Perl/5.8.8/Apache/CrowdAuth.pm line 8.
Compilation failed in require at (eval 2) line 3.
Unfortunatley there doesn't seem to be any documentation on the error online.
Any ideas?
It seems that there is a mismatch in the compiler architecture triplet between modperl and the Perl executable. The relevant error is really just the "no matching architecture in universal wrapper", which seems to be completely OS X specific.
Are you using MacOS perl? Try building and installing a different perl, it is known that Apple did a terrible job in their perl build.
While looking for links to show Ether, I found this post which may be relevant. It's a bit old, but the mention of Apache caught my eye, since it's part of your problem:
If you've recently migrated from a 32-bit Mac to a 64-bit model, you may have run into problems with some of your Perl modules suddenly throwing up their hands and going "wha?" An AFP548 article points out the likely culprit: CPAN on the Mac compiles all of your modules as Universal 32-bit binaries by default, which tends to disappoint 64-bit applications such as Apache 2.0's mod_perl.
The fix mentioned there is to adjust your ARCHFLAGS variable. The Ars Technica post points to this link for more.