Nagłówki jądra (Re: [ac] kolejny problem z okolic /usr/include/asm/byteorder.h ( kdemultimedia.spec))

[Jakub Bogusz]

On Sat, Nov 15, 2003 at 01:21:40PM +0100, Paweł Sikora wrote:
> On Saturday 15 of November 2003 13:04, Mateusz Korniak wrote:
> > Pakiet buduje się cześciowo w Ac natomiast w Nest, oraz na nagłówkach
> > 2.40.20-3 (u adgora) całkowicie dobrze.
> >
> > Powodem jest padający test:
> > > configure:35504: athlon-pld-linux-gcc -c -ansi -W -Wall -Wchar-subscripts
> > > -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings
> > > -D_XOPEN_SOURCE=500 -D_BSD_SO\
> > > URCE -O2  -O2 -march=athlon -Wformat-security -Wmissing-format-attribute
> > > -DQT_THREAD_SUPPORT  -D_REENTRANT conftest.c >&5
> > > In file included from /usr/include/linux/cdrom.h:14,
> > >                  from conftest.c:76:
> > > /usr/include/asm/byteorder.h:38: error: parse error before "__u64"
> >
> > Przez to jest:
> > > checking for CDDA... no
> >
> > No i brak cześci plików :/
> 
> sprawdz czy to pomoze, bo ja kdemultimedia
> bede dopiero chyba pojutrze kompilowal.

Może to "-ansi" w opcjach przeszkadza?
Na HEAD pomogło kiedyś:

--- kdemultimedia-3.1.3/admin/acinclude.m4.in.cdrom     Fri Sep  5 12:35:45 2003
+++ kdemultimedia-3.1.3/admin/acinclude.m4.in   Fri Sep  5 13:12:22 2003
@@ -2840,7 +2840,9 @@
             CXXFLAGS="-ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion $CXXFLAGS"
           ;;
         esac
-        CXXFLAGS="-Wall -pedantic -W -Wpointer-arith -Wwrite-strings $CXXFLAGS"
+        CXXFLAGS="-Wall -W -Wpointer-arith -Wwrite-strings $CXXFLAGS"
+        dnl -pedantic + g++ 3.3 + <linux/cdrom.h> = causes
+        dnl "error: ISO C++ forbids braced-groups within expressions" in <linux/byteorder/swab.h>
         KDE_CHECK_COMPILER_FLAG(Wundef,[CXXFLAGS="-Wundef $CXXFLAGS"])
         KDE_CHECK_COMPILER_FLAG(Wno-long-long,[CXXFLAGS="-Wno-long-long $CXXFLAGS"])
         KDE_CHECK_COMPILER_FLAG(Wnon-virtual-dtor,[CXXFLAGS="-Wnon-virtual-dtor $CXXFLAGS"])

Ale to na podobny numer, a nie to. Tu może pomóc #include <asm/types.h>
przed <linux/cdrom.h> i #define _I386_BYTEORDER_H (plus to samo dla innych
architektur), żeby nie próbował włączać byteorder.



Tak naprawdę błąd tkwi w tym, że %{_includedir}/linux/cdrom.h,
w przeciwieństwie do %{_kernelsrcdir}/include/linux/cdrom.h nie ma prawa
włącząć <asm/byteorder.h> (który jest prywatnym nagłówkiem jądra), tylko
<asm/types.h> i <endian.h>.

Podobnie - jak się okazało - %{_kernelsrcdir}/include/linux/i2c{,-dev}.h
(z i2c 2.8.x) to prywatne nagłówki jądra i nie mogą być używane w userspace.
Dla userspace służy %{_includedir}/linux/i2c-dev.h z niewiadomych
powodów umieszczony w źródłach lm_sensors 2.8.x (powinien być dołączony
do glibc-kernel-headers - ale ten, nie z i2c, jak jest teraz na
builderach!).

Dlatego IMO trzeba już porzucić możliwość podlinkowywania czegokolwiek
pod %{_includedir}/{asm,linux}. Tam mają być nagłówki dla userspace
i nic innego. Nagłówki współczesnych jąder się zupełnie do tego nie
nadają. Pojawiają się zupełnie różne pliki (o tych samych nazwach) dla
interfejsów wewnętrznych (wywołania funkcji z jądra/modułów) i userspace
(ioctl-e lub syscalle). Przy pomyleniu tych plików skompilowany kod
_nie ma prawa działać_. Doskonałym przykładem jest nowe i2c.

Teraz pytanie - czy:
- bierzemy jako bazę paczkę nagłówków z RH i próbujemy łatać nakładając
  kolejne patche (takowe będą - te nagłówki nie są doskonałe; poza tym
  w ostatnich wersjach nie ma sparca)

- czy wrzucamy bazowe nagłówki[1] do modułu w CVS[2] i w ten sposób
  poprawiamy, pakując co jakiś czas nową wersję

[1] z RH, 2.4.22 czy 2.6.0-test9? nie uciekniemy od porównywania ich :/
[2] świadomie napisałem _te_ 3 litery ;)


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/