DBD-mysql-2.9003 Installation Issues

DBD-mysql-2.9003 Installation Issues

am 02.07.2004 00:28:12 von Lauri Bettencourt

--=====================_34464266==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hello:

I have been trying to get DBD-mysql-2.9003 installed without success. Any
suggestions are welcomed. The specifics of my install are as follows:

Solaris 9 --- using gcc-3.2.1

perl-5.8.0 --- with threading support
./Configure --- accepted all defaults except for gcc as compiler &
thread support

mysql-3.23.58
CC=gcc ./configure --prefix=/usr/local/mysql --without-server
make
make install

**** have tried both source and binary versions of mysql with the same
results ****

mysql-standard-4.0.20-sun-solaris2.9-sparc
simply unpacked binary in /usr/local and linked to /usr/local/mysql

DBI-1.42
perl Makefile.PL
make
make install
removed working directory

DBD-mysql-2.9003
perl Makefile.PL
make
make install

**** Everything installs successfully, no errors. ****

Output of crle:

Configuration file [3]: /var/ld/ld.config
Default Library Path
(ELF): /usr/lib:/usr/local/lib:/usr/local/mysql/lib:/usr/local/ssl/ lib
Trusted Directories (ELF): /usr/lib/secure (system default)

Command line:
crle -c /var/ld/ld.config -l
/usr/lib:/usr/local/lib:/usr/local/mysql/lib:/usr/local/ssl/ lib

When I try to run a script I get the following error:

# perl mysql_test.pl
install_driver(mysql) failed: Can't load
'/usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris-thread-mu lti/auto/DBD/mysql/mysql.so'
for module DBD::mysql: ld.so.1: perl: fatal: relocation error: file
/usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris-thread-mul ti/auto/DBD/mysql/mysql.so:
symbol net_buffer_length: referenced symbol not found at
/usr/local/lib/perl5/5.8.0/sun4-solaris-thread-multi/DynaLoa der.pm line 229.
at (eval 1) line 3
Compilation failed in require at (eval 1) line 3.
Perhaps a required shared library or dll isn't installed where expected
at mysql_test.pl line 12

# more mysql_test.pl
#!/usr/bin/perl -w

use DBI;
use threads;

$username = 'user';
$auth = 'password';
$db_name = 'database=bvstats;host=server.domain.net';
$i=0;

## OPEN DB CONNECTION
$dbh = DBI->connect("DBI:mysql:$db_name", $username, $auth)
or &db_error_connect(DBI->errstr);


$query = qq(SELECT id, ip FROM users WHERE ip != '' LIMIT 5);
$sth = $dbh->prepare($query) || &db_error_prep($sth->errstr);
$sth->execute || &db_error_exec($sth->errstr);
my @data;
while (@data = $sth->fetchrow_array())
{
if($sth->err)
{
print "There was a fetchrow error: $sth->errstr";
}

$userinfo[$i] = $data[0];
$user_ip[$i] = $data[1];
$i++;

print qq($i: $userinfo[$i] | $user_ip[$i] \n);
}

$sth->finish;



Thanks,

Lauri-

~~~~~~~~~~~~~~~~~~~~~~~
Lauri Bettencourt
UNIX System Administrator
lbetten@wn.net
~~~~~~~~~~~~~~~~~~~~~~~
--=====================_34464266==.ALT--

Re: DBD-mysql-2.9003 Installation Issues

am 02.07.2004 00:34:43 von Glenn Fleishman

Lauri Bettencourt on 7/1/04 at 6:28 PM wrote:

>I have been trying to get DBD-mysql-2.9003 installed without success. Any=
=20
>suggestions are welcomed. The specifics of my install are as follows:

I had an unrelated problem with that same release that I was trying to figu=
re out whether it was just me but found a few notes that didn't solve it in=
the archives for this list.=20

I installed MySQL 4.1.2 alpha on a Red Hat Linux 9 box running perl 5.8.0. =
This caused the DBD::mysql module to fail. I tried to cleanly reinstall it,=
but received the error message:

mysql.xs: In function `XS_DBD__mysql__GetInfo_dbd_mysql_get_info':
mysql.xs:356: `net_buffer_length' undeclared (first use in this function)
mysql.xs:356: (Each undeclared identifier is reported only once
mysql.xs:356: for each function it appears in.)
make: *** [mysql.o] Error 1

I discovered that commenting out line 356 resulting in a successful compile=
and a working driver, but it then seemed to disable the DBD::mysql module =
from handling get_host_by_name or some such: I can no longer reference host=
s by their host or DNS name, only by IP number.

I'd file this as a bug, but I'm trying to make sure it's not a peculiarity =
of my configuration. Other folks seeing this?

gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
Linux 2.4.20-28.9smp #1 SMP
perl 5.8.0 built for i386-linux-thread-multi
MySQL 4.1.2 for x86 (prebuilt binaries)
DBD-mysql 2.9003
--
Glenn Fleishman
seattle . washington
unsolicited pundit . glennf.com
columnist . seattletimes.com/practicalmac
daily wireless networking news . wifinetnews.com

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=3Dgcdmp-msql-mysql-modules @m.gmane.org

Re: DBD-mysql-2.9003 Installation Issues

am 02.07.2004 00:34:43 von Glenn Fleishman

Lauri Bettencourt on 7/1/04 at 6:28 PM wrote:

>I have been trying to get DBD-mysql-2.9003 installed without success. Any=
=20
>suggestions are welcomed. The specifics of my install are as follows:

I had an unrelated problem with that same release that I was trying to figu=
re out whether it was just me but found a few notes that didn't solve it in=
the archives for this list.=20

I installed MySQL 4.1.2 alpha on a Red Hat Linux 9 box running perl 5.8.0. =
This caused the DBD::mysql module to fail. I tried to cleanly reinstall it,=
but received the error message:

mysql.xs: In function `XS_DBD__mysql__GetInfo_dbd_mysql_get_info':
mysql.xs:356: `net_buffer_length' undeclared (first use in this function)
mysql.xs:356: (Each undeclared identifier is reported only once
mysql.xs:356: for each function it appears in.)
make: *** [mysql.o] Error 1

I discovered that commenting out line 356 resulting in a successful compile=
and a working driver, but it then seemed to disable the DBD::mysql module =
from handling get_host_by_name or some such: I can no longer reference host=
s by their host or DNS name, only by IP number.

I'd file this as a bug, but I'm trying to make sure it's not a peculiarity =
of my configuration. Other folks seeing this?

gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
Linux 2.4.20-28.9smp #1 SMP
perl 5.8.0 built for i386-linux-thread-multi
MySQL 4.1.2 for x86 (prebuilt binaries)
DBD-mysql 2.9003
--
Glenn Fleishman
seattle . washington
unsolicited pundit . glennf.com
columnist . seattletimes.com/practicalmac
daily wireless networking news . wifinetnews.com

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=3Dgcdmp-msql-mysql-modules @m.gmane.org

Re: DBD-mysql-2.9003 Installation Issues

am 02.07.2004 01:10:19 von Robert Sinton

Glenn,

I worked around the same problem you had (under OS X in my case) by =
forcing net_buffer_length to get defined in mysql.h, when some #ifdefs =
seemed to be preventing it for no obvious reason. However I think that =
particular problem may have been peculiar to MySQL 4.1.2, so Lauri's =
problem may not be related.

In case it's helpful, I have pasted in a detailed description of my rather =
rash workaround below. I suspect that it will probably cause the early =
heat-death of the Universe, so use with caution.

Cheers,
Robert

--=20
Robert Sinton Phone +64 (3) 366-5454
Senior Systems Consultant Fax +64 (3) 366-4456
MagnumMac Resources Ltd 21-23 Carlyle Street, PO Box 1144, Christchu=
rch

In science it often happens that scientists say, "You know that's a really
good argument; my position is mistaken," and then they would actually
change their minds and you never hear that old view from them again. They
really do it. It doesn't happen as often as it should, because scientists
are human and change is sometimes painful. But it happens every day. I
cannot recall the last time something like that happened in politics or
religion. -- Carl Sagan, astronomer and writer (1934-1996)


>-----Original Message-----
>From: Robert Sinton [mailto:robert@magnummac.co.nz]=20
>Sent: jeudi 17 juin 2004 06:19
>To: Fabien
>Subject: Re: MySQL and Perl updates...
>
>
>Bonjour, Fabien.
>
>The build problem occurred because 'net_buffer_length' never got
>declared when I tried to build DBD::mysql with the libraries and headers
>from the newer version (4.1.2) of MySQL. In the previous version of
>MySQL that I had been using, it had been declared explicitly (in
>mysql/include/mysql_com.h). However in the newer version it only appears
>as follows, in the mysql/include/mysql.h header file:
>
> #if !defined(MYSQL_CLIENT) && !defined(MYSQL_SERVER) &&
>!defined(EMBEDDED_LIBRARY)
> #define max_allowed_packet
>(*mysql_get_parameters()->p_max_allowed_packet)
> #define net_buffer_length
>(*mysql_get_parameters()->p_net_buffer_length)
> #endif
>
>This seems to imply that max_allowed_packet and net_buffer_length only
>ever get declared if you are using the header file to help build
>something that isn't MySQL client, MySQL server, or an embedded
>library.
>
>However, a little earlier in the mysql.h file I found this:
>
> #if !defined(MYSQL_SERVER) && !defined(MYSQL_CLIENT)
> #define MYSQL_CLIENT
> #endif
>
>... which would seem to have the effect of ensuring that either
>MYSQL_SERVER or MYSQL_CLIENT would always be defined by the time we
>reach the block concerning max_allowed_packet and net_buffer_length.
>This looks like an error to me, but I really don't have enough
>experience to be sure.
>
>Anyway, rather than figure out the proper way to deal with this, I just
>edited mysql.h, and duplicated the #define line after the conditional,
>so that it always gets executed:
>
> #if !defined(MYSQL_CLIENT) && !defined(MYSQL_SERVER) &&
>!defined(EMBEDDED_LIBRARY)
> #define max_allowed_packet
>(*mysql_get_parameters()->p_max_allowed_packet)
> #define net_buffer_length
>(*mysql_get_parameters()->p_net_buffer_length)
> #endif
> #define net_buffer_length
>(*mysql_get_parameters()->p_net_buffer_length)
>=20
>That allowed me to bypass the problem with building DBD::mysql, although
>it didn't resolve my original problem (for which I haven't yet found an
>answer).
>
>Hope this helps!
>
>Amiti=E9s,
>Robert
>
>



On Friday, 2 July 2004 10:34 AM, Glenn Fleishman wrote:
>Lauri Bettencourt on 7/1/04 at 6:28 PM
>wrote:
>
>>I have been trying to get DBD-mysql-2.9003 installed without success. =
Any=20
>>suggestions are welcomed. The specifics of my install are as
>follows:
>
>I had an unrelated problem with that same release that I was
>trying to figure out whether it was just me but found a few
>notes that didn't solve it in the archives for this list.=20
>
>I installed MySQL 4.1.2 alpha on a Red Hat Linux 9 box running
>perl 5.8.0. This caused the DBD::mysql module to fail. I tried
>to cleanly reinstall it, but received the error message:
>
>mysql.xs: In function `XS_DBD__mysql__GetInfo_dbd_mysql_get_info':
>mysql.xs:356: `net_buffer_length' undeclared (first use in this function)
>mysql.xs:356: (Each undeclared identifier is reported only once
>mysql.xs:356: for each function it appears in.)
>make: *** [mysql.o] Error 1
>
>I discovered that commenting out line 356 resulting in a
>successful compile and a working driver, but it then seemed to
>disable the DBD::mysql module from handling get_host_by_name or
>some such: I can no longer reference hosts by their host or DNS
>name, only by IP number.
>
>I'd file this as a bug, but I'm trying to make sure it's not a
>peculiarity of my configuration. Other folks seeing this?
>
>gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
>Linux 2.4.20-28.9smp #1 SMP
>perl 5.8.0 built for i386-linux-thread-multi
>MySQL 4.1.2 for x86 (prebuilt binaries)
>DBD-mysql 2.9003
>--
>Glenn Fleishman
>seattle . washington
>unsolicited pundit . glennf.com
>columnist . seattletimes.com/practicalmac
>daily wireless networking news . wifinetnews.com
>


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=3Dgcdmp-msql-mysql-modules @m.gmane.org

Re: DBD-mysql-2.9003 Installation Issues

am 02.07.2004 01:10:19 von Robert Sinton

Glenn,

I worked around the same problem you had (under OS X in my case) by =
forcing net_buffer_length to get defined in mysql.h, when some #ifdefs =
seemed to be preventing it for no obvious reason. However I think that =
particular problem may have been peculiar to MySQL 4.1.2, so Lauri's =
problem may not be related.

In case it's helpful, I have pasted in a detailed description of my rather =
rash workaround below. I suspect that it will probably cause the early =
heat-death of the Universe, so use with caution.

Cheers,
Robert

--=20
Robert Sinton Phone +64 (3) 366-5454
Senior Systems Consultant Fax +64 (3) 366-4456
MagnumMac Resources Ltd 21-23 Carlyle Street, PO Box 1144, Christchu=
rch

In science it often happens that scientists say, "You know that's a really
good argument; my position is mistaken," and then they would actually
change their minds and you never hear that old view from them again. They
really do it. It doesn't happen as often as it should, because scientists
are human and change is sometimes painful. But it happens every day. I
cannot recall the last time something like that happened in politics or
religion. -- Carl Sagan, astronomer and writer (1934-1996)


