Thread: linking hba.c
In trying to decide how to keep ODBC compilable standalone, I can't figure out how to get md5.c in there from backend/libpq. Is it crazy to put md5.c in interfaces/odbc and symlink it from there to backend/libpq and interfaces/libpq? I don't want to have two copies of md5.c but that may be another option. Opinions? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> In trying to decide how to keep ODBC compilable standalone, I can't > figure out how to get md5.c in there from backend/libpq. Is it crazy to > put md5.c in interfaces/odbc and symlink it from there to backend/libpq > and interfaces/libpq? I don't want to have two copies of md5.c but that > may be another option. Opinions? > Seems to me that a stand-alone driver would have to have its own md5.c.... otherwise you may as well start linking in all kinds of code from the distro. Of course that is what just about all other ODBC drivers do anyway. Peter
> > In trying to decide how to keep ODBC compilable standalone, I can't > > figure out how to get md5.c in there from backend/libpq. Is it crazy to > > put md5.c in interfaces/odbc and symlink it from there to backend/libpq > > and interfaces/libpq? I don't want to have two copies of md5.c but that > > may be another option. Opinions? > > > > Seems to me that a stand-alone driver would have to have its own md5.c.... > otherwise you may as well start linking in all kinds of code from the > distro. Of course that is what just about all other ODBC drivers do anyway. If we want to have only one copy of md5.c, and we want ODBC to be standalone, the only way I can think to do it is to link the _other_ uses of md5.c back to interfaces/odbc/md5.c -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> In trying to decide how to keep ODBC compilable standalone, I can't
> figure out how to get md5.c in there from backend/libpq.
AFAIK ODBC hasn't been compilable standalone for awhile; doesn't it
depend on our toplevel configure script now?
> Is it crazy to
> put md5.c in interfaces/odbc and symlink it from there to backend/libpq
> and interfaces/libpq?
YES, that's crazy. If you think ODBC should build separately, then give
it its own copy of md5.c. But please first check that your assumption
is still valid.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > In trying to decide how to keep ODBC compilable standalone, I can't > > figure out how to get md5.c in there from backend/libpq. > > AFAIK ODBC hasn't been compilable standalone for awhile; doesn't it > depend on our toplevel configure script now? The Unix version is not compilable on its own, but I see no code in win32.mak that refers to upper directories. > > > Is it crazy to > > put md5.c in interfaces/odbc and symlink it from there to backend/libpq > > and interfaces/libpq? > > YES, that's crazy. If you think ODBC should build separately, then give > it its own copy of md5.c. But please first check that your assumption > is still valid. And I will just throw a note at the top of each mentioning they should be identical. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > In trying to decide how to keep ODBC compilable standalone, I can't > > > figure out how to get md5.c in there from backend/libpq. > > > > AFAIK ODBC hasn't been compilable standalone for awhile; doesn't it > > depend on our toplevel configure script now? > > The Unix version is not compilable on its own, but I see no code in > win32.mak that refers to upper directories. Yes. > > > > > Is it crazy to > > > put md5.c in interfaces/odbc and symlink it from there to backend/libpq > > > and interfaces/libpq? > > > > YES, that's crazy. If you think ODBC should build separately, then give > > it its own copy of md5.c. But please first check that your assumption > > is still valid. > > And I will just throw a note at the top of each mentioning they should > be identical. Is it that easy to copy md5.c ? ms5.c includes postgres.h and libpq/crypt.h. I prefer to have e.g. md5.dll. regards, Hiroshi Inoue
> > > > Is it crazy to > > > > put md5.c in interfaces/odbc and symlink it from there to backend/libpq > > > > and interfaces/libpq? > > > > > > YES, that's crazy. If you think ODBC should build separately, then give > > > it its own copy of md5.c. But please first check that your assumption > > > is still valid. > > > > And I will just throw a note at the top of each mentioning they should > > be identical. > > Is it that easy to copy md5.c ? > ms5.c includes postgres.h and libpq/crypt.h. > I prefer to have e.g. md5.dll. There is not much there. I can use a -Ddefine in ODBC and just conditionally define what I need when I am compiling in ODBC. Isn't worth a DLL. Can you help me add MD5 to ODBC? I am getting lost in the way they do passwords, and I don't even have a MSWin machine to test it once I am done. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026