I'm having some problems with compiling Peazip on OSX (10.6). I emailed the Peazip developer and he said he probably couldn't help me too much as the error seems to be OSX specific and he doesn't have access to an OSX machine any more.
The compiler I'm using is Lazarus as the source is in Pascal.
The actual compile process seems to go ok, but when I run the peazip.app program launcher, I get the following error: http://img.photobucket.com/albums/v215/thegooddale/Screen-shot-2010-05-22-at-71907-PM.png
Here is the app launcher that the compile made: http://forboden.com/coding/peazip.app.zip - you can use an unzip program to look at the files inside (i.e. unzip it twice).
I also tried just running the peazip unix file executable that was produced after the compile from the terminal and I got this: http://img.photobucket.com/albums/v215/thegooddale/Screen-shot-2010-05-22-at-72148-PM.png
Here are the messages from the compile log from Lazarus while compiling Peazip: http://pastebin.com/qK4bdncL
(I asked on the Lazarus forums and they said I can just ignore those "ld: warning: unknown stabs type" warnings).
Here is the info from the project_peach.compiled file:
<?xml version="1.0"?>
<CONFIG>
<Compiler Value="/usr/local/bin/ppc386" Date="1238949773"/>
<Params Value=" -MObjFPC -Sgi -O1 -gl -k-framework -kCarbon -k-framework -kOpenGL -k'-dylib_file' -k'/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib' -WG -vewnhi -l -Fu/Users/yansky/Desktop/peazip-3.1.src/res/themes/crystalc/ -Fu/Developer/lazarus/components/synedit/units/i386-darwin/ -Fu/Developer/lazarus/ideintf/units/i386-darwin/ -Fu/Developer/lazarus/lcl/units/i386-darwin/ -Fu/Developer/lazarus/lcl/units/i386-darwin/carbon/ -Fu/Developer/lazarus/packager/units/i386-darwin/ -Fu/Users/yansky/Desktop/peazip-3.1.src/ -Fu. -opeazip -dLCL -dLCLcarbon project_peach.lpr"/>
</CONFIG>
I guess there's little chance that anyone here has experience with Pascal and Lazarus since it's not that popular a language and the compiler is still in beta, but I thought I would post here in the hopes that someone might point me in the right general direction about where/how the peazip.app launcher is breaking.
IIRC somewhere inside the bundle a symlink must be made.
Related
I have problems building an executable file for a simple disease-transmission model implemented in C++, using cmake under macOS Monterey (v12.6.1). When I build the executable file, I obtain the following error when I try running it:
dyld[5281]: symbol not found in flat namespace (_cblas_caxpy) Abort trap: 6
The problem persists when I try to use XCode (v14.0.1) instead, resulting in the same error message.
Interestingly, my friend is able to build (& run) the executable file under macOS v10.15.7 without any problems.
Does anybody know what is going on here and how this issue can be resolved? The C++ project is publicly available on GitHub: https://github.com/AnnaMariaL/DengueSim
Any help would be very much appreciated.
Thanks!
Anna
tried: build an executable file with cmake, and Xcode under MacOS v12.16.1
expected: executable file
the program runs fine when launched under Xcode itself, but if I try to run the built executable from Xcode on the command line, that fails with the same error as for the CMake executable. So Xcode itself is, somehow, magically able to get this linker issue to resolve.
Your title/post is very confusing, however the issue isn't with cmake. It's with your cblas library and/or your linker. Look at the bug closely:
dyld[5281]: symbol not found in flat namespace (_cblas_caxpy) Abort trap: 6
Your linker is telling you that it can't find a function (symbol) in the given namespace. This is either due to the fact that your linker doesn't know where to find the correct library or you are linking against a wrong version of the library that doesn't have the symbols. The other issues might be related to how the library was built and with what it was built (architecture, compiler, etc...). This we can't answer because we don't have enough information to know for sure.
Any help on my problem is appreciated...
I'm trying to run this program located in the sparsenet.tar.gz file at http://redwood.berkeley.edu/bruno/sparsenet/
There is a README that I try to follow but I can't seem to compile my cgf.c...
The first step I assume I did correctly (I'm pretty sure I am able to compile the libnrfopt.a).
But when I type "make" in the sparsenet directory, it says:
new-host-2:sparsenet user123$ make
mex -I./nrf -L./nrf -lnrfopt cgf.c
make: mex: No such file or directory
make: * [cgf.mexmaci64] Error 1
I assume it means my terminal isn't recognizing Mex, can anyone point me to how that works? (Before you tell me I haven't done enough searching, I have...I just cant seem to find anything relevant...I have my command line options in Xcode running, GCC works, Mex -setup works)
By the way, I'm doing this in Terminal, not inside MATLAB. Doing it inside matlab by directly using Mex doesn't work for me either.
Also I've changed the mex extensions to a variety of choices including mexmac, mexmaci64, etc.
Thanks in advance!!
I was able to get it to work (R2012b, OS X 10.8.4). The code is old though, looking at the dates on some of the files so I'm not surprised that you had issues. Following the README, first I performed make libnrfopt.a in the nrf folder using Terminal. Then, in the Matlab command window I used cd to move to the sparsenet folder and executed (the same command that that produced an error when you ran make from the Terminal):
mex -I./nrf -L./nrf -lnrfopt cgf.c
From here I was able to follow the README and run the example.
By the way, if you've never run mex in Matlab before, you may need to run mex -setup first. As you mentioned Xcode, I assume that you have the compiler you need.
Ok I figured it out, in the makefile, I just needed to change the Mex = mex to the directory of mex.exec in my Matlab folder and change mext to maci64
Yes I did put:
MEX = /Applications/MATLAB_R2012a.app/bin/mex
MEXT = mexmaci64
In case your mex setup is not alright, check mexopts.sh file and change
to gcc-4.2 and g++-4.2 in the CC options. I had these compilers. Other compilers
should work too.
In case more problems persist check out this: http://www.mathworks.nl/support/solutions/en/data/1-FR6LXJ/
I'm trying to get input from an xbox controller, I went to this page:
http://www.codeproject.com/Articles/26949/Xbox-360-Controller-Input-in-C-with-XInput
and I'm just test running his source, good thing I did because it found an error:
C:\Users\me;)\Desktop\XBOX360Test\XBOX360Test\CXBOXController.h|9|fatal error: Xinput.h: No such file or directory|
Can I don't know what the issue is, doesn't Xinput ship with windows?
I'm late I know, but I get the same error.
Opening the project in Visual Studio works fine, but compiling with gcc doesn't. Seems like the compiler of VS knows more than gcc and you need to compile it with that one. Here's how:
http://msdn.microsoft.com/en-us/library/ms235639(v=vs.80).aspx
I need to step through the Qt code to help solve a bug in my C++ application. I've downloaded qt-mac-opensource-src-4.5.2.tar from here and followed the install instructions that came with this:
unpacked the file to /tmp.
typed ./configure -debug.
typed make.
typed sudo make install.
edited the PATH environment variable as instructed.
set the DYLD_IMAGE_SUFFIX environment variable to _debug.
This installed Qt and my Qt application runs, but I still can't step into the Qt code.
I'm using Xcode 3.1.3 and tried changing the Executable Info to "use debug suffix when loading frameworks". This generated a lot of warnings like:
warning: Could not find object file "/private/tmp/qt-mac-opensource-src-4.5.2/src/corelib/.obj/debug-shared/qmalloc.o" - no debug information available for "global/qmalloc.cpp".
warning: Could not find object file "/private/tmp/qt-mac-opensource-src-4.5.2/src/corelib/.obj/debug-shared/qnumeric.o" - no debug information available for "global/qnumeric.cpp".
and also a lot of non-qt related warnings.
I'd shutdown the Macbook Pro overnight, which I can only assume clears the tmp directory as the unpacked file is no longer there.
I think I could fix it by rebuilding Qt without frameworks, but this is more of a work-around than a fix that will probably come back to bite me. I'm also a bit reluctant to do this, when each rebuild takes between 3 and 4 hours.
Alternatively, would downloading the binaries and debug libs work?
I'd be grateful for any suggestions on what I'm missing and how I address this.
Thanks.
With the help of Qt support, I've now resolved this.
There were a couple of issues:
The Qt debug "make install" doesn't currently generate dSYM files for the _debug stuff. They've raised a bug about this. To get round this:
4a. cd /usr/local/Trolltech/Qt-4.5.2/lib
4b. Type /usr/bin/dsymutil -o QtGui.framework/QtGui_debug.dSYM QtGui.framework/Versions/4/QtGui_debug
4c. Repeat for each Qt framework.
The tmp directory does indeed get wiped on each reboot. To get round this:
7- Copy the entire contents of /tmp/qt-mac-opensource-src-4.5.2 to a new directory ~/Qt .
I also added both the frameworks and source code to the Xcode project.
Have a look at this http://doc.trolltech.com/4.5/debug.html
There is a section especially for debugging under MacOSX and Xcode...
I guess you need to generate a makefile with debug option using qmake !
In OS X 10.6 and 10.6.1, setting DYLD_IMAGE_SUFFIX to _debug will cause problems. Hopefully this will be addressed by a future update of OS X 10.6.
I have a unix command line app (with big nasty makefile) that I'm trying to run on a mac. I am compiling it on a 10.6 system, with all of the appropriate libraries of course. The deployment environment is a 10.5 system, with no extra libraries.
I compiled without -dynamic, and it appears to have static libraries, correctly. When I run it on the 10.6 system, it works. However, when I run it on the 10.5 system, I get:
dyld: unknown required load command 0x80000022
I got this same error when I compiled things for the 10.6 system using the 10.5 xcode, so it looks like a version mis-match type problem. However, I used gcc-4.0, and
$CFLAGS = -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5
so it SHOULD be set up for 10.5... any ideas?
thanks
Editing an ancient question:
I have the exact same problem on a different computer. This time I am at 10.5.8, fully update, the same executable works on 10.6 still.
Has anyone had any luck with this in the months since I asked this?
The reason for the dyld 0×80000022 error can be that, you are linking on OS X 10.6, and OS X 10.6 will use a load command (LC_DYLD_INFO_ONLY = 0×80000022) that OS X 10.5 does not understand.
To fix this, make sure you are using a deployment target by setting the environment variable just before your link command:
export MACOSX_DEPLOYMENT_TARGET=10.5
(or setenv MACOSX_DEPLOYMENT_TARGET=10.5)
You can always check if your executable uses the right load command like this:
otool -l executable
It will either show LC_DYLD_INFO_ONLY (without deployment target) commands or LC_DYLD_INFO (with deployment target).
I have been searching for the same issue, as I develop on 10.6 but must have a version that works on 10.5. In addition to the compiler flags above, you should add:
-no_compact_linkedit
It is described here:
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/ld.1.html
where it says:
Normally when targeting Mac OS X 10.6, the linker will generate compact information in the __LINKEDIT segment. This option causes the linker to instead produce traditional relocation information.
I got there from a discussion on the xcode-users mailing list about "unknown required load command 0x80000022".
i was able to solve this by passing -mmacosx-version-min=10.5 to the linker, e.g. --extra-ldflags="-mmacosx-version-min=10.5" passed to configure for ffmpeg which i was building shared. more info: http://lists.apple.com/archives/xcode-users/2009/Oct/msg00530.html
Depending on how many libraries you use, it may be difficult to get all of them linked statically. What does "otool -L your_binary' tell you?
In order to get a self-contained package for an application of my own, I made a custom MacPorts install in a non-standard directory, so that I could dynlink with the libraries from that directory and only be constrained in asking people to install the whole thing in the same place on their computers. Not great, not the Mac spirit at all, but it's an Unix app and you need to be familiar with Unix to use it anyway.
Good luck
Pascal
It turns out that there is a dynamic library load function (0x22) that got added at 10.5.6. The system I was running on was 10.5.5. I upgraded to 10.5.8, and everything runs!
Ok, SECOND solution, and NOT very satisfying, is to find a 10.5.8 computer, install the developer packages and re-compile... same for powerPC... sad but it will work...