>-----Original Message-----
>From: Robert Sinton [mailto:robert@magnummac.co.nz]=20
>Sent: jeudi 17 juin 2004 06:19
>To: Fabien
>Subject: Re: MySQL and Perl updates...
>
>
>Bonjour, Fabien.
>
>The build problem occurred because 'net_buffer_length' never got
>declared when I tried to build DBD::mysql with the libraries and headers
>from the newer version (4.1.2) of MySQL. In the previous version of
>MySQL that I had been using, it had been declared explicitly (in
>mysql/include/mysql_com.h). However in the newer version it only appears
>as follows, in the mysql/include/mysql.h header file:
>
> #if !defined(MYSQL_CLIENT) && !defined(MYSQL_SERVER) &&
>!defined(EMBEDDED_LIBRARY)
> #define max_allowed_packet
>(*mysql_get_parameters()->p_max_allowed_packet)
> #define net_buffer_length
>(*mysql_get_parameters()->p_net_buffer_length)
> #endif
>
>This seems to imply that max_allowed_packet and net_buffer_length only
>ever get declared if you are using the header file to help build
>something that isn't MySQL client, MySQL server, or an embedded
>library.
>
>However, a little earlier in the mysql.h file I found this:
>
> #if !defined(MYSQL_SERVER) && !defined(MYSQL_CLIENT)
> #define MYSQL_CLIENT
> #endif
>
>... which would seem to have the effect of ensuring that either
>MYSQL_SERVER or MYSQL_CLIENT would always be defined by the time we
>reach the block concerning max_allowed_packet and net_buffer_length.
>This looks like an error to me, but I really don't have enough
>experience to be sure.
>
>Anyway, rather than figure out the proper way to deal with this, I just
>edited mysql.h, and duplicated the #define line after the conditional,
>so that it always gets executed:
>
> #if !defined(MYSQL_CLIENT) && !defined(MYSQL_SERVER) &&
>!defined(EMBEDDED_LIBRARY)
> #define max_allowed_packet
>(*mysql_get_parameters()->p_max_allowed_packet)
> #define net_buffer_length
>(*mysql_get_parameters()->p_net_buffer_length)
> #endif
> #define net_buffer_length
>(*mysql_get_parameters()->p_net_buffer_length)
>=20
>That allowed me to bypass the problem with building DBD::mysql, although
>it didn't resolve my original problem (for which I haven't yet found an
>answer).
>
>Hope this helps!
>
>Amiti=E9s,
>Robert
>
>



On Friday, 2 July 2004 10:34 AM, Glenn Fleishman wrote:
>Lauri Bettencourt on 7/1/04 at 6:28 PM
>wrote:
>
>>I have been trying to get DBD-mysql-2.9003 installed without success. =
Any=20
>>suggestions are welcomed. The specifics of my install are as
>follows:
>
>I had an unrelated problem with that same release that I was
>trying to figure out whether it was just me but found a few
>notes that didn't solve it in the archives for this list.=20
>
>I installed MySQL 4.1.2 alpha on a Red Hat Linux 9 box running
>perl 5.8.0. This caused the DBD::mysql module to fail. I tried
>to cleanly reinstall it, but received the error message:
>
>mysql.xs: In function `XS_DBD__mysql__GetInfo_dbd_mysql_get_info':
>mysql.xs:356: `net_buffer_length' undeclared (first use in this function)
>mysql.xs:356: (Each undeclared identifier is reported only once
>mysql.xs:356: for each function it appears in.)
>make: *** [mysql.o] Error 1
>
>I discovered that commenting out line 356 resulting in a
>successful compile and a working driver, but it then seemed to
>disable the DBD::mysql module from handling get_host_by_name or
>some such: I can no longer reference hosts by their host or DNS
>name, only by IP number.
>
>I'd file this as a bug, but I'm trying to make sure it's not a
>peculiarity of my configuration. Other folks seeing this?
>
>gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
>Linux 2.4.20-28.9smp #1 SMP
>perl 5.8.0 built for i386-linux-thread-multi
>MySQL 4.1.2 for x86 (prebuilt binaries)
>DBD-mysql 2.9003
>--
>Glenn Fleishman
>seattle . washington
>unsolicited pundit . glennf.com
>columnist . seattletimes.com/practicalmac
>daily wireless networking news . wifinetnews.com
>


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=3Dgcdmp-msql-mysql-modules @m.gmane.org

Re: DBD-mysql-2.9003 Installation Issues

am 02.07.2004 01:42:37 von Glenn Fleishman

>I worked around the same problem you had (under OS X in my case) by
forcing net_buffer_length to get=20
>defined in mysql.h, when some #ifdefs seemed to be preventing it for no
obvious reason. However I=20
>think that particular problem may have been peculiar to MySQL 4.1.2, so
Lauri's problem may not be=20
>related.
>
>In case it's helpful, I have pasted in a detailed description of my
rather rash workaround below. I=20
>suspect that it will probably cause the early heat-death of the
Universe, so use with caution.

I'm new to this list, so I'm not entirely sure whether the developers
are on it, or whether we should be documenting all of this in some
parallel fashion in MySQL bug databases or elsewhere.

