Re: Failed install - libgen.so doesn't exist
От | Bruce Momjian |
---|---|
Тема | Re: Failed install - libgen.so doesn't exist |
Дата | |
Msg-id | 200602011631.k11GV4G20094@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Failed install - libgen.so doesn't exist (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Failed install - libgen.so doesn't exist
|
Список | pgsql-ports |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> I'm just wondering how many of those AC_CHECK_LIB calls are needed only > >> on platforms that no one uses anymore ... > > > I didn't want to mention that, but one big problem we have is that we > > have no way to know what platforms are still using which configure and > > pgport functions. It is very possible that 25% of what we have isn't > > needed anymore, but we have no way of knowing which part. > > Agreed, but pgport functions that aren't actually selected for use don't > pose any hazards. AC_CHECK_LIB is an ongoing hazard for exactly the > reason the OP presents, namely that it will suck in any random library > it can find that happens to match by name. It's especially bad that > almost all of the tests are coded like > AC_CHECK_LIB(gen, main) > which means they don't even try to determine whether the library > is actually the one intended. > > Now that we have the buildfarm I think that experimentation with this > sort of thing is a lot less risky than it used to be. I think we should > be working towards a project policy that AC_CHECK_LIB calls shalt not > use "main", but must name some symbol exported by the expected library. > If we can't find out what symbols the library is expected to provide, > it's time to dike it out. Agreed. Anyone want to do the legwork? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-ports по дате отправления: