Re: PL/Perl without shared libperl.a
От | Peter Eisentraut |
---|---|
Тема | Re: PL/Perl without shared libperl.a |
Дата | |
Msg-id | Pine.LNX.4.30.0105112347260.757-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: PL/Perl without shared libperl.a (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
Tom Lane writes: > Hmm. Or perhaps we could just go ahead and try to build libperl.so, > but not abort the make if it fails. The reason for the shlib test > originally was that we didn't want the whole build of Postgres to blow > up if we couldn't link libperl.so. Seems like you end up with no > libperl.so either way, so perhaps we could hack the Makefile to not > treat link failure as fatal. The trick is that it's a makefile > generated by MakeMaker and not entirely under our control... Or we could get rid of that makefile and write our own. MakeMaker is a piece of gar^H^H^Hoverengineering anyway. I have such a makefile worked out as a proof of concept I did a while ago. I find it a lot better in many ways already. What I would suggest in any case is that we test at configure time (no time like configure time) whether libperl is shared (using the current, official mechanism). If not, we print a warning message and disable the build. If the user wants to try it anyway we could provide some way to override it, e.g., (stupid) --with-perl=i_want_plperl, or they could go into the directory and build it there. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
В списке pgsql-general по дате отправления: