I want to install the Boehm garbage collector garbage collector on MacOS. I looked at this guide but it did not help; invoking brew install libgc did nothing. Here is my example code that I am trying to run:
#include <gc/gc.h>
int main() {
void* eight_bytes = GC_MALLOC(8);
}
Unfortunately, I get this error:
Undefined symbols for architecture x86_64:
"_GC_malloc", referenced from:
_main in boehm_invocation-369838.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Does anyone know of a good way to install this GC without building it from source?
When I installed libgc on mac, as you did, the files were installed to /usr/local/Cellar/bdw-gc/. Then, when it came time to compile my code I had to run:
$ LIBGC=/usr/local/Cellar/bdw-gc/VERSION/
$ gcc ... -I$LIBGC/include/ ... $LIBGC/lib/libgc.a other.a ...
When you install libgc, its not included in your system path. You need to explicitly add it.
Also in my code I used:
#include "gc.h"
And not <gc/gc.h>.
Related
I am attempting to compile a C program on macOS Catalina. The program will make use of bzip2 decompression. My code includes the line
#include <bzlib.h>
and I am trying to call the function BZ2_bzBuffToBuffDecompress. However, when I run gcc myfile.c -o myfile.c.o, I get the following error:
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1
I am just using a plain text editor and gcc, no IDEs and no CMake files. I suspect I may need a CMake file for this but I am not really sure how to proceed. Any assistance with this is greatly appreciated!
You need to link in the bzip library. gcc myfile.c -o myfile -lbz2. That command assumes the lib is installed into the standard location. Also, you are compiling a final executable so (by strong convention) it should not have a .o suffix.
I am self learning to code in C using Mac mini M1 and VS Code. I get the below error:
Undefined symbols for architecture arm64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Please note:
Installed the VS Code Insiders for ARM apple version!
Clang is installed!
Xcode command line tools installed!
C/C++ 1.4.0-insiders2 extension is installed in VS Code!
Code Runner 0.11.4 is installed in VS Code!
Code:
#include <stdio.h>
int main()
{
printf("test");
return 0;
}
Compiled using:
gcc -Wall -Wextra -Werror -o test test.c
Okay! It's because you forget to save your program before executing i.e you should compile and run. Instead of just running it! #Keeplearning!
I have a MATLAB function that has signal processing and machine learning and I wanted to test it on another OS like linux. So I use codegen to generate C code for that function. When I come to run it (predictActivityFromSignalBuffer) on the command line, this is what I get:
MacBook-Pro-2:predictActivityFromSignalBuffer kareem$ gcc predictActivityFromSignalBuffer.c
Undefined symbols for architecture x86_64:
"_featuresFromBuffer", referenced from:
_predictActivityFromSignalBuffer in predictActivityFromSignalBuffer-1a1886.o
"_main", referenced from:
implicit entry/start for main executable
"_mynn", referenced from:
_predictActivityFromSignalBuffer in predictActivityFromSignalBuffer-1a1886.o
"_rtIsNaN", referenced from:
_predictActivityFromSignalBuffer in predictActivityFromSignalBuffer-1a1886.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
What is this error telling me exactly? I have no idea how to debug this or where to start/look.
Did you really just call
$ gcc predictActivityFromSignalBuffer.c
without any other dependencies? Usually there come a lot of other files with a code generation that have to be linked.
I do not know what you have done to produce your .c file. I recommend to use the coder wizard by typing
coder
in the Matlab command window. This will guide you through the whole process of code generation and also offers a lot of support and testing possibilities. You can also choose to compile your functions to ready-to-use DLL libraries or executatables. Just have a look at it.
I'm having some trouble somewhere with the linker while trying to compile a test written using the Unity testing framework by Throw The Switch. I have other tests that compile and run perfectly fine so I'm definitely just missing something in enabling the assertion helper for double floating point comparisons.
There is documentation in the header file telling us how to enable double floating point comparisons.
* - define UNITY_INCLUDE_DOUBLE to allow double floating point comparisons
However, I end up with this error:
Undefined symbols for architecture x86_64:
"_UnityAssertDoublesWithin", referenced from:
_test_example in main-6fae82.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I wrote up the simplest example possible to duplicate this:
#define UNITY_INCLUDE_DOUBLE
#include "unity.h"
void test_example(void)
{
TEST_ASSERT_EQUAL_DOUBLE(1.234, 1.234);
}
int main(void) {
UNITY_BEGIN();
RUN_TEST(test_example);
return UNITY_END();
}
The contents of the CWD of the example and the exact command used to call clang (showing the same error again):
$ ls
main.c unity.c unity.h unity_internals.h
$ clang unity.c main.c
Undefined symbols for architecture x86_64:
"_UnityAssertDoublesWithin", referenced from:
_test_example in main-ee77c2.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Same exact thing happens with gcc (but it's actually just calling clang under the hood).
I'm pretty sure I'm just missing one tiny step but for the life of me I can't see what it is right now. Thanks in advance for your help.
I have this working on my minimal tests by using the same define in the unity_config.h file and adding UNITY_INCLUDE_CONFIG_H as a compiler -D flag (gcc). But running with the #define in the source does not do the same trick
You can find a full copy of a unity_config.h file on the ThrowTheSwitch GitHub repo. I usually just throw it in the same folder Unity is in.
It also works if you add the define directly into the unity.h file as specified in the comments in that file (that you quote in your question) which says
All options described below should be passed as a compiler flag to all files using Unity. If you must add #defines, place them BEFORE the #include above.
i.e. in unity.h
#define UNITY_INCLUDE_DOUBLE
#include "unity_internals.h"
...
Why your initial tactic, which should essentially be the same thing, does not work, I do not know.
Looks like this works when defining UNITY_INCLUDE_DOUBLE with the -D flag to clang/gcc. For example:
$ clang -DUNITY_INCLUDE_DOUBLE -DUNITY_DOUBLE_PRECISION=1e-12f unity.c main.c
$ ./a.out
main.c:10:test_example:PASS
-----------------------
1 Tests 0 Failures 0 Ignored
OK
I'm trying to use ODE in my C project on Xcode 4.5.1 (MacOS 10.8). I used
./autogen.sh
./configure
make
sudo make install
to install the lib. I then tried to compile a test program:
#include <stdio.h>
#include <ode/ode.h>
int main(int argc, const char * argv[]) {
dWorldID world = dWorldCreate();
return 0;
}
I added dSINGLE in Build Settings->Preprocessor Macros and libode.a in my Xcode project.
When I try to build and run I get a bunch of errors like
Undefined symbols for architecture x86_64:
"std::terminate()", referenced from:
_dJointGroupCreate in libode.a(ode.o)
_dBodyCreate in libode.a(ode.o)
dxJointBall::dxJointBall(dxWorld*) in libode.a(ball.o)
dxJointBall::dxJointBall(dxWorld*) in libode.a(ball.o)
dxJointFixed::dxJointFixed(dxWorld*) in libode.a(fixed.o)
dxJointFixed::dxJointFixed(dxWorld*) in libode.a(fixed.o)
dxJointHinge::dxJointHinge(dxWorld*) in libode.a(hinge.o)
...
.
.
.
.
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The very same procedure works fine if I create a C++ project instead of a C one.
Did I forget to add something in the build settings in order to make it work?
Solved adding
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/libstdc++.dylib
to the Xcode project.