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.
Related
While compiling cobalt for raspberry pi on ninja, im getting an error like this:
undefined reference to symbol 'eglCreateImageKHR'
here is the full trace:
[1/1] LINK cobalt
FAILED: cobalt
/home/mi07/work/raspitools/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++ #cobalt.rsp
/home/mi07/work/raspitools/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: obj/starboard/raspi/2/../shared/open_max/starboard_platform.decode_target_create.o: undefined reference to symbol 'eglCreateImageKHR'
/home/mi07/work/raspitools/sysroot/opt/vc/lib/libbrcmEGL.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
I googled it and found somewhat related article on this site.
As per this article the fault could be that of libssl1.0-dev not being there. I checked and found it was libssl-dev. Replaced it with libssl1.0-dev but still the error persists.
Can somebody tell me what is going wrong?
eglCreateImageKHR() is an EGL extension EGL_KHR_image. Since Cobalt compiled, it appears the headers declare the extension, but the linked EGL library didn't define it. It's surprising that only eglCreateImageKHR() is missing and not eglDestroyImageKHR as well.
At any rate, I recommend trying to update the EGL library, but I'm not familiar with the raspi install, so can't tell you the specifics.
Alternatively, it is safe to comment out the call to that function in decode_target_create.cc since SbImageIsDecodeSupported() always returns false for raspi (see image_is_decode_supported.cc), so decode targets should never be created / destroyed on the platform. (Decode target support is a work in progress for raspi.)
I resolved this by changing the os itself. The problem was that the cobalt was not compatible with raspi stretch but with raspi jessie. Because sysroot files are being copied from the OS it was creating that error. I don't know exactly where the difference is but changing to raspi jessie worked fine for me.
We're getting ready to deploy our application (Cytoscape) for Windows, Linux and Mac.
We find that when Java 9 is installed on Fedora 26 64 bit, trying to run the installer gives "JVM must be greater than 1.6", though our JVM range is set to 1.8.0_152...1.9.
Is there a later installer/launcher version that gives a more informative error message? ... could we have something misconfigured??
On the same platform, but with Java 10 installed instead, the launcher apparently allows execution to commence (despite our JVM range). This ends badly, as Karaf complains:
/opt/Cytoscape_v3.6.1/framework/bin/karaf: line 242: [: : integer expression expected
-Djava.endorsed.dirs=/usr/java/jdk-10/jre/lib/endorsed:/usr/java/jdk-10/lib/endorsed:/opt/Cytoscape_v3.6.1/framework/lib/endorsed is not supported. Endorsed standards and standalone APIs
in modular form will be supported via the concept of upgradeable modules.
Error: Could not create the Java Virtual Machine.
Error: A fatal exceThe programmes occurred. Program will exit.
Is the launcher somehow misidentifying the JVM? Shouldn't it give an informative error and stop the launch (including Karaf) from proceeding?
Thanks!
I am building Swift compiler from source on CentOS 6, and am running into a library issue. After fighting with the build script for a while I have got where running ./utils/build-script eventually gives:
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake --build /home/src/swift/build/Ninja-DebugAssert/cmark-linux-x86_64 -- all
ninja: no work to do.
llvm: using standard linker
+ cd /home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ '-DCMAKE_C_FLAGS= ' '-DCMAKE_CXX_FLAGS= ' -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_TOOL_SWIFT_BUILD:BOOL=NO '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_INCLUDE_TESTS:BOOL=TRUE -LLVM_INCLUDE_DOCS:BOOL=TRUE -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINTERNAL_INSTALL_PREFIX=local /home/src/swift/llvm
CMake Error at cmake/modules/CheckAtomic.cmake:36 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:296 (include)
CMakeLists.txt:403 (include)
-- Configuring incomplete, errors occurred!
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
./utils/build-script: command terminated with a non-zero exit status 1, aborting
(gcc-4.8.2 was what I compiled llvm with)
libatomic is there:
$ locate libatomic
/opt/gcc-4.8.2/lib64/libatomic.a
/opt/gcc-4.8.2/lib64/libatomic.la
/opt/gcc-4.8.2/lib64/libatomic.so
/opt/gcc-4.8.2/lib64/libatomic.so.1
/opt/gcc-4.8.2/lib64/libatomic.so.1.0.0
I just don't know how to tell the build system where to look. I have tried the usual CMAKE_LIBRARY_PATH (exporting on the command line - I am not sure if cmake works like the way LD_LIBRARY_PATH, LIBRARY_PATH work) but it can't seem to find it.
I also don't have root on the machine.
I had not tried building from source on CentOS 6 until I saw this question, but I have been able to build Swift 2.2 on CentOS 7.1 and Ubuntu 14.04, with partial success. A few things to think about:
You will need numerous dependencies required to build Swift, and unless
they happen to be already on the system, you will need root access to
install them.
Use -R flag with the build-script to create a release build.
Building in DebugAssert (the default) will require a lot of memory. In my case even 14 GB was not sufficient. A release build
can be done with about 6 GB.
As for your specific problem, it is related to Clang's dependency on GCC-related packages for headers and libraries. See, for example, Fedora 21 with clang, without gcc.
Even if you installed GCC 4.8.2 and adjusted the path to use gcc and g++ from 4.8.2, Clang may still be looking in the old GCC directories for headers and libraries. CMake first tries to compile a C++ test file that includes the header atomic, which does not exist in the old GCC. So, it then tries to link a C test program that uses the library libatomic, which again doesn't exist in the old GCC. You can see this by looking at llvm/cmake/modules/CheckAtomic.cmake mentioned by usr1234567. CMakeError.log and CMakeOutput.log can also provide valuable insight. BTW, when I was building Swift on CentOS 7.1, I didn't run into this problem because GCC 4.8.2 was used by Clang for headers and libraries and the atomic header was found, so the C++ file got compiled. However, had the libatomic check been done, it would have failed, because libatomic.so in the repository-provided 4.8.2 has INPUT ( <name of some non-existent file> ), so trying to link with libatomic errors out.
I'm sure there are various ways of dealing with this issue, but what solved the problem for me was setting the following environment variables, please adjust to your specific setup:
export CPLUS_INCLUDE_PATH=/opt/gcc-4.8.2/include/c++/4.8.2:/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu
export LIBRARY_PATH=/opt/gcc-4.8.2/lib64:/opt/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Also make sure that your 4.8.2 version of libstdc++.so is available to the dynamic linker at runtime. Since you don't have root, do
export LD_LIBRARY_PATH=/opt/gcc-4.8.2/lib64
If you had root, you could use ldconfig.
Before you start building Swift, you may want to try building, using Clang, a simple C program linking it with libatomic (the code doesn't actually have to use any symbols from the lib) and a simple C++ program that includes the <atomic> header. When compiling the C++ program, use the -std=c++11 compiler flag. If the C++ program compiles successfully, then it is not necessary for the libatomic linking test to be successful.
Interestingly, the CMakeOutput.log file still did not report finding GCC 4.8.2 as a candidate GCC installation, but the configuration/build worked well past the error.
Hopefully this helps. Please let us know if you run into something else.
CheckAtomic.cmake seems to be part of LLVM. I found a file at Github and it tries to find '__atomic_fetch_add_4' from libatomic
check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
This fails for you. Check CMakeFiles/CMakeError.log to get more details why this test failed. Or try this line in a new project.
I am installing Redmine and I am getting crazy because of a rake problem. In particular, in order to perform a bundle install for the different Ruby's plugins, I have been asked to install xapian-full-alaveteli, v 1.2.9.5.
The problem is that I get the following error:
Building native extensions. This could take a while...
ERROR: Error installing xapian-full-alaveteli:
ERROR: Failed to build gem native extension.
/home/redmine/.rvm/rubies/ruby-2.2.0/bin/ruby -rubygems /home/redmine/.rvm/rubies/ruby-2.2.0/lib/ruby/gems/2.2.0/gems/rake-10.4.2/bin/rake RUBYARCHDIR=/home/redmine/.rvm/gems/ruby-2.2.0/extensions/x86_64-linux/2.2.0/xapian-full-alaveteli-1.2.9.5 RUBYLIBDIR=/home/redmine/.rvm/gems/ruby-2.2.0/extensions/x86_64-linux/2.2.0/xapian-full-alaveteli-1.2.9.5
rake aborted!
NameError: uninitialized constant Config
/home/redmine/.rvm/gems/ruby-2.2.0/gems/xapian-full-alaveteli-1.2.9.5/Rakefile:2:in `<top (required)>'
(See full trace by running task with --trace)
rake failed, exit code 1
Gem files will remain installed in /home/redmine/.rvm/gems/ruby-2.2.0/gems/xapian-full-alaveteli-1.2.9.5 for inspection.
Results logged to /home/redmine/.rvm/gems/ruby-2.2.0/extensions/x86_64-linux/2.2.0/xapian-full-alaveteli-1.2.9.5/gem_make.out
I've tried editing by hand the rakefile and removing the line that causes troubles, but it magically reappears. The documentation about the use of rake/gem is, imho, at least vague, therefore I am totally stuck -- with a server that was supposed to be in production two days ago...
Summary
Obsolete calls to Config can cause the error. Try changing
Config::CONFIG ====> RbConfig::CONFIG
In detail
Running a Gem's rakefile caused the error: uninitialized constant Config.
Googling suggests Config is obsolete and to replace it with RbConfig. RbConfig is in the latest Ruby though the document is blank and I cannot find a Config in Ruby.
Fixes replace Config with RbConfig: gettalong/kramdown and thoughtbot/cocaine. Which also worked in my case.
Conclusion
Replace Config::CONFIG with RbConfig::CONFIG
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'