[ITP] znc 1.6.0

Alexey Sokolov alexey+cygwin@asokolov.org
Thu Jul 23 00:58:00 GMT 2015

23.07.2015 00:03, David Stacey :
> On 22/07/2015 00:53, Alexey Sokolov wrote:
>> David, how did you try to build it? What was the exact error message?
>> What do you change in Makefile.in to get it working?
> Attempting to compile znc-1.6.0-3 with cygport under Cygwin x86. It's
> worth saying that my Cygwin installation is about a month old, but that
> shouldn't matter.
>     cygport ./znc.cygport prep compile
> Nothing out of the ordinary there. This gives the following error:
>     configure.ac:255: Something is trying to use the C compiler. Since
> this is a C++ project, this should not happen!
>     autom4te-2.69: /usr/bin/m4 failed with exit status: 1
> So, for the sake of not falling at the first hurdle, I skipped the
> autoreconf step by adding the following lines to znc.cygport:
>     src_compile() {
>       cd ${B}
>       cygconf
>       cygmake -j 1 V=1
>     }
> I'll leave it to you to have a more detailed poke around as to why
> atoreconf is failing.

Hm, I'm not sure why autoreconf would do this (works for me though), but
autoreconf is not required for ZNC anyway, as release tarballs already
have ./configure script.
So, for protection against possible broken autoreconfs I'll add such
src_compile to znc.cygport.

> Anyway, with that in place we get a little
> further. The first hint that anything is wrong comes when we try to link
> the perl module:
> /usr/lib/gcc/i686-pc-cygwin/4.9.2/../../../../i686-pc-cygwin/bin/ld:
> cannot find -lznc-1.6
> That's because there's no 'libznc-1.6.dll.a' to link against. You need
> to add the following to your link command when producing the shared DLL:
>     -Wl,--out-implib=libznc-1.6.dll.a
> Again, I'll leave it to you to get this into the Makefile in a nice way.
> I'd reiterate what others have said: This should be called libznc#.dll,
> where '#' is a number that increments when the ABI breaks. This is our
> naming convention; please adhere to it. You should add this 'dll.a' file
> to your devel package. For the sake of changing as little of your
> Makefiles as possible, I left it as libznc-1.6.dll.a.
> Building again, we don't actually get any further. When linking the perl
> module, there are a stack of linker errors:
>     modperl.o: In function `ZN10CPerlTimerD2Ev':
>     /usr/src/debug/znc-1.6.0-3/modules/modperl.cpp:277: undefined
> reference to `CTimer::GetModule() const'
> and screenfulls of similar output. This is because your arguments to the
> linker are in the wrong order. This doesn't matter on Linux, but it does
> on Cygwin. You need to put the '-lznc-1.6' after your object files. This
> gets the perl module compiling, and you'll have exactly the same
> problems with the python. I gave up at this point; I didn't attempt to
> test the binaries produced.
> The problem I have with this is that I see no way that this could ever
> have compiled under Cygwin. How are you building this?

https://github.com/znc/znc-cygwin contains all the patches and build
scripts. On push, build on AppVeyor is triggered, it spawns 2 Windows
VMs. On one VM it installs fresh Cygwin x86, and on another one it
installs fresh Cygwin x86_64.
Step by step procedure is defined in

contains logs how znc-1.6.0-3.i686 is built.
Autoreconf is not failing, modperl builds fine without libznc.dll.a and
link to cygznc-1.6.dll directly, linker has every reference defined...

I'm surprised why it's not building for you at all. ZNC has been working
in Cygwin for years, if compiled from source.
Do you have any special CXXFLAGS/LDFLAGS/CXX/etc set in your environment?
E.g. -Wl,--as-needed in LDFLAGS might cause the error about having
'-lznc-1.6' after object files, and it's not specific to Cygwin.
But I agree, order of arguments should be fixed to support --as-needed
(in upstream though)

I don't know if there are any options which would cause linker to
require .dll.a.
I can generate libznc.dll.a (or cygznc.dll.a) if you insist, of course.

Regarding libznc#.dll:
Yes, that number increments when ABI breaks (e.g. from 1.6 to 1.7).
If upstream agrees to break ABI simultaneously with changing 2 first
digits of version, why name of dll should be different from version?
cygssl-1.0.0.dll is not a single number either.

> I hope the above doesn't come across as too critical - these comments
> are intended to be constructive, and I hope you find them helpful.

Yes, thanks for the comments!

More information about the Cygwin-apps mailing list