I'm programming with libjpeg and the problem came. Fortunately, I found some answers here and tried feeding from jpeg_mem_src() rather than jpeg_stdio_src(), compiling pyd file with VS2010 or gcc, analyzing pyd with dependencywalker and adding some dlls. But these solutions all failed.
Could anyone tell me how to fix it?
Related
I haven't found this file referenced anywhere but, after compiling my .f file, the exe returns this error:
The code execution cannot proceed because msys-gfortran-5.dll was not found. Reinstalling the program may fix this problem.
I had a similar issue asking for a msys-2.0.dll file but I found that one online later.
I played around with different variants such as UCRT64, MINGW64, MINGW32 but to no avail.
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.
I'm trying to use ROS for Windows for the first time, with a package that was previously developed in Linux.
Doing the catkin_make I find this error:
LINK : fatal error LNK1104: cannot
open file 'rt.lib'
I think the problem is in my CMakeLists.txt where I have:
target_link_libraries(omni_state HD HDU rt ncurses ${catkin_LIBRARIES})
I had a similar problem with HD.lib and HDU.lib, bacause I guess that the automatic find_path doesn't work well (or at all :P) in Windows. So I added
link_directories(path_to_lib_dir)
solving the problem. I would like to do the same thing for rt, but I can't find rt.lib in my PC. I also searched how to download it but I can't find a way.
Can someone help me?
So, I was developing an awesome project running Linux and I need to make the port on Windows. Problem is, the libyaml is part of my dependencies, and I need to compile it for Windows.
So I got my cygwin environment running, I ran ./configure and make, and everything went well : the library was built, I got the .a file.
Except that the makefile never ended because it couldn't build the examples : turns out some symbols are missing from the library :
undefined reference to `_imp__yaml_parser_initialize'
undefined reference to `_imp__yaml_parser_set_input_file'
undefined reference to `_imp__yaml_parser_scan'
undefined reference to `_imp__yaml_token_delete'
undefined reference to `_imp__yaml_parser_delete'
So of course, wondering how could this possibly be true, I went on searching said symbols, and I, in fact, found them in the binary, although the symbol is a tiny bit different as you can see :
$ nm src/.libs/libyaml.a | grep parser_set_input_file
000005a8 T _yaml_parser_set_input_file
So, this is usually how function name are presented when I compile a dinamicaly loadable library. What buzzes me is, WHY can't the linker find these functions ? Where does this imp come from ?
And what can I do so that my programs can link properly to the libyaml ? Everything else is working just as it should except for these functions.
Will you be the one to save me from this devilish compilo-linking stuff ?
I thank thee for your attention.
EDIT: I've been working on this problem for a few more hours now.
So, apparently it MAY come from mingw : the gcc from cygwin doesn't have any issue in compiling the examples.
However the errors remain, even if I try to do so with the cygwin's gcc. I'm starting to get sick of this retarded OS. Everytime I'm developing on Windows I spend more time solving problems than actually working. Why does it always have to be such a pain ??
Isn't there an EASY way to explain the linker not to search for mangled name of those functions ?
EDIT: I found this :
http://cygwin.com/ml/cygwin/2001-04/msg00942.html
Seems like a similar problem someone was having with ncurses. Though I haven't been able to make anything out of this.
Old thread, but the answer is still unclear. The following works for version 0.1.5:
./configure CFLAGS="-DYAML_DECLARE_STATIC" --enable-static --disable-shared
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.