[ITP] znc 1.6.0

[ITP] znc 1.6.0

[Alexey Sokolov]

Hi!

I want to package ZNC.
Package in distros:
https://packages.gentoo.org/package/net-irc/znc
https://packages.debian.org/search?keywords=znc
http://packages.ubuntu.com/search?keywords=znc
https://admin.fedoraproject.org/pkgdb/package/znc/

Also I have several questions:
1) cygport chose to make znc-python to depend on both python and
python3, though I want it to depend only on python3. Is there some way
to force not to depend on python?

2) I can setup CI, so that on every push to git master new package is
pushed, marked as "test". Is it a good idea or not?


znc.cygport
------------
NAME="znc"
VERSION=1.6.0
RELEASE=1
HOMEPAGE="http://znc.in/"
SRC_URI="http://znc.in/releases/archive/znc-${VERSION}.tar.gz"
PKG_NAMES="znc znc-devel znc-perl znc-python"

znc_SUMMARY="Advanced IRC bouncer"
znc_DESCRIPTION="ZNC is an IRC network bouncer (BNC). It can detach
the client from the actual IRC server, and also from selected channels.
Multiple clients from different locations can connect to a single ZNC
account
simultaneously and therefore appear under the same nickname on IRC.
It supports SSL secured connections and IPv6."
znc_CONTENTS="usr"
znc_CATEGORY="Net"

znc_devel_SUMMARY="Modules development for ZNC"
znc_devel_DESCRIPTION="This package contains tools to build ZNC modules
written on C++."
znc_devel_CONTENTS="usr/bin/znc-buildmod usr/include usr/lib/pkgconfig"
znc_devel_CATEGORY="Net Devel"
znc_devel_REQUIRES="znc openssl-devel libicu-devel gcc-g++"