I'd prefer to defer the universe's demise, but will take your patch
under advisement.
--
Glenn Fleishman
seattle, washington
work and home: glennf.com
wireless data news: wifinetnews.com

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=3Dgcdmp-msql-mysql-modules @m.gmane.org

Re: DBD-mysql-2.9003 Installation Issues

am 02.07.2004 01:42:37 von Glenn Fleishman

>I worked around the same problem you had (under OS X in my case) by
forcing net_buffer_length to get=20
>defined in mysql.h, when some #ifdefs seemed to be preventing it for no
obvious reason. However I=20
>think that particular problem may have been peculiar to MySQL 4.1.2, so
Lauri's problem may not be=20
>related.
>
>In case it's helpful, I have pasted in a detailed description of my
rather rash workaround below. I=20
>suspect that it will probably cause the early heat-death of the
Universe, so use with caution.

I'm new to this list, so I'm not entirely sure whether the developers
are on it, or whether we should be documenting all of this in some
parallel fashion in MySQL bug databases or elsewhere.

I'd prefer to defer the universe's demise, but will take your patch
under advisement.
--
Glenn Fleishman
seattle, washington
work and home: glennf.com
wireless data news: wifinetnews.com

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=3Dgcdmp-msql-mysql-modules @m.gmane.org

Re: DBD-mysql-2.9003 Installation Issues

am 02.07.2004 09:08:18 von Jochen Wiedmann

Glenn Fleishman wrote:

> I'm new to this list, so I'm not entirely sure whether the developers
> are on it, or whether we should be documenting all of this in some
> parallel fashion in MySQL bug databases or elsewhere.

They are. However, the explanations what went wrong, why it didn't work and
what can be changed are way too unclear to take this as a proper patch, at
least for me.

To me this smells much more like mismatching versions, for example using
MySQL binaries and header files from another source, or something similar.
As long as noone is able to give an explanation like "In MySQL 4.1.3 was an
incompatible change in the header files. 4.1.2 looked like this: .... 4.1.3
looks like this: ... As a result we need to change ...", I won't change my mind.


Jochen

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: DBD-mysql-2.9003 Installation Issues

am 02.07.2004 09:08:18 von Jochen Wiedmann

Glenn Fleishman wrote:

> I'm new to this list, so I'm not entirely sure whether the developers
> are on it, or whether we should be documenting all of this in some
> parallel fashion in MySQL bug databases or elsewhere.

They are. However, the explanations what went wrong, why it didn't work and
what can be changed are way too unclear to take this as a proper patch, at
least for me.

To me this smells much more like mismatching versions, for example using
MySQL binaries and header files from another source, or something similar.
As long as noone is able to give an explanation like "In MySQL 4.1.3 was an
incompatible change in the header files. 4.1.2 looked like this: .... 4.1.3
looks like this: ... As a result we need to change ...", I won't change my mind.


Jochen

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: DBD-mysql-2.9003 Installation Issues

am 03.07.2004 14:25:45 von Robert Sinton

OK, well, I didn't attempt a definitive analysis because, basically,
I thought that I would be in way over my head :-) But I like a challenge,
so I've had a go:

In MySQL 4.1.1, net_bufffer_length is explicitly defined in mysql_com.h,
at line 318:

extern unsigned long net_buffer_length;

In MySQL 4.1.2 (and now 4.1.3), net_buffer_length is only
conditionally defined,
in mysql.h, at line 326:

#if !defined(MYSQL_CLIENT) && !defined(MYSQL_SERVER) &&
!defined(EMBEDDED_LIBRARY)
#define max_allowed_packet (*mysql_get_parameters()->p_max_allowed_packet)
#define net_buffer_length (*mysql_get_parameters()->p_net_buffer_length)
#endif

But a little earlier, at line 300, we have:

#if !defined(MYSQL_SERVER) && !defined(MYSQL_CLIENT)
#define MYSQL_CLIENT
#endif

My tentative reading of this is that by the time we get to
line 326 of mysql.h, at least one of MYSQL_SERVER and MYSQL_CLIENT
will have been defined, which will fail to satisfy the test at line 326,
therefore preventing net_buffer_length from ever getting defined.

At line 493 (and mentioned at a couple of other places) in docs/ChangeLog
for MySQL 4.1.2 we have:

ChangeSet
1.1346.1.512 04/05/27 02:47:04 monty@mysql.com +4 -0
netware files should always be in 'make dist'
use opt_net_buffer_length instead of net_buffer_length

The other references seem to indicate that opt_net_buffer_length is local to
client/mysqldump.c and client/mysql.cc. However the following, at line 606
of the ChangeLog, seems relevant:

include/mysql.h
1.42.1.11 04/05/26 21:40:12 hf@deer.(none) +13 -0
mysql_get_parameters() interface added

