For reasons that I cannot track down, there seems to be some substantial differences in the linker between 2.10 and 2.15. After fixing up some multiple defines with "extern", I've come to the point where I'm just baffled on what is different. I have functional code that works with 2.10, but with 2.15 there are some vector conflicts.
/Applications/microchip/xc32/v2.15/bin/xc32-gcc -mprocessor=32MZ2048EFH144 -DXPRJ_default=default -legacy-libc -Wl,--defsym=_min_heap_size=65536,--no-code-in-dinit,--no-dinit-in-serial-mem -o bin/serial-r312-flash.elf obj/flash_interrupts.o obj/flash_main.o
obj/main.o: In function `__vector_dispatch_24':
main.c:(.vector_24+0x0): multiple definition of `__vector_dispatch_24'
obj/flash_interrupts.o:interrupts.c:(.vector_24+0x0): first defined here
obj/flash_main.o: In function `__vector_dispatch_9':
main.c:(.vector_9+0x0): multiple definition of `__vector_dispatch_9'
obj/flash_interrupts.o:interrupts.c:(.vector_9+0x0): first defined here
/Applications/microchip/xc32/v2.15/bin/bin/gcc/pic32mx/4.8.3/../../../../bin/pic32m-ld: Link terminated due to previous error(s).
collect2: error: ld returned 255 exit status
make: *** [flash] Error 255
I have attempted to make the vectors externs, but that did not help in the least.
//interrupt.h
extern void __attribute__((vector(_TIMER_2_VECTOR), interrupt(ipl7AUTO), nomips16))SampleTimerHandler(void);
//interrupt.c
void __attribute__((vector(_TIMER_2_VECTOR), interrupt(ipl7AUTO), nomips16)){}
In main.c, I basically have a loop.
Any suggestions would be greatly appreciated.
Try defining your ISRs like that:
void __ISR(_USB_VECTOR, IPL1SOFT) USB_ISR() {
Builds clean on mine with -Wall . Also, I believe nomips16 is the new default.
EDIT: also, see comments. Apparently, an attempt to re-declare the ISR in a header file has been a contributing factor.
Related
I have a similar problem to this one, only for me it's an error not a warning. I'm building linux-4.8.5 with a patch applied to one module. I get:
ERROR: "intel_soc_pmic_readb" [drivers/gpu/drm/i915/i915.ko] undefined!
ERROR: "intel_soc_pmic_writeb" [drivers/gpu/drm/i915/i915.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1201: recipe for target 'modules' failed
make: *** [modules] Error 2
In the other question they say something about KBUILD_EXTRA_SYMBOLS and documentation is supposed to be in Documentation/kbuild/modules.txt. But reading this file, this seems only to apply to modules not included in linux itself?
The functions are defined like
int function(){
do_stuff;
}
EXPORT_SYMBOL(function);
then there is the declaration
int function();
in a .h file in the include folder and it's called like
#include <the_aforementioned_file.h>
//stuff
function();
from a file in the same folder as the definition of the function. There are no other occurrences of the function name in the whole source tree.
And I really just don't see the mistake. Most likely I'm not looking in the right place, I guess.
As explained in a comment by Tsyvarev, this error is caused because the module in question is not being built, it requires the option CONFIG_INTEL_SOC_PMIC.
Setup:
Toolchain: gcc-arm-none-eabi-5_2-2015q4-20151219
Target: STM429i-disco board
I want to run gcov and get real time report generated in target as per below link:
https://mcuoneclipse.com/2014/12/26/code-coverage-for-embedded-target-with-eclipse-gcc-and-gcov/
First, sucessfully have compiled my code (POSIX compliant NUTTX OS) with -fprofile-arcs & -ftest-coverage flags & got generated the .gcno files for my src files.
second, sucesfully have linked with -fprofile-arcs flags enabled and using the libgcov.a file (part of the toolchain) and the final binary is generated.
Now, I dont know what changes are needed in my test application to invoke gcov, generate report & dump report.
Another problem is, gcov functions are with HIDDEN attribute in libgcov.a as below.
9: 00000000 4 FUNC GLOBAL HIDDEN 1 __gcov_flush
9: 00000000 4 FUNC GLOBAL HIDDEN 1 __gcov_init
so, I could not invoke as I need.
Any inputs in getting the .gcda file generated would be of great help.
Can you look for gcov_exit instead? It is similar to __gcov_flush. Typically, it's one of gcov_exit and __gcov_flush that would be there and you can use any.
In case this is not there or is also hidden, you can use this approach which I tried for one of my projects. I picked (and modified for various reasons) the implementation of gcov_exit from gcc source code (of version matching my toolchain) (available at https://github.com/reeteshranjan/libgcov-embedded) and plugged it in my project. With everything else remaining the same (the compiler flags etc.), I was able to then break into gcov_exit and follow the rest of the approach in the blog link you have mentioned.
I'm struggling with an error whilst trying to compile GIT. I've searched Google and the GIT source issues/bugs for similar issues but i've not found anything to help me.
Originally I received the following error
root#teemo:/usr/src/git# make prefix=/usr install install-doc install-html install-info;
CC http-push.o
In file included from cache.h:39:0,
from http-push.c:1:
/usr/include/zlib.h:34:19: fatal error: zconf.h: No such file or directory
#include "zconf.h"
^
compilation terminated.
make: *** [http-push.o] Error 1
I created a symbolic link inside /usr/include/ to the missing file as follows (after I had installed/compiled the latest/development version)
root#teemo:/usr/src/git# ln -s /usr/include/x86_64-linux-gnu/zconf.h /usr/include
Which brings me to the current issue, which I am confused as to how to solve. If someone could advise it would be greatly appreciated.
root#teemo:/usr/src/git# make prefix=/usr install install-doc install-html install-info;
CC http-push.o
In file included from /usr/include/curl/curl.h:35:0,
from http.h:6,
from http-push.c:5:
/usr/include/curl/curlrules.h:142:3: error: size of array '__curl_rule_01__' is negative
__curl_rule_01__
^
/usr/include/curl/curlrules.h:152:3: error: size of array '__curl_rule_02__' is negative
__curl_rule_02__
^
make: *** [http-push.o] Error 1
Read higher up in curlrules.h. That error is intentionally forced as part of a test that checks the size of data types.
* NOTE 2
* ------
*
* Some of the following compile time checks are based on the fact
* that the dimension of a constant array can not be a negative one.
* In this way if the compile time verification fails, the compilation
* will fail issuing an error. The error description wording is compiler
* dependent but it will be quite similar to one of the following:
*
* "negative subscript or subscript is too large"
* "array must have at least one element"
* "-1 is an illegal array size"
* "size of array is negative"
*
* If you are building an application which tries to use an already
* built libcurl library and you are getting this kind of errors on
* this file, it is a clear indication that there is a mismatch between
* how the library was built and how you are trying to use it for your
* application. Your already compiled or binary library provider is the
* only one who can give you the details you need to properly use it.
Your version of libcurl was built with different options than you're using in your current git build. (it could be 32 vs 64 bit)
Knowing what platform you're on and your build options might be enough others to help resolve it. If this is the common case, and you're on Linux or another supported platform, it'd be easier just to install a prebuilt binary using the native software management. Git downloads
In case system reports __curl_rule_01__ or __curl_rule_02__ is negative make the following changes to /usr/include/curl/curlbuild.h:
Add the following lines:
define CURL_SIZEOF_LONG 4
define CURL_SIZEOF_CURL_OFF_T 4
(Or replace similar lines if these are already defined)
I'm using 64-bit gcc-4.8.2 to generate a 32-bit target, and my machine is 64-bit. I'm using c++11 concurrency features such as thread, mutex, conditiona_variables and etc.
The linker gave the above error message when trying to link the executable. libMyLib is also part of the project.
libMyLib.so: undefined reference to '__gthrw___pthread_key_create(unsigned int*, void (*)(void*))
nm libMyLib.so | grep pthread_key_create shows:
U _ZL28__gthrw___pthread_key_createPjPFvPvE
w __pthread_key_create##GLIBC_2.0
where is the symbol 'ghtrw___pthread_key_create' from? I tried adding '-lpthread(-pthread)' as compiler flag, but it does not help.
More information. nm libMyLib.so | grep pthread shows other symbols such as _ZL20__gthread_mutex_lockP15pthread_mutex_t is defined
where is the symbol 'ghtrw___pthread_key_create' from?
It is defined in GCC's "gthreads" abstraction layer for thread primitives, in the gthr-posix.h header.
#if SUPPORTS_WEAK && GTHREAD_USE_WEAK
# ifndef __gthrw_pragma
# define __gthrw_pragma(pragma)
# endif
# define __gthrw2(name,name2,type) \
static __typeof(type) name __attribute__ ((__weakref__(#name2))); \
__gthrw_pragma(weak type)
# define __gthrw_(name) __gthrw_ ## name
#else
# define __gthrw2(name,name2,type)
# define __gthrw_(name) name
#endif
/* Typically, __gthrw_foo is a weak reference to symbol foo. */
#define __gthrw(name) __gthrw2(__gthrw_ ## name,name,name)
...
#ifdef __GLIBC__
__gthrw2(__gthrw_(__pthread_key_create),
__pthread_key_create,
pthread_key_create)
After preprocessing that expands to:
static __typeof(pthread_key_create) __gthrw___pthread_key_create __attribute__ ((__weakref__("__pthread_key_create")));
It is supposed to be a weak reference to __pthread_key_create, so it should never have a definition, because it is just a reference to glibc's internal __pthread_key_create symbol.
So it looks like something has gone wrong with how you build you library. You should not have an undefined weak symbol.
I recently stumbled into this error, and not because of a missing -pthread.
The situation happened in a somewhat unusual setup: I was compiling a software written in C++14 under Centos7. Since C++14 requires a recent version of GCC, I relied on devtoolset 6 for it.
Given the specific setup, I opened a thread on the Centos mailing list, so I'm directly referencing the relevant thread. See https://lists.centos.org/pipermail/centos-devel/2018-May/016701.html and https://lists.centos.org/pipermail/centos-devel/2018-June/016727.html
In short, it might be caused by some bug in the preprocessor macros, either of glibc or libgcc. It can be fixed by placing #include <thread> in the beginning of the source code which gives problems once compiled. Yes, even if you don't use std::thread in it.
I don't claim this will work for everyone, but it might do the job in some particular situations.
When building the latest grub2 (2.00) I get this error.
I have tried adding -Wno-unused-function to both HOST_CFLAGS, HOST_CPPFLAGS, TARGET_CPPFLAGS and TARGET_CFLAGS in the Makefile. I even tried deleting that function whilst make was running!
Unfortunately the error remains.
Have you seen this?
The latest flex makes the GRUB-2.00 build fail. I can work around the issues with --disable-werror, but grub-core/script/yylex.l causes two warnings that do not work with -Werror.
./grub-core/script/yylex.l: At top level:
grub_script.yy.c:2351:13: error: 'yy_fatal_error' defined but not used
This can be fixed by removing #define YY_FATAL_ERROR(msg) in yylex.l.
However, according to this post this seems to have been fixed.
Judging from the info on the net you either want to switch to grub 2.02 or try an older version of flex.