In a GNU LD linker script, I have the following code
_. = ASSERT((__SEC1_FREE_END - __SEC2_VAR_START)>= 128,"Report error");
The above command does not report an error if __SEC2_VAR_START is greater than __SEC1_FREE_END,
i.e when the subtraction operation evaluates to be a negative number the linker does not report an error and exit as expected.
I scanned through several documentation files but could not find if any typecasting is done while evaluating the expressions in linker scripts.
How can we explain the behaviour exhibited here?
Related
I am using dev c++ for practicing data structures in C. After compiling any program, it runs for the first time.In subsequent runs,
the compiler shows following error:
dev-cpp\collect2.exe [Error] ld returned 1 exit status
What error is the compiler pointing out??
There's unfortunately not much information to go on. One thing that's always helped me so much, when troubleshooting mysterious GNU LD errors, is using the --cref -Map=$#.map flags (where $# is the name of the output file). It'll save a report explaining every single decision the linker makes, in painstaking detail.
I'm trying to compiler c code using Hightec compiler under win7 64bit operating system. Here is my sample Batch code for compiling:
Root\HightecInstall\bin\ppc-vle-gcc -fno-inline -c -o sample.o sample.c
This is only a sample code with the compiler options "-fno-inline". After I run the batch file, I got an error saying "unknown compiler options -no-inline". But what I input is "-fno-inline". So there is a missing letter "f". I have tried with other options and the output always gave me "unknown compiler options ***" which misses one or two letter at the beginning. For example. -DDefault -> unknown -efault. I don't really understand how that could happen and how could the compiler discard the first one or two letters. Does anyone have some suggestions? Thanks.
Bo
I have a large, mixed (C, C++) workspace with a complex make file layout. I'm porting in a new library, and working through compilation issues. I have a GNU linker error (in what I am pretty sure is entirely sourced from C code in this instance) of the form:
path/to/object_file.o: In function `function_name':
(.text+0x0x11e4a0): undefined reference to `missing_function'
Now, it is my expectation that if I execute the "strings" command on object_file.o, I should see reference to both function_name and missing_function. I find neither. If I peruse the output of "strings," I do see other symbols that I recognize, so it is not mangling everything.
Is it possible that the linker error message is inaccurate?
I did find the command which builds object_file.o. It is another linker of a bunch of .a files. I executed "strings" on each of them, and did not find function_name in any of them.
So, I am trying to find the build process steps that lead up to this error, as I am not sure that function_name is relevant in this linking step. Any tips on how to do this are appreciated.
When using Cygwin and GCC under Win 7 and the quad precision library:
gcc -c lquad.c
... this runs OK, but
gcc lquad.o
... produces the following error:
/tmp/ccLM2lOn.o:lquad.c:(.text+0xdb3): undefined reference to `sqrtq'
collect2: error: ld returned 1 exit status
I have #include quadmath.h in a C source, and the __float128 type works, but not the functions (e.g. sqrtq above). This header file has all the relevant externs, e.g.:
extern __float128 sqrtq (__float128) __quadmath_throw;
I found a dll cygquadmath-0.dll which definitely has these functions in it. It is in 3 places in the Cygwin installation. Additionally, I copied it to Windows\System, but that did not help.
There is a related question here, but nothing helped me there and it is not exactly the same error: Quadruple Precision in C++ (GCC)
You are looking for a compiler solution when what you need is a linker solution:
Your code is compiling as it should, so no change in the code would solve your problem:
/tmp/ccLM2lOn.o:lquad.c:(.text+0xdb3): undefined reference to `sqrtq'
collect2: error: ld returned 1 exit status
The undefined reference to errors indicate a function needed by your object is in another library.
As suggested by #Marc Glisse, try adding -lquadmath to your linker line.
Im trying to compile z/lib on z/OS USS(thats right a mainframe). ive got gmake and the c89 compiler (which im assuming is c89 standards compliant) and USS is supposed to be POSIX compliant.
But zlib seems to be tripping up on
struct internal_state FAR *state; /* not visible by applications */
with the following error(s)
c89 -O3 -DUSE_MMAP -D_XOPEN_SOURCE_EXTENDED=1 -D_POSIX_SOURCE -c -o example.o example.c
ERROR CCN3277 ./zlib.h:92 Syntax error: possible missing ';' or ','?
ERROR CCN3007 ./zlib.h:92 "struct internal_state" is undefined.
ERROR CCN3166 ./zlib.h:103 Definition of function FAR requires parentheses.
ERROR CCN3276 ./zlib.h:103 Syntax error: possible missing '{'?
ERROR CCN3273 ./zlib.h:124 Missing type in declaration of gz_header.
ERROR CCN3166 ./zlib.h:126 Definition of function gz_header requires parentheses.
ERROR CCN3276 ./zlib.h:126 Syntax error: possible missing '{'?
WARNING CCN3137 ./zlib.h:1346 Declaration must declare at least one declarator, tag, or the members of an enumeration.
ERROR CCN3275 ./zlib.h:1350 Unexpected text z encountered.
ERROR CCN3282 ./zlib.h:1350 The type of the parameters must be specified in a prototype.
ERROR CCN3275 ./example.c:95 Unexpected text file encountered.
ERROR CCN3045 ./example.c:95 Undeclared identifier gzFile.
ERROR CCN3046 ./example.c:96 Syntax error.
ERROR CCN3045 ./example.c:98 Undeclared identifier file.
ERROR CCN3019 ./example.c:523 Expecting an array or a pointer to object type.
ERROR CCN3280 ./example.c:527 Function argument assignment between types "const char*" and "int" is not allowed.
CCN0793(I) Compilation failed for file ./example.c. Object file not created.
FSUM3065 The COMPILE step ended with return code 12.
FSUM3017 Could not compile example.c. Correct the errors and try again.
gmake: *** [example.o] Error 3
when i progressively take out the FAR * (i think its a far pointer but im really not that sure) the errors go away. But as this is a library, im not sure what other artifacts are going to be produced by removing this.
has anybody got any ideas?
any old mainframe heads out there?
it turns out there is a previous version of zlib that compiles on USS, version 1.1.4 or close to that. Its a back level, but i presume this works because it is before the implementation of the FAR pointer in the latest code. So atm i think ive got it to work.
thanks for all your help.
Regards
Mark.
FAR is not a C89 keyword, it is a Microsoft/Intelism and is probably #defined somewhere. If not, you need to define it as nothing:
#define FAR
However, this will probably only fix one of many problems. I would guess that the library uses some form of conditional compilation to handle things like FAR pointers - you need to read the docs to find which configuration is most suitabkle for your platform.
I'd use xlc instead of c89 since xlc is your system default compiler but you'll still probably have issues. I'd subscribe to the MVS-OE email list, the people on it are quite helpful. The link to info about the list appears to be down now so send email to
LISTSERV#VM.MARIST.EDU
with the message: INFO MVS-OE
FWIW, IBM provides a prebuilt version of zlib that includes support for the compression hardware (so-called zEDC) available on recent-vintage mainframes. See zlib for zEnterprise Data Compression