This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [ITP] znc 1.6.0
- From: Alexey Sokolov <alexey+cygwin at asokolov dot org>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 23 Jul 2015 01:57:58 +0100
- Subject: Re: [ITP] znc 1.6.0
- Authentication-results: sourceware.org; auth=none
- References: <55AB5EC2 dot 2060400 at asokolov dot org> <20150719100317 dot GD19825 at calimero dot vinschen dot de> <55ABA522 dot 9000008 at asokolov dot org> <87d1zogku1 dot fsf at Rainer dot invalid> <55ABEC90 dot 3040106 at asokolov dot org> <55ABECDD dot 9040805 at asokolov dot org> <87zj2sezel dot fsf at Rainer dot invalid> <55AC0089 dot 2090304 at asokolov dot org> <20150720074442 dot GJ3864 at calimero dot vinschen dot de> <55AD44E9 dot 8070207 at asokolov dot org> <20150721071221 dot GZ3864 at calimero dot vinschen dot de> <55AED4D4 dot 1040403 at tiscali dot co dot uk> <55AED687 dot 8070607 at asokolov dot org> <55AEDB8E dot 6070507 at asokolov dot org> <55B0213A dot 5070005 at tiscali dot co dot uk>
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
https://github.com/znc/znc-cygwin/blob/master/appveyor.yml
https://ci.appveyor.com/project/DarthGandalf/znc-cygwin/build/0.0.0.0.1-branch-master-build-13/job/ljcyqwn2v0im9aik#L399
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!