From my article last year, I have shown how to build up the source tree for the legacy of NXT source code. With the proper configuration, i.e., set up the path for ARM cross compiler in toolgcc.mak, directly under the sample folder, we should be able to compile the source code and integrate them with the essential kernel objects.
However, someone asks me that why he did some implementation in ecrobot sources and the compiler reports that those new implemented functions are not applicable, i.e., undefined. It is because that all the additional static libraries (those files with extension .a) are required to be compiled in advance before compiling the test suites/samples.
There are some known issues which are solved:
Use command ar can see the content inside. It is usually the correction of .o:
However, someone asks me that why he did some implementation in ecrobot sources and the compiler reports that those new implemented functions are not applicable, i.e., undefined. It is because that all the additional static libraries (those files with extension .a) are required to be compiled in advance before compiling the test suites/samples.
There are some known issues which are solved:
- cannot find -llejososek
This can be solved by compiling the source in folder e.g., "nxtOSEK_proj/c++/src". liblejososek.a will be generated in the parent folder, e.g., "nxtOSEK_proj/c++/" - new implemented functions in ecrobot are undefined
This can be solved by compiling the corresponding code in ecrobot folder. For example, libnxtway_gs_balancer.a need to be generated by compiling to source in the sub folder nxtway_gs_balancer. libnxtway_gs_balancer.a will be generated in ecrobot folder.
.a
files are static libraries typically generated by the archive tool. You usually include the header files associated with that static library and then link to the library when you are compiling. Use command ar can see the content inside. It is usually the correction of .o:
ar tv foo.a
Comments
Post a Comment