znc_perl_SUMMARY="Support for ZNC modules written on Perl"
znc_perl_DESCRIPTION="This package contains Perl bindings for ZNC."
znc_perl_CONTENTS="usr/lib/znc/modperl.so usr/lib/znc/modperl
usr/lib/znc/*.pm"
znc_perl_CATEGORY="Net Perl"

znc_python_SUMMARY="Support for ZNC modules written on Python3"
znc_python_DESCRIPTION="This package contains Python3 bindings for ZNC."
znc_python_CONTENTS="usr/lib/znc/modpython.so usr/lib/znc/modpython"
znc_python_CATEGORY="Net Python"

for exclude in $znc_devel_CONTENTS $znc_perl_CONTENTS
$znc_python_CONTENTS; do
        znc_CONTENTS="--exclude=$exclude $znc_CONTENTS"
done

# libcrypt-devel is here only because modperl refuses to compile without it
DEPEND="zlib-devel openssl-devel libcrypt-devel libsasl2-devel
libicu-devel gcc-g++ make pkg-config perl python3"
CYGCONF_ARGS="--enable-zlib --enable-openssl --enable-cyrus
--enable-charset --enable-perl --enable-python"
inherit autotools
--------

znc/setup.hint
------
category: Net
requires: cygwin libgcc1 libicu55 libopenssl100 libsasl2_3 libstdc++6 zlib0
sdesc: "Advanced IRC bouncer"
ldesc: "ZNC is an IRC network bouncer (BNC). It can detach
the client from the actual IRC server, and also from selected channels.
Multiple clients from different locations can connect to a single ZNC
account
simultaneously and therefore appear under the same nickname on IRC.
It supports SSL secured connections and IPv6."
------

znc/znc-devel/setup.hint
------
category: Net Devel
requires: bash znc openssl-devel libicu-devel gcc-g++
sdesc: "Modules development for ZNC"
ldesc: "This package contains tools to build ZNC modules written on C++."
external-source: znc
------

znc/znc-perl/setup.hint
------
category: Net Perl
requires: cygwin libgcc1 libstdc++6 perl_base znc
sdesc: "Support for ZNC modules written on Perl"
ldesc: "This package contains Perl bindings for ZNC."
external-source: znc
-------

znc/znc-python/setup.hint
------
category: Net Python
requires: cygwin libgcc1 libstdc++6 python python3 znc
sdesc: "Support for ZNC modules written on Python3"
ldesc: "This package contains Python3 bindings for ZNC."
external-source: znc
------

znc/znc-debuginfo/setup.hint
-----
category: Debug
requires: cygwin-debuginfo
external-source: znc
sdesc: "Debug info for znc"
ldesc: "This package contains files necessary for debugging the
znc package with gdb."
------

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

For some reason the mailing list swallows my messages, so I'm trying to
remove cyrillic letters for "wrote"...

19.07.2015 00:07, Alexey Sokolov :
> 18.07.2015 22:05, Alexey Sokolov :
>> I've put files in the required directory structure to
>> http://people.znc.in/~darthgandalf/znc/znc-cygwin/
>>
>> 18.07.2015 16:47, Alexey Sokolov :
>>> Hi!
>>>
>>> I want to package ZNC.
>>> Package in distros:
>>> https://packages.gentoo.org/package/net-irc/znc
>>> https://packages.debian.org/search?keywords=znc
>>> http://packages.ubuntu.com/search?keywords=znc
>>> https://admin.fedoraproject.org/pkgdb/package/znc/
>>>
>>> Also I have several questions:
>>> 1) cygport chose to make znc-python to depend on both python and
>>> python3, though I want it to depend only on python3. Is there some way
>>> to force not to depend on python?
> The answer to this is "inherit python3" (thanks jturney)
>
>
>>> 2) I can setup CI, so that on every push to git master new package is
>>> pushed, marked as "test". Is it a good idea or not?
>>>
>>>
>>> znc.cygport
>>> ------------
>>> NAME="znc"
>>> VERSION=1.6.0
>>> RELEASE=1
>>> HOMEPAGE="http://znc.in/"
>>> SRC_URI="http://znc.in/releases/archive/znc-${VERSION}.tar.gz"
>>> PKG_NAMES="znc znc-devel znc-perl znc-python"
>>>
>>> znc_SUMMARY="Advanced IRC bouncer"
>>> znc_DESCRIPTION="ZNC is an IRC network bouncer (BNC). It can detach
>>> the client from the actual IRC server, and also from selected channels.
>>> Multiple clients from different locations can connect to a single ZNC
>>> account
>>> simultaneously and therefore appear under the same nickname on IRC.
>>> It supports SSL secured connections and IPv6."
>>> znc_CONTENTS="usr"
>>> znc_CATEGORY="Net"
>>>
>>> znc_devel_SUMMARY="Modules development for ZNC"
>>> znc_devel_DESCRIPTION="This package contains tools to build ZNC modules
>>> written on C++."
>>> znc_devel_CONTENTS="usr/bin/znc-buildmod usr/include usr/lib/pkgconfig"
>>> znc_devel_CATEGORY="Net Devel"
>>> znc_devel_REQUIRES="znc openssl-devel libicu-devel gcc-g++"
>>>
>>> znc_perl_SUMMARY="Support for ZNC modules written on Perl"
>>> znc_perl_DESCRIPTION="This package contains Perl bindings for ZNC."
>>> znc_perl_CONTENTS="usr/lib/znc/modperl.so usr/lib/znc/modperl
>>> usr/lib/znc/*.pm"
>>> znc_perl_CATEGORY="Net Perl"
>>>
>>> znc_python_SUMMARY="Support for ZNC modules written on Python3"
>>> znc_python_DESCRIPTION="This package contains Python3 bindings for ZNC."
>>> znc_python_CONTENTS="usr/lib/znc/modpython.so usr/lib/znc/modpython"
>>> znc_python_CATEGORY="Net Python"
>>>
>>> for exclude in $znc_devel_CONTENTS $znc_perl_CONTENTS
>>> $znc_python_CONTENTS; do
>>>         znc_CONTENTS="--exclude=$exclude $znc_CONTENTS"
>>> done
>>>
>>> # libcrypt-devel is here only because modperl refuses to compile without it
>>> DEPEND="zlib-devel openssl-devel libcrypt-devel libsasl2-devel
>>> libicu-devel gcc-g++ make pkg-config perl python3"
>>> CYGCONF_ARGS="--enable-zlib --enable-openssl --enable-cyrus
>>> --enable-charset --enable-perl --enable-python"
>>> inherit autotools
>>> --------
>>>
>>> znc/setup.hint
>>> ------
>>> category: Net
>>> requires: cygwin libgcc1 libicu55 libopenssl100 libsasl2_3 libstdc++6 zlib0
>>> sdesc: "Advanced IRC bouncer"
>>> ldesc: "ZNC is an IRC network bouncer (BNC). It can detach
>>> the client from the actual IRC server, and also from selected channels.
>>> Multiple clients from different locations can connect to a single ZNC
>>> account
>>> simultaneously and therefore appear under the same nickname on IRC.
>>> It supports SSL secured connections and IPv6."
>>> ------
>>>
>>> znc/znc-devel/setup.hint
>>> ------
>>> category: Net Devel
>>> requires: bash znc openssl-devel libicu-devel gcc-g++
>>> sdesc: "Modules development for ZNC"
>>> ldesc: "This package contains tools to build ZNC modules written on C++."
>>> external-source: znc
>>> ------
>>>
>>> znc/znc-perl/setup.hint
>>> ------
>>> category: Net Perl
>>> requires: cygwin libgcc1 libstdc++6 perl_base znc
>>> sdesc: "Support for ZNC modules written on Perl"
>>> ldesc: "This package contains Perl bindings for ZNC."
>>> external-source: znc
>>> -------
>>>
>>> znc/znc-python/setup.hint
>>> ------
>>> category: Net Python
>>> requires: cygwin libgcc1 libstdc++6 python python3 znc
>>> sdesc: "Support for ZNC modules written on Python3"
>>> ldesc: "This package contains Python3 bindings for ZNC."
>>> external-source: znc
>>> ------
>>>
>>> znc/znc-debuginfo/setup.hint
>>> -----
>>> category: Debug
>>> requires: cygwin-debuginfo
>>> external-source: znc
>>> sdesc: "Debug info for znc"
>>> ldesc: "This package contains files necessary for debugging the
>>> znc package with gdb."
>>> ------
>>>

Re: [ITP] znc 1.6.0

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

Hi Alexey,

On Jul 19 09:24, Alexey Sokolov wrote:
> For some reason the mailing list swallows my messages, so I'm trying to
> remove cyrillic letters for "wrote"...
> 
> 19.07.2015 00:07, Alexey Sokolov :
> > 18.07.2015 22:05, Alexey Sokolov :
> >> I've put files in the required directory structure to
> >> http://people.znc.in/~darthgandalf/znc/znc-cygwin/

Packaging looks good, except...

I think libznc.dll should be called libzncX.dll or cygzncX.dll, with X
being a version number.  If there will ever be backward-incompatible
changes in the DLL, the version number should be bumped.  Also, is there
a native Windows version of ZNC?  If so, the name libznc.dll runs danger
of DLL collision.

> >> 18.07.2015 16:47, Alexey Sokolov :
> >>> Hi!
> >>>
> >>> I want to package ZNC.
> >>> Package in distros:
> >>> https://packages.gentoo.org/package/net-irc/znc
> >>> https://packages.debian.org/search?keywords=znc
> >>> http://packages.ubuntu.com/search?keywords=znc
> >>> https://admin.fedoraproject.org/pkgdb/package/znc/
> >>>
> >>> Also I have several questions:
> >>> 1) cygport chose to make znc-python to depend on both python and
> >>> python3, though I want it to depend only on python3. Is there some way
> >>> to force not to depend on python?
> > The answer to this is "inherit python3" (thanks jturney)
> >
> >
> >>> 2) I can setup CI, so that on every push to git master new package is
> >>> pushed, marked as "test". Is it a good idea or not?

I would only do that for selected new versions, not for every push.

For uploading, please send the ssh key per
https://sourceware.org/cygwin-apps/package-upload.html


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

Hi Corinna,

19.07.2015 11:03, Corinna Vinschen :
> I think libznc.dll should be called libzncX.dll or cygzncX.dll, with X
> being a version number.  If there will ever be backward-incompatible
> changes in the DLL, the version number should be bumped.  Also, is there
> a native Windows version of ZNC?  If so, the name libznc.dll runs danger
> of DLL collision.
> 

Thanks, renamed it to cygznc-1.6.dll.
There is a native version, but it's updated not very often, and it uses
znc.dll, without "lib" prefix.

> For uploading, please send the ssh key per
> https://sourceware.org/cygwin-apps/package-upload.html
> 

Done

Re: [ITP] znc 1.6.0

[Achim Gratz]

Alexey Sokolov writes:
> Thanks, renamed it to cygznc-1.6.dll.

You seem to have misunderstood.  The name of the DLL should be something
like

cygznc1.dll

where the number indicates the API version.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

+mailing list back, sorry...
> 19.07.2015 17:42, Achim Gratz :
>> Alexey Sokolov writes:
>>> Thanks, renamed it to cygznc-1.6.dll.
>> You seem to have misunderstood.  The name of the DLL should be something
>> like
>>
>> cygznc1.dll
>>
>> where the number indicates the API version.
> Is "1" some special number which should be used?
> ZNC 1.6.0 is supposed to be ABI-compatible with ZNC 1.6.1 (when it will
> be released), so third-party modules compiled against cygznc-1.6.dll
> from 1.6.0 should work fine with cygznc-1.6.dll from 1.6.1 without
> recompilation.
> That's why I chose 1.6 as version number for the filename.
>
> Also, most of .dll files I see in /bin have "-" before the number,
> that's why I've put it here too...
>
>

Re: [ITP] znc 1.6.0

[Achim Gratz]

Alexey Sokolov writes:
>> Is "1" some special number which should be used?

Just some number that gets bumped whenever the ABI changes
(i.e. applications that link against the library would need to be
recompiled).

>> ZNC 1.6.0 is supposed to be ABI-compatible with ZNC 1.6.1 (when it will
>> be released), so third-party modules compiled against cygznc-1.6.dll
>> from 1.6.0 should work fine with cygznc-1.6.dll from 1.6.1 without
>> recompilation.

I've just looked at Debian and openSUSE and both do not have a ZNC
library?

>> That's why I chose 1.6 as version number for the filename.
>>
>> Also, most of .dll files I see in /bin have "-" before the number,
>> that's why I've put it here too...

You ahould ask Yaakov, but I seem to remember that the preferred way to
name new libraries is now without the hyphen.


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [ITP] znc 1.6.0

[Marco Atzeri]

On 7/19/2015 9:10 PM, Achim Gratz wrote:
> Alexey Sokolov writes:
>>> Is "1" some special number which should be used?
>
> Just some number that gets bumped whenever the ABI changes
> (i.e. applications that link against the library would need to be
> recompiled).
>
>>> ZNC 1.6.0 is supposed to be ABI-compatible with ZNC 1.6.1 (when it will
>>> be released), so third-party modules compiled against cygznc-1.6.dll
>>> from 1.6.0 should work fine with cygznc-1.6.dll from 1.6.1 without
>>> recompilation.
>
> I've just looked at Debian and openSUSE and both do not have a ZNC
> library?
>
>>> That's why I chose 1.6 as version number for the filename.
>>>
>>> Also, most of .dll files I see in /bin have "-" before the number,
>>> that's why I've put it here too...
>
> You ahould ask Yaakov, but I seem to remember that the preferred way to
> name new libraries is now without the hyphen.
>
>
> Achim.
>

looking at fedora package,
it seems the ABI version in not used at all in ZNC
shared libs

/usr/bin/znc
/usr/lib/systemd/system/znc.service
/usr/lib/znc/adminlog.so
/usr/lib/znc/alias.so
/usr/lib/znc/autoattach.so
/usr/lib/znc/autocycle.so
/usr/lib/znc/autoop.so

http://koji.fedoraproject.org/koji/rpminfo?rpmID=6483620

so a cygznc.dll is in line with Fedora


Regards
Marco

Re: [ITP] znc 1.6.0

[Achim Gratz]

Marco Atzeri writes:
> looking at fedora package,
> it seems the ABI version in not used at all in ZNC
> shared libs

These are modules, there is no shared ZNC library on these systems at
all.

> so a cygznc.dll is in line with Fedora

I don't see a file that would correspond to it.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

19.07.2015 20:10, Achim Gratz ГЇГЁГёГҐГІ:
> Alexey Sokolov writes:
>>> Is "1" some special number which should be used?
> 
> Just some number that gets bumped whenever the ABI changes
> (i.e. applications that link against the library would need to be
> recompiled).
> 

Well, in that case 1.6 works fine. When 1.7.0 will be released, the
filename will be changed to cygznc-1.7.dll.

>>> ZNC 1.6.0 is supposed to be ABI-compatible with ZNC 1.6.1 (when it will
>>> be released), so third-party modules compiled against cygznc-1.6.dll
>>> from 1.6.0 should work fine with cygznc-1.6.dll from 1.6.1 without
>>> recompilation.
> 
> I've just looked at Debian and openSUSE and both do not have a ZNC
> library?
> 

On Linux the whole program is in /usr/bin/znc executable, and modules
(opened via dlopen()) use symbols from it.
But it's not possible on Windows, because linker requires all used
symbols to be found at build time instead of runtime. So for Windows,
most of code needed to be moved to a DLL, which both modules and (now
small) znc.exe can link to.

>>> That's why I chose 1.6 as version number for the filename.
>>>
>>> Also, most of .dll files I see in /bin have "-" before the number,
>>> that's why I've put it here too...
> 
> You ahould ask Yaakov, but I seem to remember that the preferred way to
> name new libraries is now without the hyphen.
> 

Hm, ok...
Yaakov, what's the plan?

Re: [ITP] znc 1.6.0

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

On Jul 19 20:54, Alexey Sokolov wrote:
> 19.07.2015 20:10, Achim Gratz пишет:
> > Alexey Sokolov writes:
> >>> Is "1" some special number which should be used?
> > 
> > Just some number that gets bumped whenever the ABI changes
> > (i.e. applications that link against the library would need to be
> > recompiled).
> > 
> 
> Well, in that case 1.6 works fine. When 1.7.0 will be released, the
> filename will be changed to cygznc-1.7.dll.

No, hang on.  The reason for the version-independent number is to allow
keeping the number the same for multiple versions of the package, and
only bump it when an ABI breakage occurs.  Consider this scenario with
different versioning schemes:

  znc 1.6

  --> cygznc1.dll  or  cygznc-1.6.dll

  znc 1.7 introduces new function znc_foo.  Adding functions is no ABI
  breakage.

  --> cygznc1.dll  or  cygznc-1.6.dll

  znc 1.8 removes function znc_bar.  ABI breakage; existing modules
  using this functions wouldn't load anymore.

  --> cygznc2.dll  or  cygznc-1.8.dll

  znc 1.9 adds function znc_foobar and a new structure.  No ABI breakage.

  --> cygznc2.dll  or  cygznc-1.8.dll

  znc 2.0 changes parameters to function znc_baz.  ABI breakage since
  existing modules using this function may crash.

  --> cygznc3.dll  or  cygznc-2.0.dll

The first scheme is what most autoconf-based build systems use.
However, openssl, for instance, uses the second scheme.  Both is ok, but
in both schemes the ABI version number attached to the DLL name does not
necessarily reflect the actual version number of the base package.  Did
I explain it sufficiently?

> > You ahould ask Yaakov, but I seem to remember that the preferred way to
> > name new libraries is now without the hyphen.
> 
> Hm, ok...
> Yaakov, what's the plan?

Dunno about Yaakov, but what counts in the first place is to keep track
of the ABI change and only bump the ABI version attached to the DLL name
if a new version of the base package breaks it.  The ABI version itself
is mostly maintained by the project's build system.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

>> Well, in that case 1.6 works fine. When 1.7.0 will be released, the
>> filename will be changed to cygznc-1.7.dll.
> 
> No, hang on.  The reason for the version-independent number is to allow
> keeping the number the same for multiple versions of the package, and
> only bump it when an ABI breakage occurs.  Consider this scenario with
> different versioning schemes:
> 
>   znc 1.6
> 
>   --> cygznc1.dll  or  cygznc-1.6.dll
> 
>   znc 1.7 introduces new function znc_foo.  Adding functions is no ABI
>   breakage.
> 
>   --> cygznc1.dll  or  cygznc-1.6.dll
> 
>   znc 1.8 removes function znc_bar.  ABI breakage; existing modules
>   using this functions wouldn't load anymore.
> 
>   --> cygznc2.dll  or  cygznc-1.8.dll
> 
>   znc 1.9 adds function znc_foobar and a new structure.  No ABI breakage.
> 
>   --> cygznc2.dll  or  cygznc-1.8.dll
> 
>   znc 2.0 changes parameters to function znc_baz.  ABI breakage since
>   existing modules using this function may crash.
> 
>   --> cygznc3.dll  or  cygznc-2.0.dll
> 
> The first scheme is what most autoconf-based build systems use.
> However, openssl, for instance, uses the second scheme.  Both is ok, but
> in both schemes the ABI version number attached to the DLL name does not
> necessarily reflect the actual version number of the base package.  Did
> I explain it sufficiently?

ZNC 1.6.0
--> cygznc-1.6.dll (or cygznc1.6.dll)

ZNC 1.6.1 introduces new function znc_foo, no ABI breakage.
--> cygznc-1.6.dll

ZNC 1.6.2 introduces a new structure and a new function which uses it.
No ABI breakage.
--> cygznc-1.6.dll

ZNC 1.7.0 adds new virtual function to an existing class. Even if API
is not broken, ABI is broken.
--> cygznc-1.7.dll

ZNC 1.7.1 changes some implementation details, but doesn't break ABI.
--> cygznc-1.7.dll

ZNC 1.8.0 changes order of fields in some struct, breaks ABI.
--> cygznc-1.8.dll

Since upstream agrees to not break ABI between "patch" versions, I don't
see a reason to make the DLL name to not reflect the actual version
number. I think this scheme is also used in the package of ICU library
(except that they don't guarantee ABI compatibility for C++).

>>> You ahould ask Yaakov, but I seem to remember that the preferred way to
>>> name new libraries is now without the hyphen.
>>
>> Hm, ok...
>> Yaakov, what's the plan?
> 
> Dunno about Yaakov, but what counts in the first place is to keep track
> of the ABI change and only bump the ABI version attached to the DLL name
> if a new version of the base package breaks it.  The ABI version itself
> is mostly maintained by the project's build system.

I agree about not breaking ABI without changing the filename. This
question was not directly related to ABI, however, but is about hyphen.
For consistency with existing libraries, hyphen is needed, I think. But
if the policy for new libraries to not use hyphen, I'm fine with that too.

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

>>>> You ahould ask Yaakov, but I seem to remember that the preferred way to
>>>> name new libraries is now without the hyphen.
>>> Hm, ok...
>>> Yaakov, what's the plan?
>> Dunno about Yaakov, but what counts in the first place is to keep track
>> of the ABI change and only bump the ABI version attached to the DLL name
>> if a new version of the base package breaks it.  The ABI version itself
>> is mostly maintained by the project's build system.
> I agree about not breaking ABI without changing the filename. This
> question was not directly related to ABI, however, but is about hyphen.
> For consistency with existing libraries, hyphen is needed, I think. But
> if the policy for new libraries to not use hyphen, I'm fine with that too.

Well, hyphen doesn't harm much anyway, so I'm releasing 1.6.0 now. If
hyphen will need to be removed, I'll do it for 1.7.0.

Achim and Corinna, thanks for advices!

Re: [ITP] znc 1.6.0

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

On Jul 20 19:58, Alexey Sokolov wrote:
> >> Well, in that case 1.6 works fine. When 1.7.0 will be released, the
> >> filename will be changed to cygznc-1.7.dll.

Assuming 1.7 does not break the ABI.  The problem here is that modules
built for 1.6 won't run on 1.7, even if the ABI hasn't changed, because
these modules won't find the DLL anymore.  In this case your update
to a newer package would break self-built modules for no good reason.

That's why the libs for OpenSSL 1.0.2 are still called cygssl-1.0.0 and
cygcrypto-1.0.0, and that's why many packages maintain runtime packages
which only consist of the DLLs of a package, e.g. libreadline7,
libncurses10, etc.  That allows to keep older DLL around for a while.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

21.07.2015 08:12, Corinna Vinschen пишет:
> On Jul 20 19:58, Alexey Sokolov wrote:
>>>> Well, in that case 1.6 works fine. When 1.7.0 will be released, the
>>>> filename will be changed to cygznc-1.7.dll.
> 
> Assuming 1.7 does not break the ABI.

Git master which will eventually become 1.7.0 already has ABI-breaking
changes.

>  The problem here is that modules
> built for 1.6 won't run on 1.7, even if the ABI hasn't changed,

If it's not changed, it'll be released as 1.6.1 or 1.6.2, especially to
not force users to recompile their modules.

Re: [ITP] znc 1.6.0

[David Stacey]

On 21/07/2015 08:12, Corinna Vinschen wrote:
> On Jul 20 19:58, Alexey Sokolov wrote:
>>>> Well, in that case 1.6 works fine. When 1.7.0 will be released, the
>>>> filename will be changed to cygznc-1.7.dll.
> Assuming 1.7 does not break the ABI.  The problem here is that modules
> built for 1.6 won't run on 1.7, even if the ABI hasn't changed, because
> these modules won't find the DLL anymore.  In this case your update
> to a newer package would break self-built modules for no good reason.

I've had a busy day and I'm a little tired, so I'm probably about to 
make a fool of myself on a public mailing list. Never mind :-) Three 
points on the znc package:

   - Unless I've missed something, all this talk of DLL naming is a 
little academic at the moment, as there is no 'dll.a' file to actually 
link against.

   - Has anyone tried building this in Cygwin? I tried rebuilding the 
1.6.0-2 release, and couldn't get it to compile without hacking the 
'Makefile.in' files. Even if you generate a 'dll.a', the linker 
arguments are in the wrong order. This doesn't matter in Linux, but it 
/does/ matter in Cygwin. Does this only build if cross-compiled out of 
Fedora?

   - Forgive me for being pedantic, but who gave this a GTG? I couldn't 
find one on this thread, and yet the package is up on the mirrors.

Let's hope I've missed something really obvious - apologies for any 
late-night stupidity.

Dave.

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

> I've had a busy day and I'm a little tired, so I'm probably about to
> make a fool of myself on a public mailing list. Never mind :-) Three
> points on the znc package:
> 
>   - Unless I've missed something, all this talk of DLL naming is a
> little academic at the moment, as there is no 'dll.a' file to actually
> link against.

GCC links against .dll (or .so) fine.

>   - Has anyone tried building this in Cygwin? I tried rebuilding the
> 1.6.0-2 release, and couldn't get it to compile without hacking the
> 'Makefile.in' files. Even if you generate a 'dll.a', the linker
> arguments are in the wrong order. This doesn't matter in Linux, but it
> /does/ matter in Cygwin. Does this only build if cross-compiled out of
> Fedora?

I'm using https://github.com/znc/znc-cygwin to build it on Cygwin.

>   - Forgive me for being pedantic, but who gave this a GTG? I couldn't
> find one on this thread, and yet the package is up on the mirrors.

I thought if the package exists in popular distros, no GTG needed?

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

22.07.2015 00:32, Alexey Sokolov пишет:
>> I've had a busy day and I'm a little tired, so I'm probably about to
>> make a fool of myself on a public mailing list. Never mind :-) Three
>> points on the znc package:
>>
>>   - Unless I've missed something, all this talk of DLL naming is a
>> little academic at the moment, as there is no 'dll.a' file to actually
>> link against.
> GCC links against .dll (or .so) fine.
>
>>   - Has anyone tried building this in Cygwin? I tried rebuilding the
>> 1.6.0-2 release, and couldn't get it to compile without hacking the
>> 'Makefile.in' files. Even if you generate a 'dll.a', the linker
>> arguments are in the wrong order. This doesn't matter in Linux, but it
>> /does/ matter in Cygwin. Does this only build if cross-compiled out of
>> Fedora?
> I'm using https://github.com/znc/znc-cygwin to build it on Cygwin.

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?

>>   - Forgive me for being pedantic, but who gave this a GTG? I couldn't
>> find one on this thread, and yet the package is up on the mirrors.
> I thought if the package exists in popular distros, no GTG needed?

Re: [ITP] znc 1.6.0

[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. 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?

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.

Dave.

Re: [ITP] znc 1.6.0

[David Stacey]

On 23/07/15 00:03, David Stacey wrote:
> 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.

Sorry, that's wrong. DLL should be versioned, 'dll.a' lib file should be 
unversioned.

Dave.

[Why don't we notice these things /before/ clicking Send?]

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

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!

Re: [ITP] znc 1.6.0

[Achim Gratz]

Alexey Sokolov writes:
> 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.

It's generally frowned upon to use this from the tarball if you can't
re-produce it at the build machine.   Of course you don't need to use
the one delivered in the tarball if you can solve the first problem.

> So, for protection against possible broken autoreconfs I'll add such
> src_compile to znc.cygport.

As David said, please try to make autoreconf work or at least try to
understand why it doesn't.  If you could add a cygcheck to the build
script we might be able to see better what is and is not installed in
your case.

> 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.

Uh.  You definitely need to prune the path in Cygwin to get rid of all
the Windows nonsense.  Try setting CYGWIN_NOWINPATH as an environment
variable in Windows.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

23.07.2015 06:23, Achim Gratz ГЇГЁГёГҐГІ:
>> So, for protection against possible broken autoreconfs I'll add such
>> src_compile to znc.cygport.
> 
> As David said, please try to make autoreconf work or at least try to
> understand why it doesn't.  If you could add a cygcheck to the build
> script we might be able to see better what is and is not installed in
> your case.

cygcheck is already in the build script...
https://ci.appveyor.com/project/DarthGandalf/znc-cygwin/build/0.0.0.0.1-branch-master-build-13/job/ljcyqwn2v0im9aik/artifacts

>> 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.
> 
> Uh.  You definitely need to prune the path in Cygwin to get rid of all
> the Windows nonsense.  Try setting CYGWIN_NOWINPATH as an environment
> variable in Windows.

Yes, that makes PATH more sane, thanks.

Re: [ITP] znc 1.6.0

[Ken Brown]

On 7/22/2015 8:57 PM, Alexey Sokolov wrote:
> 23.07.2015 00:03, David Stacey :
>>      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
>>
> Hm, I'm not sure why autoreconf would do this (works for me though)

I can confirm Dave's experience.  It's strange that you don't get the 
same failure.  The error message is generated by AC_PROG_CC, which is 
redefined at the beginning of configure.ac.

Ken

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

23.07.2015 14:24, Ken Brown пишет:
> On 7/22/2015 8:57 PM, Alexey Sokolov wrote:
>> 23.07.2015 00:03, David Stacey :
>>>      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
>>>
>> Hm, I'm not sure why autoreconf would do this (works for me though)
> 
> I can confirm Dave's experience.  It's strange that you don't get the
> same failure.  The error message is generated by AC_PROG_CC, which is
> redefined at the beginning of configure.ac.
> 
> Ken

Yes, that message is generated by configure.ac in case if some included
macro uses AC_PROG_CC instead of AC_PROG_CXX. But no included macro does
that, neither configure.ac nor m4/*.
So probably it somehow got included from your system m4 macros.

configure.ac:255 is AX_PTHREAD, but it should come from m4/ax_pthread.m4
and it uses C++, not C.

Probably autoreconf ignores existence of m4/ directory?

David/Ken, may you pastebin (or attach) full output of ./configure,
./configure itself, and config.log? Thanks

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

23.07.2015 21:49, Alexey Sokolov пишет:
> 23.07.2015 14:24, Ken Brown пишет:
>> On 7/22/2015 8:57 PM, Alexey Sokolov wrote:
>>> 23.07.2015 00:03, David Stacey :
>>>>      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
>>>>
>>> Hm, I'm not sure why autoreconf would do this (works for me though)
>> I can confirm Dave's experience.  It's strange that you don't get the
>> same failure.  The error message is generated by AC_PROG_CC, which is
>> redefined at the beginning of configure.ac.
>>
>> Ken
> Yes, that message is generated by configure.ac in case if some included
> macro uses AC_PROG_CC instead of AC_PROG_CXX. But no included macro does
> that, neither configure.ac nor m4/*.
> So probably it somehow got included from your system m4 macros.
>
> configure.ac:255 is AX_PTHREAD, but it should come from m4/ax_pthread.m4
> and it uses C++, not C.
>
> Probably autoreconf ignores existence of m4/ directory?
>
> David/Ken, may you pastebin (or attach) full output of ./configure,
> ./configure itself, and config.log? Thanks

If you add ACLOCAL_FLAGS="-I m4" to znc.cygport, does it fix for you?

Re: [ITP] znc 1.6.0

[Ken Brown]

On 7/23/2015 5:04 PM, Alexey Sokolov wrote:
> 23.07.2015 21:49, Alexey Sokolov пишет:
>> 23.07.2015 14:24, Ken Brown пишет:
>>> On 7/22/2015 8:57 PM, Alexey Sokolov wrote:
>>>> 23.07.2015 00:03, David Stacey :
>>>>>       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
>>>>>
>>>> Hm, I'm not sure why autoreconf would do this (works for me though)
>>> I can confirm Dave's experience.  It's strange that you don't get the
>>> same failure.  The error message is generated by AC_PROG_CC, which is
>>> redefined at the beginning of configure.ac.
>>>
>>> Ken
>> Yes, that message is generated by configure.ac in case if some included
>> macro uses AC_PROG_CC instead of AC_PROG_CXX. But no included macro does
>> that, neither configure.ac nor m4/*.
>> So probably it somehow got included from your system m4 macros.
>>
>> configure.ac:255 is AX_PTHREAD, but it should come from m4/ax_pthread.m4
>> and it uses C++, not C.
>>
>> Probably autoreconf ignores existence of m4/ directory?
>>
>> David/Ken, may you pastebin (or attach) full output of ./configure,
>> ./configure itself, and config.log? Thanks
>
> If you add ACLOCAL_FLAGS="-I m4" to znc.cygport, does it fix for you?

Yes.  So why didn't your build require that?

Ken

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

>> If you add ACLOCAL_FLAGS="-I m4" to znc.cygport, does it fix for you?
> 
> Yes.  So why didn't your build require that?

I have a hypothesis, but can't prove it without digging autotools sources.

My guess is that you have AX_PTHREAD installed in /usr/share/aclocal (or
in some other directory which is considered by default), and with bigger
#serial than what local m4/ax_pthread.m4 has (17). That's why it doesn't
work for you. But probably aclocal still tries local m4/ directory as
last resort even if "-I m4" is not provided? That's why it could work
for me. By explicitly adding m4/ to include dirs, it looks there earlier.
But this is just a guess.

Re: [ITP] znc 1.6.0

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

On Jul 22 00:32, Alexey Sokolov wrote:
> > I've had a busy day and I'm a little tired, so I'm probably about to
> > make a fool of myself on a public mailing list. Never mind :-) Three
> > points on the znc package:
> > 
> >   - Unless I've missed something, all this talk of DLL naming is a
> > little academic at the moment, as there is no 'dll.a' file to actually
> > link against.
> 
> GCC links against .dll (or .so) fine.

Without the (non-versioned) .dll.a file in /usr/lib, using -lznc will
fail.  This should be part of the -devel package.

> >   - Has anyone tried building this in Cygwin? I tried rebuilding the
> > 1.6.0-2 release, and couldn't get it to compile without hacking the
> > 'Makefile.in' files. Even if you generate a 'dll.a', the linker
> > arguments are in the wrong order. This doesn't matter in Linux, but it
> > /does/ matter in Cygwin. Does this only build if cross-compiled out of
> > Fedora?
> 
> I'm using https://github.com/znc/znc-cygwin to build it on Cygwin.
> 
> >   - Forgive me for being pedantic, but who gave this a GTG? I couldn't
> > find one on this thread, and yet the package is up on the mirrors.
> 
> I thought if the package exists in popular distros, no GTG needed?

Uhm, no.  The *votes* are not required, the GTG is.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

22.07.2015 09:07, Corinna Vinschen:
> On Jul 22 00:32, Alexey Sokolov wrote:
>>> I've had a busy day and I'm a little tired, so I'm probably about to
>>> make a fool of myself on a public mailing list. Never mind :-) Three
>>> points on the znc package:
>>>
>>>   - Unless I've missed something, all this talk of DLL naming is a
>>> little academic at the moment, as there is no 'dll.a' file to actually
>>> link against.
>>
>> GCC links against .dll (or .so) fine.
> 
> Without the (non-versioned) .dll.a file in /usr/lib, using -lznc will
> fail.  This should be part of the -devel package.

$ g++ -O2 -std=c++11 -U__STRICT_ANSI__ -D_FORTIFY_SOURCE=2 -include
znc/zncconfig.h -L/bin -lznc-1.6 -shared -o alias.so alias.cpp

This is roughly what znc-buildmod does when one runs "znc-buildmod
alias.cpp", it's provided in the -devel package. And it works.

(I've omitted several long flags from that command line, which are
irrelevant for this discussion)

The current packaged version uses '-L"/bin"' with quotes instead, I need
to fix this.

>>>   - Has anyone tried building this in Cygwin? I tried rebuilding the
>>> 1.6.0-2 release, and couldn't get it to compile without hacking the
>>> 'Makefile.in' files. Even if you generate a 'dll.a', the linker
>>> arguments are in the wrong order. This doesn't matter in Linux, but it
>>> /does/ matter in Cygwin. Does this only build if cross-compiled out of
>>> Fedora?
>>
>> I'm using https://github.com/znc/znc-cygwin to build it on Cygwin.
>>
>>>   - Forgive me for being pedantic, but who gave this a GTG? I couldn't
>>> find one on this thread, and yet the package is up on the mirrors.
>>
>> I thought if the package exists in popular distros, no GTG needed?
> 
> Uhm, no.  The *votes* are not required, the GTG is.
> 

Oops. Sorry then!

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

>>>
>>>>   - Forgive me for being pedantic, but who gave this a GTG? I couldn't
>>>> find one on this thread, and yet the package is up on the mirrors.
>>>
>>> I thought if the package exists in popular distros, no GTG needed?
>>
>> Uhm, no.  The *votes* are not required, the GTG is.
>>
> 
> Oops. Sorry then!
> 

Hi,

Is there anything missing for GTG?
https://github.com/znc/znc-cygwin/tree/e80164ce0f463177fe8bd0c2adfce9e707495da8
is the latest version with .dll.a (I didn't push to mirrors it yet)

Re: [ITP] znc 1.6.0

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Jul 30 23:34, Alexey Sokolov wrote:
> >>>
> >>>>   - Forgive me for being pedantic, but who gave this a GTG? I couldn't
> >>>> find one on this thread, and yet the package is up on the mirrors.
> >>>
> >>> I thought if the package exists in popular distros, no GTG needed?
> >>
> >> Uhm, no.  The *votes* are not required, the GTG is.
> >>
> > 
> > Oops. Sorry then!
> > 
> 
> Hi,
> 
> Is there anything missing for GTG?
> https://github.com/znc/znc-cygwin/tree/e80164ce0f463177fe8bd0c2adfce9e707495da8
> is the latest version with .dll.a (I didn't push to mirrors it yet)

Oh sorry, I thought you already did push the packages.  Can you please
point us to wget'able package files?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

03.08.2015 08:59, Corinna Vinschen пишет:
> On Jul 30 23:34, Alexey Sokolov wrote:
>>>>>
>>>>>>   - Forgive me for being pedantic, but who gave this a GTG? I couldn't
>>>>>> find one on this thread, and yet the package is up on the mirrors.
>>>>>
>>>>> I thought if the package exists in popular distros, no GTG needed?
>>>>
>>>> Uhm, no.  The *votes* are not required, the GTG is.
>>>>
>>>
>>> Oops. Sorry then!
>>>
>>
>> Hi,
>>
>> Is there anything missing for GTG?
>> https://github.com/znc/znc-cygwin/tree/e80164ce0f463177fe8bd0c2adfce9e707495da8
>> is the latest version with .dll.a (I didn't push to mirrors it yet)
> 
> Oh sorry, I thought you already did push the packages.  Can you please
> point us to wget'able package files?
> 

I pushed some packages, but the version with .dll.a not yet.
I thought that probably I should get GTG before pushing again.

http://people.znc.in/~darthgandalf/znc/znc-cygwin/

Re: [ITP] znc 1.6.0

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

On Aug  3 10:02, Alexey Sokolov wrote:
> 03.08.2015 08:59, Corinna Vinschen пишет:
> > On Jul 30 23:34, Alexey Sokolov wrote:
> >>>>>
> >>>>>>   - Forgive me for being pedantic, but who gave this a GTG? I couldn't
> >>>>>> find one on this thread, and yet the package is up on the mirrors.
> >>>>>
> >>>>> I thought if the package exists in popular distros, no GTG needed?
> >>>>
> >>>> Uhm, no.  The *votes* are not required, the GTG is.
> >>>>
> >>>
> >>> Oops. Sorry then!
> >>>
> >>
> >> Hi,
> >>
> >> Is there anything missing for GTG?
> >> https://github.com/znc/znc-cygwin/tree/e80164ce0f463177fe8bd0c2adfce9e707495da8
> >> is the latest version with .dll.a (I didn't push to mirrors it yet)
> > 
> > Oh sorry, I thought you already did push the packages.  Can you please
> > point us to wget'able package files?
> > 
> 
> I pushed some packages, but the version with .dll.a not yet.
> I thought that probably I should get GTG before pushing again.

If that's the most noticable change, please go ahead and upload.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITP] znc 1.6.0

[Alexey Sokolov]

22.07.2015 09:07, Corinna Vinschen пишет:
> On Jul 22 00:32, Alexey Sokolov wrote:
>>> I've had a busy day and I'm a little tired, so I'm probably about to
>>> make a fool of myself on a public mailing list. Never mind :-) Three
>>> points on the znc package:
>>>
>>>   - Unless I've missed something, all this talk of DLL naming is a
>>> little academic at the moment, as there is no 'dll.a' file to actually
>>> link against.
>>
>> GCC links against .dll (or .so) fine.
> 
> Without the (non-versioned) .dll.a file in /usr/lib, using -lznc will
> fail.  This should be part of the -devel package.

FTR,
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/win32.html
has a good write-up on this.