Warning "LITTLE_ENDIAN" redefined

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After updating to AS 7.0.1417 a project was compiled with no errors, but a warning '"LITTLE_ENDIAN" redefined' appeared. The first definition was in line 217 of file:

C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\SAMD21_DFP\1.2.276\samd21a\include\samd21g18a.h

The redefinition was in line 17 of file:

c:\program files (x86)\atmel\studio\7.0\toolchain\arm\arm-gnu-toolchain\arm-none-eabi\include\machine\endian.h

Looking at this file it looks like the symbol __BSD_VISIBLE is defined somewhere, but where? 

Jerry

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jerry

 

I am having the same issue and started searching.

I let you know in case I find some thing

 

All the Best

Frank

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jerry,

 

found it:

in features.h __BSD_VISIBLE gets defined based on _DEFAULT_SOURCE and that is defined based on eihter _GNU_SOURCE or _BSD_SOURCE or _SVID_SOURCE
This is all kind of confusing to me... I was hoping I can get rid of the little endian warnings, but I am afraid that if I undef __BSD_VISIBLE the thing will fail because they have used the BSD version some were.

All the Best
Frank
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm having the same issue but would like to know more without digging into it too much myself.

 

Does this happen when creating a new project with atmel studio?

 

What else might be affected by the toolchain update?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I created an empty C project and compiled it. The error did not appear. 

The project which does show the error is large and complicated, it would be difficult to localise the cause of the error

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The next thing I would do is a diff on the .cproj files of the new project and the old

 

WinMerge would suffice.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After that compare the generated Makefile

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I started a new ASF example project "WINC3400_SIMPLE_TCP_CLIENT_EXAMPLE1"

 

I'm receiving the

"LITTLE_ENDIAN" Redefined 

Warning on build.

 

Officially giving up on this issue for now since this was an untouched Atmel example.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Resurrecting this thread.  I just tried to do a START update on my project and I'm getting the "LITTLE_ENDIAN" redefined error.  Traces back to endian.h in the toolchain, with __BSD_VISIBLE defined.

 

It looks like the START generated code is using the compiler option -std=gnu99 (under project properties->ARM/GNU C Compiler->Miscellaneous).  Change it to -std=c99 and the problem goes away.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ScottMN: Thanks for the fix

Jerry

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Running AS7 7.0.1931

Switching to -std=c99 causes an error and forces me to remove any GCC extensions I'm using.

I ditched the extension but still am receiving the error.

 

Error seems to be due to the boundary macro in compiler.h being defined as such:

 

 

I'm not going to modify the toolchain or ASF files so for now I'm falling back to using std=gnu99

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I usually go into the offending header file and put

#ifndef  LITTLE_ENDIAN

#define LITTLE_ENDIAN

#endif

 

The issue is that if you include header files in different orders it can be defining LITTLE_ENDIAN again, I do wish the CMSIS headers would have the #ifndef to the definition. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is not always a sufficient answer.  Yes, it will get rid of the warning.  But not necessarily correctly.

I found this thread because I am having the same problem.

In my case, the two files with the conflicting definitions are endian.h and samg55j19.h

The definitions are different. So defining LITTLE_ENDIAN only if it is not defined already gets rid of the warning.  But the underlying problem, that the identifier, "LITTLE_ENDIAN", is being used differently, does not go away.  

In one case, it is defined as 1.  In the other, as 1234.

So code like this:

#if _BYTE_ORDER == _LITTLE_ENDIAN

will not work if the wrong one is picked by the ifdef.

 

The definition in endian.h is used several times inside of endian.h, so it will not be a problem if the #ifdef is in the other file.  I have not figured out where the definition from samg55j19.h is used; I can comment it out and my code compiles, for whatever that is worth.