So my best guess is that net_buffer_length has been either intentionally
or unintentionally eliminated in MySQL 4.1.2, in favour of a new
parameter-fetching interface which includes the ability to discover the
value previously known as net_buffer_length.

Perhaps (and now I'm really going out on a limb) the operation at line 300
in mysql.h is inappropriate? It looks rather odd to me: the second
clause in the #if test seems redundant, and the whole thing seems to enforce an
assumption that if you are not building the server, you must be
building the client.
It almost looks to me as if the purpose of the operation at line 326 is to say
"Well, we've re-coded for the new parameter-fetching mechanism in our client,
server, and embedded library source code, but we need to allow for
alternative uses of the header file, which may still be using the old way
of finding out net_buffer_length.", and then someone's accidentally left in
a temporary hack at line 300 which subverts all that.

As to how you would adjust DBD::mysql to handle the new parameter-fetching
interface, a reliable solution for that is definitely out of my league,
but I'm guessing that it would look something like replacing the use of
net_buffer_length with (*mysql_get_parameters()->p_net_buffer_length),
as seen at line 328 of mysql.h. Of course, you would have to make that
conditional on whether you are building it with MySQL 4.1.2 or later.

I modified line 355 of mysql.xs as follows, which allowed the build
to complete,
and passed a simple operational test:

retsv = newSViv((*mysql_get_parameters()->p_net_buffer_length));


As I said, I don't really have the experience to comment definitively
on this issue, and I apologise if some of my terminology is mangled,
but hopefully the above is of some help. I am keen to learn, so if
you feel like
pointing out any blunders I'd be most grateful.

Cheers,
Robert

PS Checking the above against the new 4.1.3 beta, I found that
mysql_shutdown()
has acquired an extra argument in that version, which introduces a further
compilation hitch for DBD::mysql:

cc -c -I/Library/Perl/5.8.1/darwin-thread-multi-2level/auto/DBI
-I/usr/local/mysql/include -fno-omit-frame-pointer -g -pipe -pipe
-fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing
-I/usr/local/include -Os -DVERSION=\"2.9003\"
-DXS_VERSION=\"2.9003\"
"-I/System/Library/Perl/5.8.1/darwin-thread-multi-2level/COR E"
mysql.c
mysql.xs: In function `XS_DBD__mysql__dr__admin_internal':
mysql.xs:100: error: too few arguments to function `mysql_shutdown'

See line 411 in mysql.h (4.1.1) vs lines 457-459 in mysql.h (4.1.3)

I got around this by modifying line 100 of mysql.xs as follows:

result = mysql_shutdown(sock, SHUTDOWN_DEFAULT);

Again, obviously, that would need to be made conditional on the MySQL version.


>Glenn Fleishman wrote:
>
>>I'm new to this list, so I'm not entirely sure whether the developers
>>are on it, or whether we should be documenting all of this in some
>>parallel fashion in MySQL bug databases or elsewhere.
>
>They are. However, the explanations what went wrong, why it didn't
>work and what can be changed are way too unclear to take this as a
>proper patch, at least for me.
>
>To me this smells much more like mismatching versions, for example
>using MySQL binaries and header files from another source, or
>something similar. As long as noone is able to give an explanation
>like "In MySQL 4.1.3 was an incompatible change in the header files.
>4.1.2 looked like this: .... 4.1.3 looks like this: ... As a result
>we need to change ...", I won't change my mind.
>
>Jochen

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: DBD-mysql-2.9003 Installation Issues

am 03.07.2004 14:25:45 von Robert Sinton

OK, well, I didn't attempt a definitive analysis because, basically,
I thought that I would be in way over my head :-) But I like a challenge,
so I've had a go:

In MySQL 4.1.1, net_bufffer_length is explicitly defined in mysql_com.h,
at line 318:

extern unsigned long net_buffer_length;

In MySQL 4.1.2 (and now 4.1.3), net_buffer_length is only
conditionally defined,
in mysql.h, at line 326:

#if !defined(MYSQL_CLIENT) && !defined(MYSQL_SERVER) &&
!defined(EMBEDDED_LIBRARY)
#define max_allowed_packet (*mysql_get_parameters()->p_max_allowed_packet)
#define net_buffer_length (*mysql_get_parameters()->p_net_buffer_length)
#endif

But a little earlier, at line 300, we have:

#if !defined(MYSQL_SERVER) && !defined(MYSQL_CLIENT)
#define MYSQL_CLIENT
#endif

My tentative reading of this is that by the time we get to
line 326 of mysql.h, at least one of MYSQL_SERVER and MYSQL_CLIENT
will have been defined, which will fail to satisfy the test at line 326,
therefore preventing net_buffer_length from ever getting defined.

