Getting a linker error on osx (no errors on linux or fbsd for the same code):
ld: duplicate symbol _dbg_char in .libs/liboekernel_la-OEK_get.o and .libs/liboekernel_la-OEK.o
the 2 libs listed in the error are mine but the symbol isn't. c++flint confirms '_dbg_char' is in both libs but I'm not sure how to find where it comes from.
tricks, strategies, outright answers for how to id _dbg_char would be greatly appreciated.
project is using libtool/autotools and gcc 4.01
Found a logging / debug macro that was defining dbg_char by 'dbg_ ## t'. fix was to make it static. lessons learned:
osx adds a leading _ to symbol names. it wasn't until i ran nm on linux and saw the same symbol without the leading _ that i thought to search the codebase for "dbg_" instead of "_dbg_"
osx was right to complain
rich irony that cut-and-pasting a debug macro i didn't fully understand caused me so much trouble
You might want to check if both libs #include a header file that declare _dbg_char but miss the extern keyword. Maybe that's #ifdef 'ed out for other platforms so you only hit that problem on OS X.
Related
I've had this error for weeks I already made a post about it but it wasn't very clear.
So I am calling a function from a a header file myBmpGris.h and the functions are implemented on the file myBmpGris.c . Here is my main file:
#include<stdio.h>
#include<stdlib.h>
#include "myBmpGris.h"
int main(){
char * image_name = "image_carre.bmp";
BmpImg image = readBmpImage(image_name);
return 0;
I compile by using ggc main.c and I get this error message :
Undefined symbols for architecture x86_64:
"_readBmpImage", referenced from:
_main in main-1c453a.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 read a lot of posts about the same error message but none of the answers seem to apply to my case. I'm kind of desperate because a lot of my programs give me the same error. What should I do ?
You need to tell the compiler about all the code files which contain any of the needed functions.
So if you have until now compiled like gcc main.c, then the simplest way of also getting the other file compiled is gcc main.c myBmpGris.c.
You might want to read up on the other things you can helpfully tell the compiler (and other parts of the building), i.e. the possible commandline parameters. Or use one of the available free programming environments. (I am not going to name any. Just use your favorite search engine on "C IDE free" or similar. The first few hits discuss several, try a few, then use the one your friends use, or the one you really like much, much better.)
There are two thing.
Compilation you have included. h file. It means comilper will make entry in symbol table for all used function from included library.
Linking here linker try to get address from library to fill in symbol table created in first step. This cannot be performed in your case. So give full path of library.
I have a GCC C based project in Eclipse CDT (Oxygen). In the Problems window, when I go I open C file in the main editor window, it lists bunch of unresolved symbols errors, many for the C and C library built-ins, like __func__.
If I understand it right this is Eclipse' indexer error, as the code compiles & builds fine.
So this is just more of annoyance issue with my Eclipse setup I want to remove. I cannot figure out what is the issue with it however. I've re-indexed N times, double checked includes, compiler / toolchain paths, still doesn't work.
The error(s) would be like:
Symbol '"__func__' could not be resolved
...
Symbol '__asm__ could not be resolved
__func__ is C standard, __asm__ is GCC/GNU keyword..
I tried something from here : https://www.eclipse.org/forums/index.php/t/636348/
no luck.
Anyone knows how to fix the indexer here? Sometimes it also fails to resolve include paths of standard C headers, even though again, the code builds just fine.
I'm trying to compile a C program using libxml2 in Eclipse. It seems like my code doesn't have problems, but there are errors when I build my project.
The error output is in this screenshot: https://drive.google.com/file/d/0BwV-0_2diIaaQlZHM2Fwa2R0LWc/edit
Before this error, I had an “Undefined reference to” error, but it was because I forgot to link the library libxml2. Now it's the problem in the screenshot. I don't what to do.
[EDITED]
I solved my problem I just need to put -nostartfiles in the linker flags.
I solved my problem I just need to write -nostartfiles in the Linker Flags box :D
To find "Linker Flags" box go to Your Project > Properties > C/C++Build > Settings > GCC C Linker > Miscellaneous
That's it.
Thanks for help.
I don't think your solution is acceptable, I think it will lead to the same problem when your project is executed in other environment (another eclipse configuration, running it from console, etc)
That error occurs when you have defined the same function more than one time in your project, and I bet it's because you have defined the same function you already had in a library.
For example, if I have lib1.h with a function called hello() and then write the same function in your main.c (having that library linked) that problem will occur.
In fact, in your image, I can see "multiple definition of __data_start"
So I think you just have to change the problematic function name and it will be fixed.
In addition, this problem will be caused if you include the same library more than once in your program, but it can be solved using preprocessor (if you are interested in this, google it, since it would be off-topic and make my answer too long)
I am compiling a program on AIX. It is compiled successfully but gives following warnings:
ld: 0711-224 WARNING: Duplicate symbol: .basename
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
I tried to find this symbol I found in my "common.o" file.
nm -X64 -f common.o | fgrep '.basename'
.basename T 3776 120
But when find this symbol on executable I find following:
nm -X64 CCF | fgrep '.basename'
.basename T 4295089984 120
.basename T 4295174672
.basename t 4295174672 40
Can I display the libraries name that contains this symbol?
Does this symbol present in my source file ? (may be sound silly but I do not really know)
I have find the answer to this question that it can be traced in source.
What steps should I take to remove this warning?
Also does this duplicate symbol can cause application crash?
In my case it is crashing.
According to the man page, there are two versions of basename(), one POSIX and one GNU, and it looks like you are linking in both of them. You will need to choose one and suppress the other, depending on your needs. The man page explains how.
Because they behave differently, code that is compiled for one will likely crash when the linker/loader binds it to the other one. If you have a choice of compilers, choosing the non-gcc one might help.
I’m trying to initialize the Metal C environment with the following code, but get the following errors on the memset line.
ERROR CCN3275 IMIJWS0.METAL.SAMPLIB(MEM):6 Unexpected text ')' encountered.
ERROR CCN3045 IMIJWS0.METAL.SAMPLIB(MEM):6 Undeclared identifier ___MEMSET.
ERROR CCN3277 IMIJWS0.METAL.SAMPLIB(MEM):6 Syntax error: possible missing ')' or ','?
CCN0793(I) Compilation failed for file //'IMIJWS0.METAL.SAMPLIB(MEM)'. Object file not created.
Below is my code
#include < string.h>
#include < stdlib.h>
#include < metal.h>
void mymtlfcn(void) {
struct __csysenv_s mysysenv;
memset ( &mysysenv, 0, sizeof ( mysysenv ) );
mysysenv.__cseversion = __CSE_VERSION_1;
mysysenv.__csesubpool = 129;
mysysenv.__cseheap31initsize = 131072;
mysysenv.__cseheap31incrsize = 8192;
mysysenv.__cseheap64initsize = 20;
mysysenv.__cseheap64incrsize = 1;
The issue was with the search order. Although I did search(/usr/metal/include) from with in my JCL I didn't proceed it with a nosearch option, so string.h was getting picked up from the standard system librarys instead of the version included with Metal C. I've pasted my optfile dataset I passed to the CPARM below for refference.
//OPTIONS DD *
SO
LIST
LONG
NOXREF
CSECT
METAL
LP64
NOSEARCH
search(/usr/include/metal/)
So, I have no idea. But some suggestions:
You might try copying/pasting this code here from this example just to make sure it works 'as expected'
Maybe try defining some of the macros here? (when I did C programming on zOS, I had to do include some weird macros in order to get stuff to work. I have no reasonable technical explanation for this.)
You could try searching for memset() using "=3.14" (from ispf.) See if any other modules use that function, and then check the headers that they include (or macros that they define - either in the C files or H files) to make it work.
Another thought: before the memset(), try doing putting a printf() in. If you get a syntax error on the same line (only for printf, rather than memset) then you can see if the problem is before line 6 - like a misplaced parenthesis.
Finally, if i recall correctly, I had to compile my individual modules, and then link them manually (unless I wrote a JCL to do this for me.) So you might have to link once to link with your other modules, and then link again against the C library. Not to be pedantic, but: you're fairly certain that you're doing all of the link passes?
I realize that's a lot of hoops to try and you've probably already read the manuals, but maybe there is something useful to try?
Also, and you probably already know this, but this site (for looking up error codes) is infinitely useful. (along with the above links for full-text-searching the manual)
Edit: this page also talks about "built-in functions" - you could try (as stated at the bottom of the page) "#undef memcpy" to use the non-built-in version?
Can you show us your compiler arguments? You need to make sure that you're not pulling in the standard C header files in addition to the metal C ones. Here's an example:
xlc -c -Wc,metal,longname,nosearch,'list(./)' -I. -I /usr/include/metal -I "//'SYS1.SIEAHDRV'" -S -qlanglvl=extended foo.c
as -mrent -mgoff -a=foo.list -o foo.o foo.s
ld -bac=1 -brent -S "//'SYS1.CSSLIB'" -o foo foo.o
Are you missing the closing brace '}' for the function? How about any missing semi-colon line terminators? When missing braces/semi-colons the z/OS C compiler throws some strange/misleading messages sometimes. I don't have it to try out, but I'm assuming Metal does as well.