MySQL at Linux/PPC

MySQL at Linux/PPC

[Kostas Gewrgiou]

After looking at Bug#: 5732 in RedHat's bugzilla, 
(http://developer.redhat.com/bugzilla/show_bug.cgi?id=5732)
i found out why enabling LFS makes a bad mysql binary, quoting from the
description of the patch bug:

   The configure scripts of patch-2.5 detect the LFS support in 
   glibc-2.1, but due to the lack of a definition of 
   _GNU_SOURCE, no prototypes for fseeko are declared. That way 
   the compiler thinks fseeko is taking a 32bit argument for 
   the offset, when in reality it takes a 64bit offset.

After compiling MySQL with -D_GNU_SOURCE (with LFS enabled) the problems
went away, i am not sure if defining _LARGEFILE_SOURCE is supposed to give
the fseeko declarations but if it is then its a bug in the glibc headers.

  Kostas Gewrgiou.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MySQL at Linux/PPC

[Joel Klecker]

At 09:19 +0300 1999-10-13, Kostas Gewrgiou wrote:
>After looking at Bug#: 5732 in RedHat's bugzilla,
>(http://developer.redhat.com/bugzilla/show_bug.cgi?id=5732)
>i found out why enabling LFS makes a bad mysql binary, quoting from the
>description of the patch bug:
>
>   The configure scripts of patch-2.5 detect the LFS support in
>   glibc-2.1, but due to the lack of a definition of
>   _GNU_SOURCE, no prototypes for fseeko are declared. That way
>   the compiler thinks fseeko is taking a 32bit argument for
>   the offset, when in reality it takes a 64bit offset.
>
>After compiling MySQL with -D_GNU_SOURCE (with LFS enabled) the problems
>went away, i am not sure if defining _LARGEFILE_SOURCE is supposed to give
>the fseeko declarations but if it is then its a bug in the glibc headers.

The glibc documentation says that _LARGEFILE_SOURCE is supposed to 
give the fseeko declaration.

  - Macro: _LARGEFILE_SOURCE
      If this macro is defined some extra functions are available which
      rectify a few shortcomings in all previous standards.  More
      concrete the functions `fseeko' and `ftello' are available.
      Without these functions the difference between the ISO C interface
      (`fseek', `ftell') and the low-level POSIX interface (`lseek')
      would lead to problems.

      This macro was introduced as part of the Large File Support
      extension (LFS).
-- 
Joel Klecker (aka Espy)                    Debian GNU/Linux Developer
<URL:mailto:jk@espy.org>                 <URL:mailto:espy@debian.org>
<URL:http://web.espy.org/>               <URL:http://www.debian.org/>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

MySQL at Linux/PPC

[Michael Widenius]

>>>>> "Kostas" == Kostas Gewrgiou <gewrgiou@imbc.gr> writes:

Kostas> After looking at Bug#: 5732 in RedHat's bugzilla, 
Kostas> (http://developer.redhat.com/bugzilla/show_bug.cgi?id=5732)
Kostas> i found out why enabling LFS makes a bad mysql binary, quoting from the
Kostas> description of the patch bug:

Kostas>    The configure scripts of patch-2.5 detect the LFS support in 
Kostas>    glibc-2.1, but due to the lack of a definition of 
Kostas>    _GNU_SOURCE, no prototypes for fseeko are declared. That way 
Kostas>    the compiler thinks fseeko is taking a 32bit argument for 
Kostas>    the offset, when in reality it takes a 64bit offset.

Kostas> After compiling MySQL with -D_GNU_SOURCE (with LFS enabled) the problems
Kostas> went away, i am not sure if defining _LARGEFILE_SOURCE is supposed to give
Kostas> the fseeko declarations but if it is then its a bug in the glibc headers.

Kostas>   Kostas Gewrgiou.

Hi!

MySQL 3.22.27 and MySQL 3.23.4 and above we now detect the glibc
version and will not use LFS if glibc < 2.1

We have successfully compiled MySQL on RedHat 6.0 without having to
patch anything, so it looks like this is now fixed.

If you still get the problem on your machine with the above MySQL
version, please mail me and we will look at it once more!

Regards,
Monty

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MySQL at Linux/PPC

[Paul DuBois]

On Thu, Oct 14, 1999 at 10:27:35PM +0300, Michael Widenius wrote:
> >>>>> "Kostas" == Kostas Gewrgiou <gewrgiou@imbc.gr> writes:
> 
> Kostas> After looking at Bug#: 5732 in RedHat's bugzilla, 
> Kostas> (http://developer.redhat.com/bugzilla/show_bug.cgi?id=5732)
> Kostas> i found out why enabling LFS makes a bad mysql binary, quoting from the
> Kostas> description of the patch bug:
> 
> Kostas>    The configure scripts of patch-2.5 detect the LFS support in 
> Kostas>    glibc-2.1, but due to the lack of a definition of 
> Kostas>    _GNU_SOURCE, no prototypes for fseeko are declared. That way 
> Kostas>    the compiler thinks fseeko is taking a 32bit argument for 
> Kostas>    the offset, when in reality it takes a 64bit offset.
> 
> Kostas> After compiling MySQL with -D_GNU_SOURCE (with LFS enabled) the problems
> Kostas> went away, i am not sure if defining _LARGEFILE_SOURCE is supposed to give
> Kostas> the fseeko declarations but if it is then its a bug in the glibc headers.
> 
> Kostas>   Kostas Gewrgiou.
> 
> Hi!
> 
> MySQL 3.22.27 and MySQL 3.23.4 and above we now detect the glibc
> version and will not use LFS if glibc < 2.1
> 
> We have successfully compiled MySQL on RedHat 6.0 without having to
> patch anything, so it looks like this is now fixed.
> 
> If you still get the problem on your machine with the above MySQL
> version, please mail me and we will look at it once more!
> 
> Regards,
> Monty

I haven't tried 3.22.7, but 3.23.4 builds and run just
fine with LinuxPPC R5/Q3 on my PowerBook and on a G4/400.
The LFS problem doesn't occur like it did with earlier versions.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/