At line 493 (and mentioned at a couple of other places) in docs/ChangeLog
for MySQL 4.1.2 we have:

ChangeSet
1.1346.1.512 04/05/27 02:47:04 monty@mysql.com +4 -0
netware files should always be in 'make dist'
use opt_net_buffer_length instead of net_buffer_length

The other references seem to indicate that opt_net_buffer_length is local to
client/mysqldump.c and client/mysql.cc. However the following, at line 606
of the ChangeLog, seems relevant:

include/mysql.h
1.42.1.11 04/05/26 21:40:12 hf@deer.(none) +13 -0
mysql_get_parameters() interface added

So my best guess is that net_buffer_length has been either intentionally
or unintentionally eliminated in MySQL 4.1.2, in favour of a new
parameter-fetching interface which includes the ability to discover the
value previously known as net_buffer_length.

Perhaps (and now I'm really going out on a limb) the operation at line 300
in mysql.h is inappropriate? It looks rather odd to me: the second
clause in the #if test seems redundant, and the whole thing seems to enforce an
assumption that if you are not building the server, you must be
building the client.
It almost looks to me as if the purpose of the operation at line 326 is to say
"Well, we've re-coded for the new parameter-fetching mechanism in our client,
server, and embedded library source code, but we need to allow for
alternative uses of the header file, which may still be using the old way
of finding out net_buffer_length.", and then someone's accidentally left in
a temporary hack at line 300 which subverts all that.

As to how you would adjust DBD::mysql to handle the new parameter-fetching
interface, a reliable solution for that is definitely out of my league,
but I'm guessing that it would look something like replacing the use of
net_buffer_length with (*mysql_get_parameters()->p_net_buffer_length),
as seen at line 328 of mysql.h. Of course, you would have to make that
conditional on whether you are building it with MySQL 4.1.2 or later.

I modified line 355 of mysql.xs as follows, which allowed the build
to complete,
and passed a simple operational test:

retsv = newSViv((*mysql_get_parameters()->p_net_buffer_length));


As I said, I don't really have the experience to comment definitively
on this issue, and I apologise if some of my terminology is mangled,
but hopefully the above is of some help. I am keen to learn, so if
you feel like
pointing out any blunders I'd be most grateful.

Cheers,
Robert

PS Checking the above against the new 4.1.3 beta, I found that
mysql_shutdown()
has acquired an extra argument in that version, which introduces a further
compilation hitch for DBD::mysql:

cc -c -I/Library/Perl/5.8.1/darwin-thread-multi-2level/auto/DBI
-I/usr/local/mysql/include -fno-omit-frame-pointer -g -pipe -pipe
-fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing
-I/usr/local/include -Os -DVERSION=\"2.9003\"
-DXS_VERSION=\"2.9003\"
"-I/System/Library/Perl/5.8.1/darwin-thread-multi-2level/COR E"
mysql.c
mysql.xs: In function `XS_DBD__mysql__dr__admin_internal':
mysql.xs:100: error: too few arguments to function `mysql_shutdown'

See line 411 in mysql.h (4.1.1) vs lines 457-459 in mysql.h (4.1.3)

I got around this by modifying line 100 of mysql.xs as follows:

result = mysql_shutdown(sock, SHUTDOWN_DEFAULT);

Again, obviously, that would need to be made conditional on the MySQL version.


>Glenn Fleishman wrote:
>
>>I'm new to this list, so I'm not entirely sure whether the developers
>>are on it, or whether we should be documenting all of this in some
>>parallel fashion in MySQL bug databases or elsewhere.
>
>They are. However, the explanations what went wrong, why it didn't
>work and what can be changed are way too unclear to take this as a
>proper patch, at least for me.
>
>To me this smells much more like mismatching versions, for example
>using MySQL binaries and header files from another source, or
>something similar. As long as noone is able to give an explanation
>like "In MySQL 4.1.3 was an incompatible change in the header files.
>4.1.2 looked like this: .... 4.1.3 looks like this: ... As a result
>we need to change ...", I won't change my mind.
>
>Jochen

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: DBD-mysql-2.9003 Installation Issues

am 03.07.2004 15:45:14 von Rudy Lippan

On Sun, 4 Jul 2004, Robert Sinton wrote:

> In MySQL 4.1.2 (and now 4.1.3), net_buffer_length is only
> conditionally defined,
> in mysql.h, at line 326:
>
> #if !defined(MYSQL_CLIENT) && !defined(MYSQL_SERVER) &&
> !defined(EMBEDDED_LIBRARY)
> #define max_allowed_packet (*mysql_get_parameters()->p_max_allowed_packet)
> #define net_buffer_length (*mysql_get_parameters()->p_net_buffer_length)
> #endif

I thought that this was fixed in the 4.1.3 client libraries. IIRC, having
client defined should not cause net_buffer_length to not be defined. I will
speak with Patrick on monday about this, but I guess that even if the client
libs are broken, I will still have to put a work-around for this in 2.9004.


> PS Checking the above against the new 4.1.3 beta, I found that
> mysql_shutdown()
> has acquired an extra argument in that version, which introduces a further
> compilation hitch for DBD::mysql:
>

This is already in DBD::mysql-2.9004_2. 2.9004 should be out sometime next week
(tuesday if I don't hear of any problems and the mac build works). The release
of 2.9004_2 got delayed because of pause being down, and then I did not want to
go with a full non-beta release of DBD::mysql Just before going offline for a
day or two ;)


Thank you.

Rudy


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: DBD-mysql-2.9003 Installation Issues

am 03.07.2004 15:45:14 von Rudy Lippan

On Sun, 4 Jul 2004, Robert Sinton wrote:

> In MySQL 4.1.2 (and now 4.1.3), net_buffer_length is only
> conditionally defined,
> in mysql.h, at line 326:
>
> #if !defined(MYSQL_CLIENT) && !defined(MYSQL_SERVER) &&
> !defined(EMBEDDED_LIBRARY)
> #define max_allowed_packet (*mysql_get_parameters()->p_max_allowed_packet)
> #define net_buffer_length (*mysql_get_parameters()->p_net_buffer_length)
> #endif

I thought that this was fixed in the 4.1.3 client libraries. IIRC, having
client defined should not cause net_buffer_length to not be defined. I will
speak with Patrick on monday about this, but I guess that even if the client
libs are broken, I will still have to put a work-around for this in 2.9004.


> PS Checking the above against the new 4.1.3 beta, I found that
> mysql_shutdown()
> has acquired an extra argument in that version, which introduces a further
> compilation hitch for DBD::mysql:
>

This is already in DBD::mysql-2.9004_2. 2.9004 should be out sometime next week
(tuesday if I don't hear of any problems and the mac build works). The release
of 2.9004_2 got delayed because of pause being down, and then I did not want to
go with a full non-beta release of DBD::mysql Just before going offline for a
day or two ;)


Thank you.

Rudy


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: DBD-mysql-2.9003 Installation Issues

am 03.07.2004 23:16:11 von Robert Sinton

>This is already in DBD::mysql-2.9004_2.

Oops, sorry, I was getting DBD::mysql from CPAN, and didn't think to
check for a dev. version.

Cheers,
Robert

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

Re: DBD-mysql-2.9003 Installation Issues

am 03.07.2004 23:16:11 von Robert Sinton

>This is already in DBD::mysql-2.9004_2.

Oops, sorry, I was getting DBD::mysql from CPAN, and didn't think to
check for a dev. version.

Cheers,
Robert

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

DBD-mysql-2.9004 [was Re: DBD-mysql-2.9003 Installation Issues]

am 05.07.2004 16:17:23 von Steve Hay

Hi,

Rudy Lippan wrote:

>2.9004 should be out sometime next week
>(tuesday if I don't hear of any problems and the mac build works). The release
>of 2.9004_2 got delayed because of pause being down, and then I did not want to
>go with a full non-beta release of DBD::mysql Just before going offline for a
>day or two ;)
>
Is there going to be any UTF-8 support added (mysql_enable_utf8) in this
release yet?

I know I've discussed it with you previously, and Gaal Yahas was also
asking the same questions recently, including a patch very similar to yours.

Or are we waiting to make proper use of MySQL 4.1.x's character set
features before doing anything?

Aside from that, 2.9004_2 worked fine for me on WinXP with perl-5.8.4
and mysql-4.1.2-alpha (except for the net_buffer_length issue and
t/mysql.t failing 46-48 which is not new).

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org

DBD-mysql-2.9004 [was Re: DBD-mysql-2.9003 Installation Issues]

am 05.07.2004 16:17:23 von Steve Hay

Hi,

Rudy Lippan wrote:

>2.9004 should be out sometime next week
>(tuesday if I don't hear of any problems and the mac build works). The release
>of 2.9004_2 got delayed because of pause being down, and then I did not want to
>go with a full non-beta release of DBD::mysql Just before going offline for a
>day or two ;)
>
Is there going to be any UTF-8 support added (mysql_enable_utf8) in this
release yet?

I know I've discussed it with you previously, and Gaal Yahas was also
asking the same questions recently, including a patch very similar to yours.

Or are we waiting to make proper use of MySQL 4.1.x's character set
features before doing anything?

Aside from that, 2.9004_2 worked fine for me on WinXP with perl-5.8.4
and mysql-4.1.2-alpha (except for the net_buffer_length issue and
t/mysql.t failing 46-48 which is not new).

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org