STM32F107/C - Błąd w pakowaniu struktur (-DPACK_STRUCT_END)

Witam, muszę przekopiować projekt pod STM32F107 (Działający już) na CrossWorksie -> Eclipse, problem leży w makefile'u, ale nie mogę podejrzeć co robi ten crossworksowy, mój wygląda następująco:

Dodałem wpis -DPACK_STRUCT_END, ponieważ wcześniej był problem powtarzających się nazw struktur w pliku:

Jest to fragment pliku nagłówkowego uip.h, biblioteki uIP. Po dodaniu do makefile'a -DPACK_STRUCT_END, mam błąd
"uip.h:1429:3: error: expected identifier or '(' before numeric constant"
Czego kompilator tam oczekuje? Błąd nadal dotyczy nazw struktur PACK_STRUCT_END [/code]

PACK_STRUCT_END powinno być makrem zawierającym taki łańcuch znaków który wymusi na kompilatorze "pakowanie" struktury, a nie pustą definicją jak u Ciebie.

4\/3!!

Ok znalazłem definicję, tylko gdzie umieścić te dyrektywy, jak definiuję tak, w pliku w którym są używane, to błąd nadal się nie zmienia:

Jeśli podstawię wprost __attribute((packed)) to jest OK, widocznie gdzie indziej ma być definicja.

Dodano po 1 [godziny] 7 [minuty]:

Wpisałem definicje w:

Wydaje się być dobrze, kompilator odpuścił i zalał mnie kolejnymi błędami, ale to już kwestia załączeń.

Nie musisz nic definiowac w makefile.



Oznacza to mniej więcej to, że jeżeli symbol PACK_STRUCT_END nie jest zdefiniowany to bedzie on zamieniany wszędzie w kodzie na __attribute((packed)).
Jezeli gdzieś nie jest widoczna ta definicja to powinieneś załączyć odpowiedni nagłówek.

EDIT:
Z tegio co wiem pod gcc nie pisze się __attribute tylko __attribute__

Próbowałem wcześniej robić takie definicje w nagłówkach, ale kompilator zgłaszał błąd, nie wiem dlaczego, po wstawieniu definicji w makefile wszystko poszło gładko i cały projekt się kompiluje, walczę tylko z przerwaniem od ETH_IRQ, ponieważ startupy się różnią i coś nie tak z adresem jest.

Ok, wszystko ślicznie przepisane na eclipse, kompiluje się i działa, tylko rozmiar kodu się średnio zgadza, projekty różnią się tylko, albo aż, podmienioną biblioteką od stm na wersję 3.5.0 z wersji bodajże 2.0.x, oraz driverem od ethernetu, kod wzrósł 2krotnie, na CrossWorksie 32.7KB -> Eclipse 72.8KB !!! Przy optymalizacji "-O1". Te nowe biblioteki są tak kodożerne czy coś jest nie tak z użyciem instrukcji thumb/arm (tutaj nie za bardzo się orientuje)?