similar to: Unresolved variable in `libupsclient-config'

Dear Stanislav, thanks for your patch. The problem with your "recommended" pkgconfigdir is that in many cases, it does not work. Namely, when ${prefix} is not one of the standard places such as /usr. As I understand it, the whole point of a tool like pkgconfig is to allow other software to automatically detect the install location of NUT, especially when that location is not one of

Peter, Any objections to adding this to the trunk? When I run 'ldd upsc' without this patch, it lists the OpenSSL libraries, and the default ./configure setting is to not use OpenSSL. - Charles > Log: > If we are not using SSL_CFLAGS or SSL_LDFLAGS, do not add the OpenSSL libraries > to all of the binaries. > > > Modified: branches/deb_fixes_for_trunk/configure.in >

Hi, when building with the WITH_DEV conditional, either `libupsclient.pc' *or* `libupsclient-config' is installed. This is annoying when linking with libupsclient, because you basically have to do the check twice, once using `pkg-config' and once using `libupsclient-config'. Please consider the attached patch, which changes the behavior of `lib/Makefile.am' to install

Hi, Made a test build of the Testing branch. The problem is that upsmon and upsc is not respecting the revision change of libupsclient.so. It is now libupsclient.so.1, but i get this. /usr/sbin/upsmon: error while loading shared libraries: libupsclient.so.0: cannot open shared object file: No such file or directory and: upsc: error while loading shared libraries: libupsclient.so.0: cannot

Hello together, after upgrading from nut 2.2.1 to nut 2.2.2, I noticed there's a (new?) libupsclient.so library. On my Redhat based system, f.e. the "upsc" binary links against it and is unhappy as the library is not included in the current RPM file. If you look at the .spec file for Redhat, the libupsclient.* stuff is included in the "nut-devel" package only. The SuSE

tags 439986 upstream thanks Hi Florian, 2007/8/29, Florian Forster <octo at verplant.org>: > Package: nut-dev > Version: 2.2.0-1 > Severity: minor > > After upgrading from version 2.0.something to version 2.2.0-1 the type > `UPSCONN' had been renamed to `UPSCONN_t'. This is a problem for > software that is supposed to work with different versions of this >

Stan, I'm very pleased to see you back to work with us on enhancing nut in that many areas ;-) 2008/4/30 Stanislav Brabec <sbrabec at suse.cz>: > Stanislav Brabec wrote: > > > Please note that 2.2.2-pre3 installs hald addons by default to / on > > openSUSE 11.0 beta 2 x86_64. Not a big problem. > > Here is a patch, which fixes openSUSE 11.0 beta 2 x86_64:

When starting Dovecot 1.0.15 after building it from source using the standard procedure, I receive the following message when starting, even though SLL_DISABLE=No: Error: SSL support not compiled in but ssl_disable=no Fatal: Invalid configuration in /usr/local/etc/dovecot.conf How is SSL support configured and built in? I know it has something to do with the --SSL_CFLAGS flag.

