The declared structure has the same name as the structure in the compilation tool chain, how to solv-CodePudding

I have implemented a set of functions satisfying the posix interface and want to run it on my STM32 development board. However, during the compilation process, it was found that the declared structure was duplicated with the structure name in the cross-compilation toolchain. For example, they are all called pthread_attr_t, and pthread_attr_t in the cross-compilation toolchain is automatically used during compilation, which leads to program errors. How should I solve this problem so that my program correctly references the pthread_attr_t I declared myself.

I can't change the name of my structure, and I also tried changing #include <face_pthread.h> to #include "face_pthread.h", but it doesn't solve this problem, so I hope someone can help me.

I add a case to show my current situation.

test.h

#ifndef __TEST__
#define __TEST__

typedef unsigned char INT8U;
typedef INT8U clockid_t;

void test();

#endif

test.c

#include "test.h"

void test() {
    clockid_t time;
    return;
}

I compile the code with arm-none-eabi-gcc

The following is the error message

.../Test/test.h:5:15: error: conflicting types for 'clockid_t'
    5 | typedef INT8U clockid_t;
      | 
arm-none-eabi\include\sys\types.h:199:21: note: previous declaration of 'clockid_t' was here
  199 | typedef __clockid_t clockid_t;
      |

Wait a minute, when I added the error case, I found that the operating system I used introduced the header file #include <stdio.h> of the compilation toolchain in a certain configuration file, and introduced related files #include <sys/types.h> in stdio.h, it seems that this error is caused, maybe I need to change the question: is there any way to avoid this conflict?

CodePudding user response：

NB: several possible duplicate questions relate to re-implementing standard library functions. This question is about re-implementing standard library types, and I think it is a legitimate fact-based question and I couldn't find a duplicate.

You are trying to re-implement part of the standard library which is included as part of your compiler package.

You can do this, but it is a lot more work than you perhaps think it is.

You can start by adding the command line argument -nostdinc to gcc. This will stop it being able to find the headers that contain the duplicates. It will also stop it from finding a great many other things that perhaps you wanted. You will have to re-implement all of them too.

If you want to avoid duplicate symbols when linking as well as duplicate type definitions when compiling then you will probably need -nostdlib. You may also need -ffreestanding. See the gcc manual and the questions linked in the comments for details.

CodePudding user response：

I also thought of a solution to solve the problem I encountered: By looking at the header files of the cross-compilation toolchain, it can be found that almost every macro definition declared in the cross-compilation toolchain is wrapped with #ifndef. I just need to implement a header file, declare these macros in the tool chain, and maybe my problem can be solved. I will try it later, if there is a better solution, I hope you can give your valuable suggestions.