Re: determining if we're using db.h from libc6 or libdb2?
Domenico Andreoli, in an immanent manifestation of deity, wrote: i don't know how much what i'm going to say would be of help, but if you added a new check in configure.in in order to let your source know what kind of db.h you have? you could be pretty sure that your sources are getting compiled the right way. Well, I'd need to know how to detect it. I'm assuming that this isn't a bundled module with configure. I can't just detect for db2.4 since that just happens to be the version included in glibc2.[01]. The user might just have that version installed. I suppose that I could have configure write a C program that included db.h and linked with -ldb. If it failed, try including db2/db.h and if that worked, then I've isolated the problem in configure. Darren -- [EMAIL PROTECTED]http://www.daft.com/~torin/ [EMAIL PROTECTED][EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-206-ELF-LIPZ @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @ @Make a little hot-tub in your soul. @ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: determining if we're using db.h from libc6 or libdb2?
On Wed, Sep 13, 2000 at 02:38:07PM -0700, Darren/Torin/Who Ever... wrote:
Domenico Andreoli, in an immanent manifestation of deity, wrote:
i don't know how much what i'm going to say would be of help, but if you
added
a new check in configure.in in order to let your source know what kind of
db.h
you have? you could be pretty sure that your sources are getting compiled the
right way.
Well, I'd need to know how to detect it. I'm assuming that this isn't a
bundled module with configure. I can't just detect for db2.4 since that
just happens to be the version included in glibc2.[01]. The user might
just have that version installed.
of course you cannot test version numbers only. yes, version could help to
choose whether or not the test is needed. you know that below a certain
version you are speaking of db2 in glibc2 and above you are speaking of db2
out of glibc2. between these versions you have ambiguity and test is needed.
what to do in this test i'm not able to tell you.
I suppose that I could have configure write a C program that included
db.h and linked with -ldb. If it failed, try including db2/db.h and
if that worked, then I've isolated the problem in configure.
i suppose you should care what the linker is linking your test code at too, but
you already know this.
i have a printed manual of autoconf i've never read too much. it seems not to be
a great pain write new tests, but for sure it is neither *that* easy. i never
did
such a thing before.
IMHO, your problem your problem is best solved by autoconf.
btw, if i'm not wrong, these changes in glibc2 affects many other developers.
maybe in autoconf's upstream level they will write this test. maybe.
i'm sorry i cannot help you more :((
cheers
ps: and if you check for something like __DB_H__ after the header that in older
glibc2 would have included it? if this symbol is not defined, it means that you
are talking about a glibc2 without db2. so you know where to look for it.
db2/db.h! since i don't know which relation exists between glibc2 headers and
db2 ones, i could be completely wrong. :(
just an idea to make simpler the test for autoconf. something like:
#include whatever_glibc2_header_should_include_db_H.h
int main()
{
#ifdef __DB_H__
return 0;
#elif
return 1;
#endif
}
checking the return of this test you should know what kind of db.h you have and
you don't even care about which library to link it at! this code should work
without any db2 library linked, since it doesn't reference any external symbol.
hmm, i'm not so sure of this last words... i'm not a great developer.
but once you know who db.h is, you know which db2 shared library you need.
... more 2 cents... :)
-[ Domenico Andreoli, aka cavok
--[ get my public gpg key at http://www.freeweb.org/free/cavok/gpgkey.asc
-[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
pgp6wl1OMhNtk.pgp
Description: PGP signature
Re: determining if we're using db.h from libc6 or libdb2?
In article [EMAIL PROTECTED], Darren/Torin/Who Ever... [EMAIL PROTECTED] wrote: Ben Collins, in an immanent manifestation of deity, wrote: On Tue, Sep 12, 2000 at 12:46:02AM -0700, Darren/Torin/Who Ever... wrote: Is there some set of defines such that I can determine with #ifdef that I've got a copy of glibc2 that has db.h as an include file? My plan is that if such a #ifdef is true, then I can #include db2/db.h. Keep it at db.h, since in a few days, it wont matter. Db2 is getting removed from glibc, and your only choice will be db.h or db2/db.h from libdb2 (both the same file, just db.h is the default place). Well, I was hoping to have a general solution because that version of glibc2 is still going to be used for a while. Something like #if (__GLIBC__ == 2) (__GLIBC_MINOR__ 2) /* Glibc 2.0 and 2.1 */ # include db2/db.h #else /* Must be Glibc 2.2 or later */ # include db.h #endif Mike. -- Deadlock, n.: Deceased rastaman. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
determining if we're using db.h from libc6 or libdb2?
Is there some set of defines such that I can determine with #ifdef that I've got a copy of glibc2 that has db.h as an include file? My plan is that if such a #ifdef is true, then I can #include db2/db.h. Thanks, Darren -- [EMAIL PROTECTED]http://www.daft.com/~torin/ [EMAIL PROTECTED][EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-206-ELF-LIPZ @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @ @Make a little hot-tub in your soul. @ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: determining if we're using db.h from libc6 or libdb2?
On Tue, Sep 12, 2000 at 12:46:02AM -0700, Darren/Torin/Who Ever... wrote: Is there some set of defines such that I can determine with #ifdef that I've got a copy of glibc2 that has db.h as an include file? My plan is that if such a #ifdef is true, then I can #include db2/db.h. Keep it at db.h, since in a few days, it wont matter. Db2 is getting removed from glibc, and your only choice will be db.h or db2/db.h from libdb2 (both the same file, just db.h is the default place). -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: determining if we're using db.h from libc6 or libdb2?
Ben Collins, in an immanent manifestation of deity, wrote: On Tue, Sep 12, 2000 at 12:46:02AM -0700, Darren/Torin/Who Ever... wrote: Is there some set of defines such that I can determine with #ifdef that I've got a copy of glibc2 that has db.h as an include file? My plan is that if such a #ifdef is true, then I can #include db2/db.h. Keep it at db.h, since in a few days, it wont matter. Db2 is getting removed from glibc, and your only choice will be db.h or db2/db.h from libdb2 (both the same file, just db.h is the default place). Well, I was hoping to have a general solution because that version of glibc2 is still going to be used for a while. I have systems that will stay at potato until about a month after woody has been released. Others must be in the same position. I know that I could go trolling through the headers but I'd prefer a documented solution to a cobbled solution. BTW, the reason that I need this is to get openldap 2 to run on i386. It took me about two hours to figure out that it was including the headers for db2.4 (in glibc2) while using the library from db2.7. The error looks like: slapadd: ldbm_db_errcall(): == DB_DUPSORT requires DB_DUP slapadd: Could not open/create id2entry.dbb Darren -- [EMAIL PROTECTED]http://www.daft.com/~torin/ [EMAIL PROTECTED][EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-206-ELF-LIPZ @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @ @Make a little hot-tub in your soul. @ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
