Closed ohagendorf closed 8 years ago
with a manual created '.temp' dir the execption disappears but that works just once because it is deleted after exporting
and the generated gcc_arm/coide zip project files are nearly empty like the uvision/uvision5 files
I'm using Windows 10, maybe under linux it is working ...
I just merged #1912 , that should solve it . Please rerun , and let us know. I tested gcc arm and uvision.
@ohagendorf coide exports, but seems like c99 is not enabled there (I tested with kl25z as I built the lib earlier). Can you please provide details if you find anything?
I am seeing weird errors from various IDE, for instance LPC1768 for uvision with full sources, it does not compile. It complains about i2c_start
not defined, that seems correct as it's defined as inline i2c_start()
in the C code file. according to c99, it should be private to that compilation unit. But I have not seen this error, neither others I am seeing now. All this is for uvision, I'll need to investigate
Additional to missing i2c_start
and i2c_stop
I've got several other Undefined symbols.
With several
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif
in hal_tick.c
, system_stm32f7xxx.c
and mbed_overrides.c
around the function declarations of HAL_IncTick
, us_ticker_irq_handler
, HAL_Init
the first problem was solved.
The i2c_start
and i2c_stop
problem could only be solved be removing inline
@ohagendorf Does that look like c files are compiled with c++ compiler? To me that would be the only explanation to some errors I am seeing, but could not spot the change causing this in the code base.
No, in the project file they are all FileType 1, same as the other .c files. Filetype 8 is used by .cpp files. So that could not be the reason.
I probably spot the issue , there's --cpp
flag for cxx flags, which is fine for cxx ,but in the exported project is set for c/c++ and that's the problem. In the docs on keil site This option is implicitly selected for files having a suffix of .cpp, .cxx, .c++, .cc, or .CC.
means we don't need this option anyway. Once you remove it , lot of errors are gone for me with various projects. I'll prepare a fix
Thanks for the fast solution.
It's still broken, at least if I generate a project with full sources there're duplicated symbols (.o files and also sources, thus like system , startup or others are duplicated). We have to investigate
cc @screamerbg
I don't have problems with something like this:
project.py -m NUCLEO_F767ZI -i uvision5 -p 28
or
project.py -m NUCLEO_F767ZI -i gcc_arm -p 28
as I had before.
I Am closing this, as it was resolved. the issue I reported here , I created a separate ticket for it to track it.
After PR #1893 project.py does not work any longer. The generated zip files are nearly empty or an exception is generated. In the following some examples:
Exporting to gcc:
Exporting to coide
Exporting to uvision/uvision5:
cc @screamerbg @theotherjimmy @sg- @0xc0170