search for: iostreams

...sage, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Component configuration: - date_time : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization...

attempting to compile dovecot 2.2.31 on Sun/Oracle Solaris 10 SPARC. configure goes fine. First sign of problems during compile is with this warning: ............................................... *** libssl_iostream_openssl.so is not portable! ............................................... actual ERRORS - Soon, compile errors out with undefined symbols. Output at bottom of note.

On Fri, 20 Oct 2017, Kadlecsik J?zsef wrote: > On Fri, 6 Oct 2017, Jozsef Kadlecsik wrote: > > > We upgraded one of our dovecot servers to debian stretch with dovecot > > 2.2.27 and since then one of our users has been experiencing random IMAP > > failures. > > > > On the client side the user runs alpine and the corresponding debug lines: > > >

Trying to build Dovecot 2.2.34 on OpenBSD fails. This seems to have been introduced by this commit.. https://github.com/dovecot/core/commit/4a9020ed888caf03fd3132a30a7818b01daa4b9d Fairly -current.. /usr/bin/libtool --tag=CC --mode=link cc -std=gnu99 -O2 -pipe -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast

Greetings! I am attempting to install Dovecot 2.2.5 on Solaris 10 Sparc hardware with openssl version 0.9.7d 17 Mar 2004. I have created a dovecot user and a dove null user, assigned them their own login directories specifying the ksh shell and assigned them to their own groups. I have run the configure command successfully and am having trouble with the make. At first, I received the problem

Hi, I came up with the following patch while trying to figure out a good solution for the situation described in Debian bug #871987[1]. In short, OpenSSL in Debian unstable has disabled TLSv1.0 and TLSv1.1 *by default*. That means that unless an application requests otherwise, only TLSv1.2 is supported. In the world of e-mail this is seemingly an issue, as there are still way too many old clients

As of LLVM 3.2, is it possible to use iostream with the MCJIT or interpreter execution engines? I'm getting some errors... Each of these commands correctly prints "hello": echo -e '#include <stdio.h>\nint main(){ printf("hello"); }' | clang -cc1 -emit-llvm-bc -x c++ | lli -use-mcjit echo -e '#include <iostream>\nint main(){ std::cout <<

Hello all, I'm trying to compile dovecot 2.2.21 on OS-X 10.11.3 and I'm running a bit of trouble with OpenSSL. I've cloned OpenSSL (OpenSSL 1.1.0-pre4-dev) from github and in openssl/ssl.h SSL_TXT_SSLV2 is not defined anymore. Compilation fails with: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib -I../../src/lib-test

In src/lib-ssl-iostream/iostream-openssl-params.c a call is made to DH_generate_parameters. This function has been deprecated since OpenSSL 0.9.8. With OpenSSL 1.1 compilation will throw an error. Not sure how to send patches, I don't even know if the patch I wrote actually works (I don't program in C, but gave it a shot anyway) but below is the patch. ---

OpenSSL 1.1 features a cleanup function that is automatically run on shutdown using atexit(3). This function frees all OpenSSL-allocated resources. In dovecot, OpenSSL is loaded indirectly using dlopen(3) against the relevant dovecot crypto module and is finally unloaded using dlclose(3). Until OpenSSL 1.0.1c this worked fine, however OpenSSL 1.0.1c makes sure[1] that the library stays loaded

Hi all, I'm trying to set up my server with support for TLS 1.3 only, but that does not seem to be supported. First off, TLS 1.3 itself does work fine, so it's not the config or ssl library, and 1.3-only works fine with Postfix. The problem is only in disabling TLS 1.2 for Dovecot. On connection, I'm getting an error that 1.3 is an "Unknown ssl_min_protocol setting". Reading

Hello, I've stumbled upon the following behavior in branches/release_35 (as of 218689) under ubuntu 14.04 LTS amd64: whenever I include the (system-wise) gnu iostream header, clang++ stops devirtualizing the following code: #if BREAKAGE_ENSUES #include <iostream> #endif struct Base { virtual int foo() const = 0; }; struct A : Base { int a; A(const int a) : a(a) { } int foo() const

Hello, We upgraded one of our dovecot servers to debian stretch with dovecot 2.2.27 and since then one of our users has been experiencing random IMAP failures. We enabled raw logging at the server side and it shows normal IMAP commands/responses: 1507292522.222427 * 6 FETCH (FLAGS () BODYSTRUCTURE ("text" "plain" ("charset" "us-ascii") NIL NIL

Hi, Consider the following file. ******************************* foo.cc ******************************* #include <R.h> #include <Rinternals.h> #include <iostream> ******************************* R CMD SHLIB foo.cc gives scads of errors. I've use C++ extensively with R before (using C linkage) but not with Rinternals.h. I'm puzzled. The errors make no sense to me. Am

Hi list I'm trying to build dovecot 2.2.15 from source on a debian wheezy (64bit). As I wanted to get starttls support for dovecot's lmtp I got the patched files from here: http://hg.dovecot.org/dovecot-2.2/rev/297192cfbd37 My ./configure ./configure --prefix=/usr/local/dovecot-test --with-solr --with-mysql --with-sql --without-shadow --without-pam configure seems to run fine but

I am sorry if this is not the correct list for asking this. T try to build dovecot 2.3.20 from source on a QNAP NAS, which is a linux variant. There is an dovecot available, but this does not include a pigeonhole sieve, that?s why I try to build it from source. The configure script works fine, but the make fails as follows: *** Warning: Linking the executable test-http-payload against the

...o handle the >>> extremely >>> unlikely case of a static object constructor writing to one of the >>> standard streams. >> >> I also dislike this strongly, but it isn't really related. > > Isn't this the motivation behind "#include <iostreams> is hereby > FORBIDDEN?" Yes it is. As I said, I don't like this aspect of the standard streams, but it isn't very related to this problem. >>> 2. Slowness of std::cout and friends due to their reliance on FILE * >>> buffering and resulting excessive...

Hi, This patch: On 15/11/2016 10:46 PM, Aki Tuomi wrote: > > > On 13.11.2016 20:04, Apollon Oikonomopoulos wrote: >> OpenSSL 1.1 features a cleanup function that is automatically run on shutdown >> using atexit(3). This function frees all OpenSSL-allocated resources. >> >> In dovecot, OpenSSL is loaded indirectly using dlopen(3) against the relevant >>

Hi all, With the newest patches to LLVM, there should be no reason for having "#include <iostream>" in any library source code file, except for lib/ Support/Streams.cpp. Please use the following instead: OLD NEW --- --- std::ostream llvm::OStream std::istream llvm::IStream std::cerr llvm::cerr std::cerr llvm::cout

Asterisk Project Security Advisory - AST-2018-007 Product Asterisk Summary Infinite loop when reading iostreams Nature of Advisory Denial of Service Susceptibility Remote Authenticated Sessions Severity Critical Exploits Known No...