Hi Robert: First and foremost, if your system is running okay then you can simply ignore the error message.
Second, the story (as uncovered by Dan Wells) is that libdbi-drivers changed in release 0.83 so that the old --enable-libdbi flag that used to be required to link the drivers to the libdbi.so library now does the exact opposite. So depending on your version of libdbi-drivers, you may or may not have to use the --enable-libdbi flag. We probably need to update Makefile.install accordingly. Dan 2008/7/9 Robert Soulliere <[EMAIL PROTECTED]>: > I am getting the error when running settings-tester.pl: > > "/usr/local/lib/dbd/libdbdpgsql.so was not linged against libdbi - you > probably need to compile libdbi-drivers from source with the --enable > -libdbi configure switch." > > I thought this question came up in the past and tried to find a solution > in past Evergreen-Dev posts but could not so I apologize if I am > bringing up a old issue which has already been discussed. > > I tried to do what following the instructions indicated on: > http://open-ils.org/dokuwiki/doku.php?id=libdbi > to no avail. > > Is there another problem here I should look into? I am running Evergreen > version 1.2.1.4 on a Debian Linux server. > > Thanks, > Robert > > > > > > ----- Original Message ----- > From: Dan Scott <[EMAIL PROTECTED]> > Date: Tuesday, July 8, 2008 11:45 am > Subject: [OPEN-ILS-DEV] 1.4 release: switching locales in the OPAC and > staff client > To: Evergreen Development Discussion List > <[email protected]> > >> Thoughts on the following proposal for the (rapidly approaching) >> 1.4 release? >> >> I'm particularly interested in the plumbing for supported & default >> locales. We could conceivably have one set of locales supported for >> the OPAC, and a different (probably smaller) set of locales supported >> for the staff client. And corresponding to that, a staff user might >> prefer to use the OPAC in one locale, but use the staff client in a >> different locale (probably because the corresponding translation isn't >> available in the staff client). This is trickiest to manage if we do >> opt to support a "locale preference" at the user level; but one way >> might be to implement locale preference as a fall-through list akin to >> how browsers do it, so if a given locale isn't available the next one >> is automatically tried. >> >> Related issue: I don't think there's a way of expressing a supported >> set of locales in the system. And the default locale is currently >> hard-coded as en-US. Would it make sense to beef up opensrf.xml to >> include a <locales> element within <default> (possibly with a list of >> <supported_locale> child elements and a single <default_locale> child >> element) and teach the various libraries to rely on that? Or would it >> make more sense to push those settings into the database where we can >> provide a user-friendly admin interface? >> >> Hmm. Part of me likes the database approach, as it means that we could >> have an actor.org_unit_setting override the system-wide default locale >> (in our consortium, some libraries are French-only, others are >> English-only). But perhaps that particular problem would be best >> handled via Apache configuration anyways (as the library would >> probably use a different URL entry point to get to the OPAC). >> >> Sorry, I started rambling there. Hopefully this is more helpful >> rambling than hurtful. >> >> ==== >> >> In 1.4, the OPAC interface will be fully supported in multiple >> locales. >> Currently, the locale is determined by the URL, with supported locales >> and the default locale set in eg_vhost.conf. For example: >> * en-US (http://biblio-dev.laurentian.ca/opac/en- >> US/skin/lul/xml/index.xml) * fr-CA (http://biblio- >> dev.laurentian.ca/opac/fr-CA/skin/lul/xml/index.xml) >> >> For the production release of the i18n support for the OPAC, we need >> to add a user-friendly locale switcher mechanism in the OPAC. >> >> The switcher should expose: >> * the list of supported locales (defined in opensrf.xml?) >> * the associated locale name displayed in the language of the >> respective locale >> >> It would be nice if the preference were sticky across sessions (likely >> via a cookie). >> >> We may also want to expose this as a user preference in "My Account"; >> that could also drive other language / locale selections for tasks >> like generating overdue notices. We cannot rely solely on "My Account" >> because most users will be accessing the OPAC unauthenticated. >> >> Suggested priority of locale selections (where subsequent levels >> override the previous): >> * System default locale (set in eg_vhost.conf? or in opensrf.xml?) >> * Org unit default locale (set in actor.org_unit_settings? or >> perhaps just based on Apache configuration) >> * [http://www.w3.org/International/questions/qa-lang-priorities >> User-agent locale preference sniffing] >> * My Account preference >> * OPAC locale switcher UI / cookie >> >> -- >> Dan Scott >> Laurentian University >> > > > This E-mail contains privileged and confidential information intended > only for the individual or entity named in the message. If the reader > of this message is not the intended recipient, or the agent responsible > to deliver it to the intended recipient, you are hereby notified that > any review, dissemination, distribution or copying of this communication > is prohibited. If this communication was received in error, please > notify the sender by reply E-mail immediately, and delete and destroy > the original message. > -- Dan Scott Laurentian University
