Re: Building DBD::Oracle with one version but deploying with another
Yep, that's exactly what I'm getting at. Apparently ActiveState makes this work with their DBD::Oracle package. So, I'm wondering how I can make it work, too. What are the limitations? Why does ORACLE_HOME and LD_LIBRARY_PATH need to be set during build/installation rather than just during runtime? > > From: Jan Dubois >To: John Wiersba >Cc: Lyle ; "dbi-dev@perl.org" >Sent: Thursday, April 18, 2013 1:41 PM >Subject: Re: Building DBD::Oracle with one version but deploying with another > > >Sorry, I can't remember the details. I think you must use clients for >the same version of Oracle on the server, e.g. if you compiled >DBD::Oracle with an Oracle 10 instant client, then it doesn't seem to >work with an Oracle 11 client. But my memories of that are foggy; I >don't know if this is just a limitation on Windows, or if it applies >everywhere. > >I also never tried to run DBD::Oracle compiled against the instant >client with a server that has the regular client installed. I kind of >expect it to work, if they are the same versions, but haven't verified >it. > >Cheers, >-Jan > > >On Thu, Apr 18, 2013 at 10:16 AM, John Wiersba wrote: >> Yes, I'm doing that. Each server can have a different environment than the >> server the original DBD:Oracle was built on. Or the question still applies >> if I want to use a different version of Oracle installed on the original >> build server, especially if I remove the version of Oracle that was used to >> build the original DBD::Oracle. >> >> >> From: Jan Dubois >> To: John Wiersba >> Cc: Lyle ; "dbi-dev@perl.org" >> Sent: Thursday, April 18, 2013 1:09 PM >> >> Subject: Re: Building DBD::Oracle with one version but deploying with >> another >> >> I think you also need to add the ORACLE_HOME directory to >> LD_LIBRARY_PATH (on the deployment machine) to make it work. >> >> Cheers, >> -Jan >> >> On Thu, Apr 18, 2013 at 9:04 AM, John Wiersba wrote: >>> Thanks, Lyle. I'm trying to build DBD::Oracle on Linux/AIX/Solaris for >>> distribution to another server (assume the OS and perl versions on both >>> servers) which will have a different ORACLE_HOME, possibly a different >>> version of the Oracle client and likely in a different location. The target >>> server may not have a C compiler. >>> >>> That's the same situation that ActiveState must have encountered, building >>> DBD::Oracle with whatever version of Oracle they had downloaded and >>> installed in some random location, but deploying it on the user's server >>> which likely has a different version of Oracle installed in a different >>> location. >>> >>> >>> >>> From: Lyle To: dbi-dev@perl.org Sent: Thursday, April 18, 2013 11:43 AM Subject: Re: Building DBD::Oracle with one version but deploying with another On 18/04/2013 16:22, John Wiersba wrote: > [A previous version of this question was asked on dbi-users -- I haven't > gotten any response there. Not sure which list to post to.] > > Hi, I'd like to find out how to build/install DBD::Oracle with one > version of Oracle client but then deploy it with a potentially different > client version, say on a server without the original client version (or > with > it installed in a different location). It seems like the Oracle > client libraries can be loaded dynamically at runtime, based on > ORACLE_HOME, so there doesn't need to be a dependency on those exact > client libraries that were used at build/install time. > > Another > way of asking: How does ActiveState deploy DBD::Oracle without needing > to build it (maybe no C compiler is available), on servers with > different versions of the Oracle client libraries installed? I built DBD::Oracle on windows recently. I did need the Oracle client libraries for the tests to pass, and ActiveState would have too. Once built they package up the binaries for distribution, and expect the target system to have the appropriate libraries. If I remember correctly, I had to download the appropriate libraries from Oracle. I spoke to the vanilla Perl people about this, as they currently don't have a DBD::Oracle bundled in with their distro. They had been looking at bundling the client libraries as well, but I think there is a licensing issues surrounding doing that which is why ActiveState do not do it. We agreed to take another look at it next month as I'm very busy this month. > I've searched the archives for both dbi-dev and dbi-users and can't find > this issue addressed, although I did see a similar issue asked once. If > there's any reference material that I have overlooked, could you please > point it out. The README for DBD::Oracle seems to indicate that this is > not > possible or not advised, but then what is Active
Re: DBD::mysql - bit worrying
On 18/04/2013 20:09, Paul DuBois wrote: On Apr 18, 2013, at 12:07 PM, Patrick Galbraith wrote: Lyle, To be certain, they don't wish to "kill" DBD::mysql. They are really trying to define what Oracle supports and what they do not. The were very helpful in painstakingly migrating the bugs from their system manually to RT. Albeit, I have my work cut out for me now :) I'm not an official spokesman for Oracle, although I do work for them. I am unaware of any effort against DBD::mysql. Nor has Oracle made any effort to dissuade me from writing about DBD::mysql, e.g., at http://www.kitebird.com/mysql-book/. (You can view that URL as a shameless plug or just evidence in support of the preceding claims, your choice. :-)) Paul, that's good to hear :) Patrick, I've since noticed more issues that I covered in my patch. Hopefully next month I'll get chance to give it a more thorough check. Lyle Regards, Patrick On Apr 11, 2013, at 8:28 PM, Lyle wrote: On 12/04/2013 00:58, Darren Duncan wrote: On 2013.04.11 4:37 PM, Lyle wrote: Hmm... Got a reply to my bug report and it's a bit worrying: http://bugs.mysql.com/bug.php?id=68266 Seems like MySQL don't want to directly support DBD::mysql any more. Whether you like mysql or not, that's a heavily used DBD. I'm not aware that DBD::mysql was ever supported through the general MySQL bug reporter, and I understood it was a separate project. It most certainly was, for example: http://bugs.mysql.com/bug.php?id=20153 The DBD::mysql docs still tell you to report bugs there. Even I was able to submit a bug to their DBD::mysql category just last February, they've only just removed it from the bug reporter. I think Patrick Galbraith is the person you should ask about this matter, as Patrick has been the one releasing DBD::mysql on CPAN for many years, a full decade at this point. I've just joined the p...@lists.mysql.com mailing list. It'll be interesting to see if that list stays or gets removed as well. Lyle -- Darren Duncan
Re: DBD::mysql - bit worrying
On Apr 18, 2013, at 12:07 PM, Patrick Galbraith wrote: > Lyle, > > To be certain, they don't wish to "kill" DBD::mysql. They are really trying > to define what Oracle supports and what they do not. The were very helpful in > painstakingly migrating the bugs from their system manually to RT. Albeit, I > have my work cut out for me now :) I'm not an official spokesman for Oracle, although I do work for them. I am unaware of any effort against DBD::mysql. Nor has Oracle made any effort to dissuade me from writing about DBD::mysql, e.g., at http://www.kitebird.com/mysql-book/. (You can view that URL as a shameless plug or just evidence in support of the preceding claims, your choice. :-)) > > Regards, > > Patrick > > On Apr 11, 2013, at 8:28 PM, Lyle wrote: > >> On 12/04/2013 00:58, Darren Duncan wrote: >>> On 2013.04.11 4:37 PM, Lyle wrote: Hmm... Got a reply to my bug report and it's a bit worrying: http://bugs.mysql.com/bug.php?id=68266 Seems like MySQL don't want to directly support DBD::mysql any more. Whether you like mysql or not, that's a heavily used DBD. >>> >>> I'm not aware that DBD::mysql was ever supported through the general MySQL >>> bug reporter, and I understood it was a separate project. >> >> It most certainly was, for example: >> http://bugs.mysql.com/bug.php?id=20153 >> >> The DBD::mysql docs still tell you to report bugs there. Even I was able to >> submit a bug to their DBD::mysql category just last February, they've only >> just removed it from the bug reporter. >> >>> I think Patrick Galbraith is the person you should ask about this matter, >>> as Patrick has been the one releasing DBD::mysql on CPAN for many years, a >>> full decade at this point. >> >> I've just joined the p...@lists.mysql.com mailing list. It'll be interesting >> to see if that list stays or gets removed as well. >> >> >> Lyle >> >>> >>> -- Darren Duncan >>> >>> >> >
Re: Building DBD::Oracle with one version but deploying with another
Sorry, I can't remember the details. I think you must use clients for the same version of Oracle on the server, e.g. if you compiled DBD::Oracle with an Oracle 10 instant client, then it doesn't seem to work with an Oracle 11 client. But my memories of that are foggy; I don't know if this is just a limitation on Windows, or if it applies everywhere. I also never tried to run DBD::Oracle compiled against the instant client with a server that has the regular client installed. I kind of expect it to work, if they are the same versions, but haven't verified it. Cheers, -Jan On Thu, Apr 18, 2013 at 10:16 AM, John Wiersba wrote: > Yes, I'm doing that. Each server can have a different environment than the > server the original DBD:Oracle was built on. Or the question still applies > if I want to use a different version of Oracle installed on the original > build server, especially if I remove the version of Oracle that was used to > build the original DBD::Oracle. > > > From: Jan Dubois > To: John Wiersba > Cc: Lyle ; "dbi-dev@perl.org" > Sent: Thursday, April 18, 2013 1:09 PM > > Subject: Re: Building DBD::Oracle with one version but deploying with > another > > I think you also need to add the ORACLE_HOME directory to > LD_LIBRARY_PATH (on the deployment machine) to make it work. > > Cheers, > -Jan > > On Thu, Apr 18, 2013 at 9:04 AM, John Wiersba wrote: >> Thanks, Lyle. I'm trying to build DBD::Oracle on Linux/AIX/Solaris for >> distribution to another server (assume the OS and perl versions on both >> servers) which will have a different ORACLE_HOME, possibly a different >> version of the Oracle client and likely in a different location. The target >> server may not have a C compiler. >> >> That's the same situation that ActiveState must have encountered, building >> DBD::Oracle with whatever version of Oracle they had downloaded and >> installed in some random location, but deploying it on the user's server >> which likely has a different version of Oracle installed in a different >> location. >> >> >> >> >>> >>> From: Lyle >>>To: dbi-dev@perl.org >>>Sent: Thursday, April 18, 2013 11:43 AM >>>Subject: Re: Building DBD::Oracle with one version but deploying with >>> another >>> >>> >>>On 18/04/2013 16:22, John Wiersba wrote: [A previous version of this question was asked on dbi-users -- I haven't gotten any response there. Not sure which list to post to.] Hi, I'd like to find out how to build/install DBD::Oracle with one version of Oracle client but then deploy it with a potentially different client version, say on a server without the original client version (or with it installed in a different location). It seems like the Oracle client libraries can be loaded dynamically at runtime, based on ORACLE_HOME, so there doesn't need to be a dependency on those exact client libraries that were used at build/install time. Another way of asking: How does ActiveState deploy DBD::Oracle without needing to build it (maybe no C compiler is available), on servers with different versions of the Oracle client libraries installed? >>> >>>I built DBD::Oracle on windows recently. I did need the Oracle client >>> libraries for the tests to pass, and ActiveState would have too. Once built >>> they package up the binaries for distribution, and expect the target system >>> to have the appropriate libraries. If I remember correctly, I had to >>> download the appropriate libraries from Oracle. I spoke to the vanilla Perl >>> people about this, as they currently don't have a DBD::Oracle bundled in >>> with their distro. They had been looking at bundling the client libraries as >>> well, but I think there is a licensing issues surrounding doing that which >>> is why ActiveState do not do it. We agreed to take another look at it next >>> month as I'm very busy this month. >>> I've searched the archives for both dbi-dev and dbi-users and can't find this issue addressed, although I did see a similar issue asked once. If there's any reference material that I have overlooked, could you please point it out. The README for DBD::Oracle seems to indicate that this is not possible or not advised, but then what is ActiveState doing to make it work? >>> >>>With ActiveState's ppm, it wont work on the target system unless the >>> correct client libraries are there. I think that's what led me to build my >>> own DBD::Oracle in the first place. I was building for 64 bit Windows, and >>> found this blog post: >>>http://www.pythian.com/blog/dbdoracle-and-windows-64bit/ >>>I found errors in that post and commented with my findings, yet my comment >>> has yet to be accepted. I think Pythian is on this list? So maybe they will >>> comment. >>> >>> >>>Lyle >>> >>> >>> >>> > >
Re: Building DBD::Oracle with one version but deploying with another
Yes, I'm doing that. Each server can have a different environment than the server the original DBD:Oracle was built on. Or the question still applies if I want to use a different version of Oracle installed on the original build server, especially if I remove the version of Oracle that was used to build the original DBD::Oracle. > > From: Jan Dubois >To: John Wiersba >Cc: Lyle ; "dbi-dev@perl.org" >Sent: Thursday, April 18, 2013 1:09 PM >Subject: Re: Building DBD::Oracle with one version but deploying with another > > >I think you also need to add the ORACLE_HOME directory to >LD_LIBRARY_PATH (on the deployment machine) to make it work. > >Cheers, >-Jan > >On Thu, Apr 18, 2013 at 9:04 AM, John Wiersba wrote: >> Thanks, Lyle. I'm trying to build DBD::Oracle on Linux/AIX/Solaris for >> distribution to another server (assume the OS and perl versions on both >> servers) which will have a different ORACLE_HOME, possibly a different >> version of the Oracle client and likely in a different location. The target >> server may not have a C compiler. >> >> That's the same situation that ActiveState must have encountered, building >> DBD::Oracle with whatever version of Oracle they had downloaded and >> installed in some random location, but deploying it on the user's server >> which likely has a different version of Oracle installed in a different >> location. >> >> >> >> >>> >>> From: Lyle >>>To: dbi-dev@perl.org >>>Sent: Thursday, April 18, 2013 11:43 AM >>>Subject: Re: Building DBD::Oracle with one version but deploying with another >>> >>> >>>On 18/04/2013 16:22, John Wiersba wrote: [A previous version of this question was asked on dbi-users -- I haven't gotten any response there. Not sure which list to post to.] Hi, I'd like to find out how to build/install DBD::Oracle with one version of Oracle client but then deploy it with a potentially different client version, say on a server without the original client version (or with it installed in a different location). It seems like the Oracle client libraries can be loaded dynamically at runtime, based on ORACLE_HOME, so there doesn't need to be a dependency on those exact client libraries that were used at build/install time. Another way of asking: How does ActiveState deploy DBD::Oracle without needing to build it (maybe no C compiler is available), on servers with different versions of the Oracle client libraries installed? >>> >>>I built DBD::Oracle on windows recently. I did need the Oracle client >>>libraries for the tests to pass, and ActiveState would have too. Once built >>>they package up the binaries for distribution, and expect the target system >>>to have the appropriate libraries. If I remember correctly, I had to >>>download the appropriate libraries from Oracle. I spoke to the vanilla Perl >>>people about this, as they currently don't have a DBD::Oracle bundled in >>>with their distro. They had been looking at bundling the client libraries as >>>well, but I think there is a licensing issues surrounding doing that which >>>is why ActiveState do not do it. We agreed to take another look at it next >>>month as I'm very busy this month. >>> I've searched the archives for both dbi-dev and dbi-users and can't find this issue addressed, although I did see a similar issue asked once. If there's any reference material that I have overlooked, could you please point it out. The README for DBD::Oracle seems to indicate that this is not possible or not advised, but then what is ActiveState doing to make it work? >>> >>>With ActiveState's ppm, it wont work on the target system unless the correct >>>client libraries are there. I think that's what led me to build my own >>>DBD::Oracle in the first place. I was building for 64 bit Windows, and found >>>this blog post: >>>http://www.pythian.com/blog/dbdoracle-and-windows-64bit/ >>>I found errors in that post and commented with my findings, yet my comment >>>has yet to be accepted. I think Pythian is on this list? So maybe they will >>>comment. >>> >>> >>>Lyle >>> >>> >>> >>> > > >
Re: Building DBD::Oracle with one version but deploying with another
I think you also need to add the ORACLE_HOME directory to LD_LIBRARY_PATH (on the deployment machine) to make it work. Cheers, -Jan On Thu, Apr 18, 2013 at 9:04 AM, John Wiersba wrote: > Thanks, Lyle. I'm trying to build DBD::Oracle on Linux/AIX/Solaris for > distribution to another server (assume the OS and perl versions on both > servers) which will have a different ORACLE_HOME, possibly a different > version of the Oracle client and likely in a different location. The target > server may not have a C compiler. > > That's the same situation that ActiveState must have encountered, building > DBD::Oracle with whatever version of Oracle they had downloaded and installed > in some random location, but deploying it on the user's server which likely > has a different version of Oracle installed in a different location. > > > > >> >> From: Lyle >>To: dbi-dev@perl.org >>Sent: Thursday, April 18, 2013 11:43 AM >>Subject: Re: Building DBD::Oracle with one version but deploying with another >> >> >>On 18/04/2013 16:22, John Wiersba wrote: >>> [A previous version of this question was asked on dbi-users -- I haven't >>> gotten any response there. Not sure which list to post to.] >>> >>> Hi, I'd like to find out how to build/install DBD::Oracle with one >>> version of Oracle client but then deploy it with a potentially different >>> client version, say on a server without the original client version (or >>> with it installed in a different location). It seems like the Oracle >>> client libraries can be loaded dynamically at runtime, based on >>> ORACLE_HOME, so there doesn't need to be a dependency on those exact >>> client libraries that were used at build/install time. >>> >>> Another >>> way of asking: How does ActiveState deploy DBD::Oracle without needing >>> to build it (maybe no C compiler is available), on servers with >>> different versions of the Oracle client libraries installed? >> >>I built DBD::Oracle on windows recently. I did need the Oracle client >>libraries for the tests to pass, and ActiveState would have too. Once built >>they package up the binaries for distribution, and expect the target system >>to have the appropriate libraries. If I remember correctly, I had to download >>the appropriate libraries from Oracle. I spoke to the vanilla Perl people >>about this, as they currently don't have a DBD::Oracle bundled in with their >>distro. They had been looking at bundling the client libraries as well, but I >>think there is a licensing issues surrounding doing that which is why >>ActiveState do not do it. We agreed to take another look at it next month as >>I'm very busy this month. >> >>> I've searched the archives for both dbi-dev and dbi-users and can't find >>> this issue addressed, although I did see a similar issue asked once. If >>> there's any reference material that I have overlooked, could you please >>> point it out. The README for DBD::Oracle seems to indicate that this is >>> not possible or not advised, but then what is ActiveState doing to make it >>> work? >> >>With ActiveState's ppm, it wont work on the target system unless the correct >>client libraries are there. I think that's what led me to build my own >>DBD::Oracle in the first place. I was building for 64 bit Windows, and found >>this blog post: >>http://www.pythian.com/blog/dbdoracle-and-windows-64bit/ >>I found errors in that post and commented with my findings, yet my comment >>has yet to be accepted. I think Pythian is on this list? So maybe they will >>comment. >> >> >>Lyle >> >> >> >>
Re: DBD::mysql - bit worrying
Lyle, To be certain, they don't wish to "kill" DBD::mysql. They are really trying to define what Oracle supports and what they do not. The were very helpful in painstakingly migrating the bugs from their system manually to RT. Albeit, I have my work cut out for me now :) Regards, Patrick On Apr 11, 2013, at 8:28 PM, Lyle wrote: > On 12/04/2013 00:58, Darren Duncan wrote: >> On 2013.04.11 4:37 PM, Lyle wrote: >>> Hmm... Got a reply to my bug report and it's a bit worrying: >>> http://bugs.mysql.com/bug.php?id=68266 >>> >>> Seems like MySQL don't want to directly support DBD::mysql any more. >>> Whether you >>> like mysql or not, that's a heavily used DBD. >> >> I'm not aware that DBD::mysql was ever supported through the general MySQL >> bug reporter, and I understood it was a separate project. > > It most certainly was, for example: > http://bugs.mysql.com/bug.php?id=20153 > > The DBD::mysql docs still tell you to report bugs there. Even I was able to > submit a bug to their DBD::mysql category just last February, they've only > just removed it from the bug reporter. > >> I think Patrick Galbraith is the person you should ask about this matter, as >> Patrick has been the one releasing DBD::mysql on CPAN for many years, a full >> decade at this point. > > I've just joined the p...@lists.mysql.com mailing list. It'll be interesting > to see if that list stays or gets removed as well. > > > Lyle > >> >> -- Darren Duncan >> >> >
Re: DBD::mysql - bit worrying
Hi Lyle, I just released 4.0.23 Which updated the documentation to reflect that MySQL/Oracle will no longer be where bugs are reported and to use http://rt.cpan.org Here is my LJ post about this matter: http://capttofu.livejournal.com/29756.html Regards, Patrick On Apr 11, 2013, at 7:37 PM, Lyle wrote: > Hmm... Got a reply to my bug report and it's a bit worrying: > http://bugs.mysql.com/bug.php?id=68266 > > Seems like MySQL don't want to directly support DBD::mysql any more. Whether > you like mysql or not, that's a heavily used DBD. > > > Lyle >
Re: Building DBD::Oracle with one version but deploying with another
Thanks, Lyle. I'm trying to build DBD::Oracle on Linux/AIX/Solaris for distribution to another server (assume the OS and perl versions on both servers) which will have a different ORACLE_HOME, possibly a different version of the Oracle client and likely in a different location. The target server may not have a C compiler. That's the same situation that ActiveState must have encountered, building DBD::Oracle with whatever version of Oracle they had downloaded and installed in some random location, but deploying it on the user's server which likely has a different version of Oracle installed in a different location. > > From: Lyle >To: dbi-dev@perl.org >Sent: Thursday, April 18, 2013 11:43 AM >Subject: Re: Building DBD::Oracle with one version but deploying with another > > >On 18/04/2013 16:22, John Wiersba wrote: >> [A previous version of this question was asked on dbi-users -- I haven't >> gotten any response there. Not sure which list to post to.] >> >> Hi, I'd like to find out how to build/install DBD::Oracle with one >> version of Oracle client but then deploy it with a potentially different >> client version, say on a server without the original client version (or with >> it installed in a different location). It seems like the Oracle >> client libraries can be loaded dynamically at runtime, based on >> ORACLE_HOME, so there doesn't need to be a dependency on those exact >> client libraries that were used at build/install time. >> >> Another >> way of asking: How does ActiveState deploy DBD::Oracle without needing >> to build it (maybe no C compiler is available), on servers with >> different versions of the Oracle client libraries installed? > >I built DBD::Oracle on windows recently. I did need the Oracle client >libraries for the tests to pass, and ActiveState would have too. Once built >they package up the binaries for distribution, and expect the target system to >have the appropriate libraries. If I remember correctly, I had to download the >appropriate libraries from Oracle. I spoke to the vanilla Perl people about >this, as they currently don't have a DBD::Oracle bundled in with their distro. >They had been looking at bundling the client libraries as well, but I think >there is a licensing issues surrounding doing that which is why ActiveState do >not do it. We agreed to take another look at it next month as I'm very busy >this month. > >> I've searched the archives for both dbi-dev and dbi-users and can't find >> this issue addressed, although I did see a similar issue asked once. If >> there's any reference material that I have overlooked, could you please >> point it out. The README for DBD::Oracle seems to indicate that this is not >> possible or not advised, but then what is ActiveState doing to make it work? > >With ActiveState's ppm, it wont work on the target system unless the correct >client libraries are there. I think that's what led me to build my own >DBD::Oracle in the first place. I was building for 64 bit Windows, and found >this blog post: >http://www.pythian.com/blog/dbdoracle-and-windows-64bit/ >I found errors in that post and commented with my findings, yet my comment has >yet to be accepted. I think Pythian is on this list? So maybe they will >comment. > > >Lyle > > > >
Re: Building DBD::Oracle with one version but deploying with another
On 18/04/2013 16:22, John Wiersba wrote: [A previous version of this question was asked on dbi-users -- I haven't gotten any response there. Not sure which list to post to.] Hi, I'd like to find out how to build/install DBD::Oracle with one version of Oracle client but then deploy it with a potentially different client version, say on a server without the original client version (or with it installed in a different location). It seems like the Oracle client libraries can be loaded dynamically at runtime, based on ORACLE_HOME, so there doesn't need to be a dependency on those exact client libraries that were used at build/install time. Another way of asking: How does ActiveState deploy DBD::Oracle without needing to build it (maybe no C compiler is available), on servers with different versions of the Oracle client libraries installed? I built DBD::Oracle on windows recently. I did need the Oracle client libraries for the tests to pass, and ActiveState would have too. Once built they package up the binaries for distribution, and expect the target system to have the appropriate libraries. If I remember correctly, I had to download the appropriate libraries from Oracle. I spoke to the vanilla Perl people about this, as they currently don't have a DBD::Oracle bundled in with their distro. They had been looking at bundling the client libraries as well, but I think there is a licensing issues surrounding doing that which is why ActiveState do not do it. We agreed to take another look at it next month as I'm very busy this month. I've searched the archives for both dbi-dev and dbi-users and can't find this issue addressed, although I did see a similar issue asked once. If there's any reference material that I have overlooked, could you please point it out. The README for DBD::Oracle seems to indicate that this is not possible or not advised, but then what is ActiveState doing to make it work? With ActiveState's ppm, it wont work on the target system unless the correct client libraries are there. I think that's what led me to build my own DBD::Oracle in the first place. I was building for 64 bit Windows, and found this blog post: http://www.pythian.com/blog/dbdoracle-and-windows-64bit/ I found errors in that post and commented with my findings, yet my comment has yet to be accepted. I think Pythian is on this list? So maybe they will comment. Lyle
Building DBD::Oracle with one version but deploying with another
[A previous version of this question was asked on dbi-users -- I haven't gotten any response there. Not sure which list to post to.] Hi, I'd like to find out how to build/install DBD::Oracle with one version of Oracle client but then deploy it with a potentially different client version, say on a server without the original client version (or with it installed in a different location). It seems like the Oracle client libraries can be loaded dynamically at runtime, based on ORACLE_HOME, so there doesn't need to be a dependency on those exact client libraries that were used at build/install time. Another way of asking: How does ActiveState deploy DBD::Oracle without needing to build it (maybe no C compiler is available), on servers with different versions of the Oracle client libraries installed? I've searched the archives for both dbi-dev and dbi-users and can't find this issue addressed, although I did see a similar issue asked once. If there's any reference material that I have overlooked, could you please point it out. The README for DBD::Oracle seems to indicate that this is not possible or not advised, but then what is ActiveState doing to make it work? Thanks!-- John
SQL-Statement
On request from Jens: $ git clone github.com:perl5-dbi/dbi.git SQL-Statement is now a full copy of https://github.com/rehsack/SQL-Statement The new location does NOT know about the old, as it can now be used as the new decisive source: that is up to Jens. Enjoy! -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