Hello Dovecot users! There seems to be a new dependency in some modules (eg, lib-storage, libdovecot-lda, libdovecot-ssl) on OpenSSL. In Dovecot 2.0, those modules didn't require OpenSSL, but 2.1 does. For the linking process the path to the OpenSSL library isn't specified properly (SSL_LIBS). Dovecot fails to build if OpenSSL is in a non-standard path. (Haven't checked if SSL_CFLAGS

Hi, Below is a log of what I did. In summary, I think the problem lies in that I can't build libupsclient: e.g. make[1]: *** No rule to make target `libupsclient.la', needed by `upsc'. Stop. I'm not very familiar with autoconf, aclocal, automake, I tried hacking it a bit, but couldn't get it to fix the errors... Thanks, Edwin $ svn update At revision 845. $ autoreconf

Hi, I am running into a interesting issue with Dovecot. I compiled Dovecot 2.0.7 with LD_RUN_PATH set to /xsys/lib and it was able to find and link against the correct OpenSSL libraries (/xsys/lib), the generated Makefile look OK. Here is a snippet of the SSL cflags and libs. SSL_CFLAGS = -I/xsys/include SSL_LIBS = -L/xsys/lib -lssl -lcrypto -ldl After I compil, install and run Dovecot I

Dear Dovecot developers! This problem already existed some years ago, has been fixed, and now it's there again in Dovecot 2.2.25 (2.2.24 was fine). I'm running CentOS 6 with a custom OpenSSL installation in /usr/local/ssl Therefore, Dovecot is configured like this: env SSL_CFLAGS="-I/usr/local/ssl/include" SSL_LIBS="-L/usr/local/ssl/lib -Wl,-R/usr/local/ssl/lib -lcrypto

I would also check where the "... is not portable!" messaage is generated. If it's done by the configure script, you can look at the test to give you a hint as to why this message was generated. For my setup, I did much the same as you but didn't have to set the SSL_CFLAGS, SSL_LIBS environment variables, nor did I set the --with-ssldir configure option (although your setup may

I'm having an issue with Thunderbird (and Opera) and Dovecot SSL on a Solaris 10. My OS is Solaris 10 6/06 x86 (running in 64-bit mode) using ZFS (disk mirror) as the filesystem for my users. Dovecot version is 1.0rc7 (logs below are from 1.0rc6). First the connection asks if the SSL-certificate should be accepted, accepting it seems to work but then nothing happens. Thunderbird is

Hello, I tried to compile Dovecot 2.2.5 on Debian 6 with an alternate OpenSSL installation located at /usr/local/ssl A compilation with CPPFLAGS="-I/usr/local/ssl/include" \ LDFLAGS="-L/usr/local/ssl/lib -Wl,-rpath=/usr/local/ssl/lib" \ SSL_LIBS="-L/usr/local/ssl/lib -Wl,-rpath=/usr/local/ssl/lib" \ ./configure \ --prefix=/opt/dovecot-2.2.5 \ --enable-asserts \

Home again. Fixed SSL checking for Redhat 9, I hope. Could someone test if it actually works now? Also fixed a few compiler warnings. If this thing works, I'll just update the NEWS file and call it 0.99.10. http://dovecot.procontrol.fi/rc/ Near future plans include rewriting parts of index handling. At least .tree file will go, I've a _much_ better idea how to replace it. .data file is

I upgraded an operating system to openSUSE 42.2, kernel 4.4 and recompiled nut 2.7.4. ./configure, make clean and make went well, but make install failed. Make reports Making install in clients make[1]: Entering directory '/mnt/home/rprice/nut/nut-2.7.4.dev/clients' make[2]: Entering directory '/mnt/home/rprice/nut/nut-2.7.4.dev/clients' /usr/bin/mkdir -p '/usr/lib64'

Hi, Thanks for help. - I download the last version of NUT, 2.7.2.6 - I install library: nss-devel gcc-c++ So now I didn't get last errors on make. But I get a new one when I try to do - make install --------------------------- *[root at artesano nut-2.7.2.6]# make install* Making install in include make[1]: Entering directory `/home/artesano/Downloads/nut-2.7.2.6/include'

Hi Charles, I try to do from a new clean installations after reset my server (some changes need it), and now the make install seems to works. Now i going to configure and test it. I attached the logs files from the last run. If i have any other problem I write to the list. Thanks a lot for your help. Have a good day. 2015-02-13 17:45 GMT-06:00 Charles Lepple <clepple at gmail.com>: >

Hi Charles, I forgot add attaches.[?] I try to do from a new clean installations after reset my server (some changes need it), and now the make install seems to works. Now i going to configure and test it. I attached the logs files from the last run. If i have any other problem I write to the list. Thanks a lot for your help. Have a good day. 2015-02-13 17:45 GMT-06:00 Charles Lepple