similar to: dovecot 2.2.31: linking error

No, I did not. I used the mainstream tar release, not the git bundle. autoreconf -vi returns error, for lack of m4 file. Sent from ProtonMail Mobile On Thu, Jun 29, 2017 at 12:51 PM, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > On 29.06.2017 13:32, Rupert Gallagher wrote: > -std=gnu99 > -mmacosx-version-min=10.12 > [...] > Undefined symbols for architecture x86_64: >

I tried compiling without "--with-storage=maildir" and it terminated without error. I need to enforce maildir, however. Sent from ProtonMail Mobile On Fri, Jun 30, 2017 at 4:26 PM, Timo Sirainen <tss at iki.fi> wrote: > On 29 Jun 2017, at 13.32, Rupert Gallagher wrote: > > -std=gnu99 > -mmacosx-version-min=10.12 > [...] > Undefined symbols for architecture

On 29.06.2017 13:32, Rupert Gallagher wrote: > -std=gnu99 > -mmacosx-version-min=10.12 > [...] > Undefined symbols for architecture x86_64: > "_imapc_client_cmd", referenced from: > _imapc_quota_refresh in quota-imapc.o > "_imapc_client_get_capabilities", referenced from: > _imapc_quota_refresh in quota-imapc.o > "_imapc_command_sendf",

On 29 Jun 2017, at 13.32, Rupert Gallagher <ruga at protonmail.com> wrote: > > -std=gnu99 > -mmacosx-version-min=10.12 > [...] > Undefined symbols for architecture x86_64: > "_imapc_client_cmd", referenced from: > _imapc_quota_refresh in quota-imapc.o > "_imapc_client_get_capabilities", referenced from: > _imapc_quota_refresh in quota-imapc.o

I would rather choose what to install. Sent from ProtonMail Mobile On Sat, Jul 1, 2017 at 1:02 PM, Sami Ketola <sami.ketola at dovecot.fi> wrote: >> On 1 Jul 2017, at 13.08, Rupert Gallagher wrote: > > I tried compiling without "--with-storage=maildir" and it terminated without error. I need to enforce maildir, however. You can enforce maildir in configuration. Sami

Hello I have 2.2.18 built with: ./configure \ --prefix="$prefix" \ --bindir="$prefix/bin" \ --sbindir="$prefix/bin" \ --sysconfdir="/etc" \ --with-storages="maildir,imapc,pop3c" \ --without-vpopmail \ --without-ldap I'm attempting to sync (backup) from another Dovecot server running version 2.0.21: Both servers

I described this off-list to Zac, but for anyone else who is following, simply specifying the target triple is not enough to have the build system set an older macOS deployment target. I.e the 6.0.0-rc1 binaries I've just uploaded have the same deployment target problem. Looking at the 5.0.0 and 6.0.0-rc1 binaries, I can confirm that their deployment target was too new: Load command 9

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

How is -mmacosx-version-min=10.9 being set? LLVM_COMPILE_FLAGS? Or CMAKE_CXX_COMPILE? > On May 2, 2018, at 19:22, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I described this off-list to Zac, but for anyone else who is following, simply specifying the target triple is not enough to have the build system set an older macOS deployment target. I.e the 6.0.0-rc1

Back in January/March of 2017, it was the case that building openssh with the latest openssl on MacOS 10.12.x (Sierra) was a bit of a bother. I could build everything with Xcode, but the resulting sshd segfaulted upon invocation (see the archives). So I built gcc 6.3 and used that to build openssh 7.x on Sierra. As long as machines stayed on 10.12.x, all was fine. Under High Sierra, the Xcode

>> Daniel's comments are also good. > > …success! Looks like I spoke a bit too soon. Everything works as far as the fat binaries are concerned, except that -mmacosx-version-min is set to the host’s OS version, not that of the SDK, causing errors when it tries to link against 10.6’s versions of libraries instead of 10.5’s. This patch appears to solve that; it uses the OS version

On Tue, Feb 5, 2013 at 12:38 PM, Kostya Serebryany <kcc at google.com> wrote: > +samsonov, glider > > > On Tue, Feb 5, 2013 at 12:16 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> On Mon, Feb 4, 2013 at 6:21 AM, Erik Verbruggen <erik.verbruggen at me.com>wrote: >> >>> Hi Chandler, >>> >>> If I remember correctly,

On Mon, Feb 4, 2013 at 6:21 AM, Erik Verbruggen <erik.verbruggen at me.com>wrote: > Hi Chandler, > > If I remember correctly, you are the de-facto maintainer for the > CMake-built-mainainer, so..: > Sure, but I'm often busy. You're better off using the development mailing list for questions such as this, and I've moved the conversation there. > I have a

On an (Intel Leopard) Mac I try to build a package (mxFinance) which depends on another package (mxGraphics). The dependendy is 1) a 'Depends:' in DESCRIPTION and 2) an import in NAMESPACE. - The build fails if the dependent package (mxGraphics) is not installed in the R.framework Do I need to have installed all packages which are required by packages to be built binary (source builds

Hi, I'm wanting to call R from Perl via the RSPerl package. However I cannot seem to install it on my Macbook (OS X Tiger - R 2.6 - Perl 5.8.6). I try to install the source downloaded from the sigmahat website - but it seems to fail - when I search my system for R.pm - I can't find it? Something looks to be going wrong with the make bits? Cheers David M ---- $ R CMD INSTALL

This may be that the libgcc_s.dylib based unwinder is incompatible with the darwin unwinder. You cannot mix and match the two. One of the lines from the bugzilla comments shows: /sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0, being used. That will not work. All of the libgcc_s.dylib functionality has been subsumed into libSystem.dylib on SnowLeopard (darwin10). The

Jack, Where do the "-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -mmacosx-version-min=10.8" flags come from? I don't see them in your CMake invocation - perhaps they're added via $CC or $CFLAGS? Is this being done on purpose? I can add a CMake step checking whether the current CFLAGS/LDFLAGS allow to build an

Nick, How exactly do you envision this being done? Looking at the contents of config/darwin.h, I see... /* Support -mmacosx-version-min by supplying different (stub) libgcc_s.dylib libraries to link against, and by not linking against libgcc_s on earlier-than-10.3.9. Note that by default, -lgcc_eh is not linked against! This is because in a future version of Darwin the EH frame

I realize this is off-topic for the list, but I thought all the darwin developers here might want to be aware of this. The current regressions in gcc trunk regarding exception handling has been escalated to a P1 in order to attract darwin developers to the issue... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260#c31 If these regressions aren't fixed before gcc 4.5's release, it appears

Please, use clang instead of gcc. Code quality can only profit from it. I just compiled 2.3.4 and compiler stderr is full of interesting problems. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20190103/83b1b813/attachment.html>