MCUXpresso #include Issue

[chadgraham]

Hi,

I have a project that appears to have a #include issue that I'd appreciate some help with.

I have a project that includes several libraries.  Each of these libraries compiles without issue and my application project will compile until I add a function call into one of the libraries.  (Note, I have used functions in other libraries and this library is linked in the same manner.  The include directory is added and accessible, the library and library path is properly referenced in the project settings and the file is properly included in the application file.)

When I compile, the error reports that the undefined reference is actually a #define reference in the function I'm calling to to another library file.  ( library_a.c #includes library_b.c where the #define is located.)  I have confirmed that first library correctly includes the secondary library file and even copying in the #define command into the list library call does not correct the file.  (I also don't get a compiler complaint that the definition is #defined in two locations.)  I can also call other functions in the first library without issues so I'm pretty certain the includes are properly setup.

Unfortunately, the user manuals, the NXP forums, and google searches have failed to be helpful.  Does anyone have any suggestions on what I can try?

[chadgraham]

Hello,

I was able to solve this specific problem by deleting all of the project references, libraries, library search folders, and include folders.  By re-adding the links and references as the compiler progressed through the various errors, I eventually got the entire system to compile.  Comparing the before and after include locations and order, I still don't see a difference, but I was able to confirm the functionality of the application.

Thank you Con Verse and Erich Styger for pointing me in the right direction.converse ErichS

[chadgraham]

Hello,

It's a bit convoluted, but I'll try to explain it as best I can.

The problem statement is a call to a defined macro in the library file ux_host_stack_hcd_thread_entry.c:

UX_DISABLE_INTS

ux_host_stack_hcd_thread_entry.c includes the library header #include "ux_api.h" which includes a basic library file #include "ux_port.h".

In ux_port.h, the macro is defined:

#define UX_DISABLE_INTS         old_interrupt_posture =  tx_interrupt_control(TX_INT_DISABLE);

The actual error is:
undefined reference to `tx_thread_interrupt_control'

ux_port.h  includes the library header #include "ux_api.h" which also includes another library file #include "tx_api.h" 

In tx_api.h, tx_thread_interrupt_control is converted to _tx_thread_interrupt_control and declared as:

UINT        _tx_thread_interrupt_control(UINT new_posture);

Based on how I interpret the library file, the #define is a macro to a know function in in an included file, but it is unable locate it.  I have used the tx_interrupt_control() function in other applications and only referenced the tx_api.h so I am certain that the TX library is functioning.

[converse]

A few comments:

- You say the macro is defined as 

old_interrupt_posture =  tx_interrupt_control(TX_INT_DISABLE);

and that 

tx_thread_interrupt_control is converted to _tx_thread_interrupt_control

but you say the error is

undefined reference to `tx_thread_interrupt_control'

So there is something inconsistent in your description.

- An undefined reference error is from the linker. So, you are not adding the library that resolves the reference to tx_thread_interrupt_control

Don't get confused between #include (which is a compiler operation) with undefined references which is a linker error

- The evaluation of commands on a link compile command is very important.

When the compiler sees .o files, they get added to the target binary automatically, so all .o files are present. That leaves a list of undefined entities which need to be found.

The next stage is to look through the libraries. Each library is searched, and the .o elements of each library which fulfills an undefined reference is added to the target binary. That always resolves some issues. However, it may also have further requirements. So adding part of a library may add to the required elements to be satisfied.

When a library requires another library, it needs to be specified after something which required it, and before the libraries which satisfy its requirements.

There is a chance if the .o files also require the same parts of a library, this issue can crop up when code is deleted from a .o (removing the mechanism which pulls in the library part).

- If this doesn't help, we are going to need to reproduce the problem here to be able to resolve it.

[ErichStyger]

Could you post/upload a minimal example?

[converse]

As a minimum, post the #define that you think is causing the problem and the error message that is being generated