--===============0825263746==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	micalg=pgp-sha1; boundary="Boundary-02=_OueuAM8L+RDYQll"
Content-Transfer-Encoding: 7bit

--Boundary-02=_OueuAM8L+RDYQll
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Martin Koller wrote:
>On Sunday 30 May 2004 00:49, Thiago Macieira wrote:
>> Martin Koller wrote:
>> >In file included from /usr/include/linux/cdrom.h:14,
>> >                 from cdromAccess_Linux.cpp:17,
>> >                 from cdromAccess.cpp:33:
>> >/usr/include/asm/byteorder.h:38: syntax error before `(' token
>> >/usr/include/asm/byteorder.h:42: '__u64' is used as a type, but is
>> > not defined as a type.
>> >/usr/include/asm/byteorder.h:43: syntax error before `}' token
>>
>> Kernel headers problem, not a KDE problem. Drop the -ansi switch
>> when compiling those directories and it'll work.
>
>It's not a problem for me to work around this error, but doesn't this
> mean that _everybody_ with a kernel with those headers will have that
> problem ? (I'm pretty sure that this is a huge number of people)
>Isn't there a simple solution or a check during configure, etc. ?

I'm not advocating not making workarounds, but I am against workarounds=20
if a proper fix is possible.

Bugs must be fixed where the bug is. "Fixing" it somewhere else isn't=20
fixing. The problem in this case is that the kernel headers'=20
declaration of __u64 is conditional to STRICT_ANSI. The logical=20
conclusion that follows is that every function or structure that uses=20
__u64 must be conditional to STRICT_ANSI as well. And this is not the=20
case.

We can't fix every little bug there is in other people's code by adding=20
workarounds to our code. The kernel headers are especially the case=20
because those are outright bugs that they don't want to fix (yet).

One last thing: distributors are responsible for cleaning up the kernel=20
headers to make them compile against the libc they use. Users are not=20
supposed to replace those kernel headers unless they want to take the=20
responsibility for the cleaning up as well.

Yes, I know that's not the best case scenario, but it is the scenario we=20
have.
=2D-=20
  Thiago Macieira  -  Registered Linux user #65028
   thiago (AT) macieira (DOT) info
    ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--Boundary-02=_OueuAM8L+RDYQll
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBAueuOM/XwBW70U1gRAuulAJ4jrd7MKCQyvZXSSXEqtaV3cksJiACgt/NJ
m1lVB+wiesYFS/31RJydido=
=2xZS
-----END PGP SIGNATURE-----

--Boundary-02=_OueuAM8L+RDYQll--

--===============0825263746==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

--===============0825263746==--