devel/sope: make (stage-qa) now fails with DEVELOPER=yes complaining about iconv dependency

[Euan Thoms]

I'm the maintainer of devel/sope2 (required for www/sogo2).

Upon updating the port for an upstream version increment, I now get an error running "make" when DEVELOPER=yes is set in /etc/make.conf. The upstream project is in maintainence so I'm almost certain there's no changes in the upstream source requiring new dependencies. Especially not to do with iconv.

It does NOT help if I add USES+=iconv to the Makefile.

I will continue to submit the ports update patches, since I use things like "make check-plist" and "portlint -AC" always. I suspect it may fail in poudriere though.

Below is the error message after runnning "make":

gmake[2]: Leaving directory '/usr/ports/devel/sope2/work/SOPE'
====> Compressing man pages (compress-man)
===> Installing ldconfig configuration file
====> Running Q/A tests (stage-qa)
Error: /usr/local/GNUstep/Local/Library/Libraries/libNGExtensions.so.4.9.203 is linked to /usr/local/lib/libiconv.so.2 from converters/libiconv but it is not declared as a dependency
Warning: you need USES+=iconv


STEPS TO REPRODUCE:

- With an updated port tree cd to /usr/ports/deve/sope2
- Add DEVELOPER=yes to /etc/make.conf
- Run "make" command

--
Regards, Euan Thoms

_______________________________________________
freebs...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-port...@freebsd.org"

[Euan Thoms]

Bump

Can someone please confirm if they can reproduce on their ports tree.

[Walter Schwarzenfeld]

I can confirm. I got

Running Q/A tests (stage-qa)
Error:
/usr/local/GNUstep/Local/Library/Libraries/libNGExtensions.so.4.9.203 is
linked to /usr/local/lib/libiconv.so.2 from converters/libiconv but it
is not declared as a dependency
Warning: you need USES+=iconv

Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
is linked to /usr/local/lib/libssl.so.38 from security/libressl but it

is not declared as a dependency

Warning: you need USES=ssl
Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
is linked to /usr/local/lib/libcrypto.so.37 from security/libressl but

it is not declared as a dependency

Warning: you need USES=ssl


In the past this statements were only warnings. Now they appears as errors.
I see it in more than one port. Last I saw similar errors in
rubygem-passenger.

[Euan Thoms]

On Friday, July 15, 2016 01:02 SGT, Walter Schwarzenfeld <w.schwa...@utanet.at> wrote:

> I can confirm. I got
> Running Q/A tests (stage-qa)
> Error:
> /usr/local/GNUstep/Local/Library/Libraries/libNGExtensions.so.4.9.203 is
> linked to /usr/local/lib/libiconv.so.2 from converters/libiconv but it
> is not declared as a dependency
> Warning: you need USES+=iconv
> Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
> is linked to /usr/local/lib/libssl.so.38 from security/libressl but it
> is not declared as a dependency
> Warning: you need USES=ssl
> Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
> is linked to /usr/local/lib/libcrypto.so.37 from security/libressl but
> it is not declared as a dependency
> Warning: you need USES=ssl
>
>
> In the past this statements were only warnings. Now they appears as errors.
> I see it in more than one port. Last I saw similar errors in
> rubygem-passenger.

Thanks for confirming.


--
Regards, Euan Thoms

[Walter Schwarzenfeld]

I think this statements should be only warnings. Cause not all of these
statements are right and each maintianer should decide which "USES" or
"LIB_DEPENDS" are necessairely and which not.

[mokhi]

Maybe it's off topic.
But AFAIK there's also an issue about sope3 port, when MySQL57 is installed.

in brief it's:
"
# make install
...
gmake[4]: Leaving directory '/usr/ports/devel/sope3/work/SOPE/sope-ldap/NGLdap'
gmake[3]: Leaving directory '/usr/ports/devel/sope3/work/SOPE/sope-ldap'
gmake[2]: Leaving directory '/usr/ports/devel/sope3/work/SOPE'

====> Compressing man pages (compress-man)
===> Installing ldconfig configuration file

===> Installing for sope3-3.0.2
===> Checking if sope3 already installed
===> Registering installation for sope3-3.0.2
pkg-static: Unable to access file
/usr/ports/devel/sope3/work/stage/usr/local/GNUstep/Local/Library/GDLAdaptors-4.9/MySQL.gdladaptor/MySQL:
No such file or directory
pkg-static: Unable to access file
/usr/ports/devel/sope3/work/stage/usr/local/GNUstep/Local/Library/GDLAdaptors-4.9/MySQL.gdladaptor/Resources/Info-gnustep.plist:
No such file or directory
pkg-static: Unable to access file
/usr/ports/devel/sope3/work/stage/usr/local/GNUstep/Local/Library/GDLAdaptors-4.9/MySQL.gdladaptor/Resources/Version:
No such file or directory
pkg-static: Unable to access file
/usr/ports/devel/sope3/work/stage/usr/local/GNUstep/Local/Library/GDLAdaptors-4.9/MySQL.gdladaptor/stamp.make:
No such file or directory
*** Error code 74
"

Regards, Mokhi.

[Euan Thoms]

I'll look into this as soon as I can.

I did not make the v3 port initially. Someone else forked my v2 port and I asked for the maintainership back. I do run v3 in production (just for testing) alongside v2 (which I use daily). But I use postgresql. So I never even tested the mysql option. I assumed the person that made the v3 port did that, perhaps not.


--
Regards, Euan Thoms

[Euan Thoms]

On Friday, July 15, 2016 01:11 SGT, Walter Schwarzenfeld <w.schwa...@utanet.at> wrote:

> I think this statements should be only warnings. Cause not all of these
> statements are right and each maintianer should decide which "USES" or
> "LIB_DEPENDS" are necessairely and which not.

Well, I don't know enough to comment about whether it should be classed as a warning or an error. But there's definetely a bug in the ports Mk system, since adding USES+=iconv does not remove the error. I don't think I even need iconv as a dependency, it should be included lower down in the dependency tree.

[mokhi]

> I'll look into this as soon as I can

Okay :) thanks
As I'm maintainer of mysql57, someone mailed me logs of that problem,
AFAIK There's no problem for mysql56 but it happens when 57 is found
instead of 56

Thanks and regards, Mokhi.

[Martin Waschbüsch]

> Am 14.07.2016 um 23:29 schrieb Euan Thoms <eu...@potensol.com>:
>
>
> On Friday, July 15, 2016 01:11 SGT, Walter Schwarzenfeld <w.schwa...@utanet.at> wrote:
>
>> I think this statements should be only warnings. Cause not all of these
>> statements are right and each maintianer should decide which "USES" or
>> "LIB_DEPENDS" are necessairely and which not.
>
> Well, I don't know enough to comment about whether it should be classed as a warning or an error. But there's definetely a bug in the ports Mk system, since adding USES+=iconv does not remove the error. I don't think I even need iconv as a dependency, it should be included lower down in the dependency tree.

I am not sure about this. At the very least, sope-core does use iconv in its NGExtensions (e.g. NSString+Encoding.m).
Can we really assume some lower dependency package already pulls iconv in?

[Kubilay Kocak]

On 15/07/2016 5:17 PM, Martin Waschbüsch wrote:
>
>> Am 14.07.2016 um 23:29 schrieb Euan Thoms <eu...@potensol.com>:
>>
>>
>> On Friday, July 15, 2016 01:11 SGT, Walter Schwarzenfeld
>> <w.schwa...@utanet.at> wrote:
>>
>>> I think this statements should be only warnings. Cause not all
>>> of these statements are right and each maintianer should decide
>>> which "USES" or "LIB_DEPENDS" are necessairely and which not.
>>
>> Well, I don't know enough to comment about whether it should be
>> classed as a warning or an error. But there's definetely a bug in
>> the ports Mk system, since adding USES+=iconv does not remove the
>> error. I don't think I even need iconv as a dependency, it should
>> be included lower down in the dependency tree.
>
> I am not sure about this. At the very least, sope-core does use iconv
> in its NGExtensions (e.g. NSString+Encoding.m). Can we really assume
> some lower dependency package already pulls iconv in?

If something in a port links to libiconv (or anything else), then
the dependency should be registered in that port

[Walter Schwarzenfeld]

It is a bug the statement is wrong.
The error message disappiear if you add to LIB_DEPENDS
libiconv.so:converters/libiconv.

Btw.
it says

Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
is linked to /usr/local/lib/libssl.so.38 from security/libressl but it
is not declared as a dependency
Warning: you need USES=ssl
Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
is linked to /usr/local/lib/libcrypto.so.37 from security/libressl but
it is not declared as a dependency
Warning: you need USES=ssl

if I add ssl to USES
it states
you may not need USES+=ssl.

I am not happy with the "new" stage-qa messages.

[Walter Schwarzenfeld]

Also there are some ports who had USES=readline and stage-qa states You
have to add USES+=readline.
Here is also the statement wrong.

[Walter Schwarzenfeld]

=> you may not need USES+=ssl.

And this message disappeared if I set USES? ssl:libressl.

This should not needed if I had DEFAULT_VERSIONS=ssl=libressl in /etc/make.conf.
(I think only USES=ssl should be enough).

[Walter Schwarzenfeld]

USES? ssl:libressl

the question mark is a typo, should be
USES= ssl:libressl

[Matthew Seaman]

On 07/15/16 09:37, Walter Schwarzenfeld wrote:
> It is a bug the statement is wrong.
> The error message disappiear if you add to LIB_DEPENDS
> libiconv.so:converters/libiconv.
>
> Btw.
> it says
> Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
> is linked to /usr/local/lib/libssl.so.38 from security/libressl but it
> is not declared as a dependency
> Warning: you need USES=ssl
> Error: /usr/local/GNUstep/Local/Library/Libraries/libNGStreams.so.4.9.57
> is linked to /usr/local/lib/libcrypto.so.37 from security/libressl but
> it is not declared as a dependency
> Warning: you need USES=ssl
>
>
> if I add ssl to USES
> it states

> you may not need USES+=ssl.
>

> I am not happy with the "new" stage-qa messages.

I agree that this is annoying, and I wish there was some way to tell
stage-qa that the library dependencies are in fact OK.

The problem here is the heuristic used to determine whether there are
any missing library dependencies. This simply uses readelf(1) to find
out what's required by the dynamic loader for all of the binaries
included in the port. If it finds that an application 'foo' requires a
shared library libbar it will tell you 'you need USES+=bar' Much of the
time this is correct, and a handy sanity check.

However, what seems to happen fairly often is that foo only has a direct
dependency on libbaz and libbaz is what links against libbar. foo
doesn't know anything about functions and objects provided by libbar or
use any of them itself, except through the interface provided by libbaz,
so foo's dependency on libbar is entirely indirect.

In this situation I can't see why the port foo should list an explicit
dependency on libbar; the one it inherits through libbaz seems to me to
express the linkage between foo and libbar in an entirely satisfactory way.

You should only get the 'you may not need USES+=foo' message when you've
added the dependency in the ports Makefile, but none of the resulting
binaries link against libfoo. I don't see how you are getting the
results you describe there.

Cheers,

Matthew

[Euan Thoms]

On Friday, July 15, 2016 15:26 SGT, Kubilay Kocak <ko...@FreeBSD.org> wrote:

> On 15/07/2016 5:17 PM, Martin Waschbüsch wrote:
> >
> >> Am 14.07.2016 um 23:29 schrieb Euan Thoms <eu...@potensol.com>:
> >>
> >>
> >> On Friday, July 15, 2016 01:11 SGT, Walter Schwarzenfeld
> >> <w.schwa...@utanet.at> wrote:
> >>
> >>> I think this statements should be only warnings. Cause not all
> >>> of these statements are right and each maintianer should decide
> >>> which "USES" or "LIB_DEPENDS" are necessairely and which not.
> >>
> >> Well, I don't know enough to comment about whether it should be
> >> classed as a warning or an error. But there's definetely a bug in
> >> the ports Mk system, since adding USES+=iconv does not remove the
> >> error. I don't think I even need iconv as a dependency, it should
> >> be included lower down in the dependency tree.
> >
> > I am not sure about this. At the very least, sope-core does use iconv
> > in its NGExtensions (e.g. NSString+Encoding.m). Can we really assume
> > some lower dependency package already pulls iconv in?
>
> If something in a port links to libiconv (or anything else), then
> the dependency should be registered in that port
>

OK, thanks guys. I will add libiconv as a LIB_DEPENDS. But I still think there may be a bug. The make error tells me to use USES+=iconv and it doesn't work, I still get the same error about libiconv not being specified as a dependancy.

--
Regards, Euan Thoms

[Euan Thoms]

On Friday, July 15, 2016 16:43 SGT, Walter Schwarzenfeld <w.schwa...@utanet.at> wrote:

> Also there are some ports who had USES=readline and stage-qa states You
> have to add USES+=readline.
> Here is also the statement wrong.

That's interesting. When I said I did add USES+=iconv, actually I just added iconv to the existing USES= declaration. I will try USES+=iconv next time I work on the port.

[Don Lewis]

On 15 Jul, Euan Thoms wrote:
>
> On Friday, July 15, 2016 15:26 SGT, Kubilay Kocak <ko...@FreeBSD.org>
> wrote:
>
>> On 15/07/2016 5:17 PM, Martin Waschbüsch wrote:
>> >
>> >> Am 14.07.2016 um 23:29 schrieb Euan Thoms <eu...@potensol.com>:
>> >>
>> >>

>> >> On Friday, July 15, 2016 01:11 SGT, Walter Schwarzenfeld

>> >> <w.schwa...@utanet.at> wrote:
>> >>
>> >>> I think this statements should be only warnings. Cause not all
>> >>> of these statements are right and each maintianer should decide
>> >>> which "USES" or "LIB_DEPENDS" are necessairely and which not.
>> >>
>> >> Well, I don't know enough to comment about whether it should be
>> >> classed as a warning or an error. But there's definetely a bug in
>> >> the ports Mk system, since adding USES+=iconv does not remove the
>> >> error. I don't think I even need iconv as a dependency, it should
>> >> be included lower down in the dependency tree.
>> >
>> > I am not sure about this. At the very least, sope-core does use
>> > iconv in its NGExtensions (e.g. NSString+Encoding.m). Can we really
>> > assume some lower dependency package already pulls iconv in?
>>
>> If something in a port links to libiconv (or anything else), then
>> the dependency should be registered in that port
>>
>
> OK, thanks guys. I will add libiconv as a LIB_DEPENDS. But I still
> think there may be a bug. The make error tells me to use USES+=iconv
> and it doesn't work, I still get the same error about libiconv not
> being specified as a dependancy.

It looks like USES=iconv doesn't add the dependency on newer FreeBSD
versions that have basic iconv support in the base system. If you set
USES=iconv:wchar_t or USES=iconv:translit, then it will unconditionally
add the dependency.

If you don't use the WCHAR_T or //TRANSLIT extensions, it may not be
necessary to link with -liconv, but it is possible that the port does
this automatically if it finds that libiconv is installed by another
dependency.

[Don Lewis]

On 15 Jul, Euan Thoms wrote:
>

> On Friday, July 15, 2016 16:43 SGT, Walter Schwarzenfeld

> <w.schwa...@utanet.at> wrote:
>
>> Also there are some ports who had USES=readline and stage-qa states
>> You have to add USES+=readline.
>> Here is also the statement wrong.
>
> That's interesting. When I said I did add USES+=iconv, actually I just
> added iconv to the existing USES= declaration. I will try USES+=iconv
> next time I work on the port.

They should be equivalent.

[Walter Schwarzenfeld]

No, that what a missunderstood.

There are some ports have USES=readline in the Makefile.

But the warning "

/You have to add USES+=readline" appears. (the warning uses the "+", but
that was not what I meant)./

[Euan Thoms]

On Saturday, July 16, 2016 00:11 SGT, Don Lewis <truc...@FreeBSD.org> wrote:

> On 15 Jul, Euan Thoms wrote:
> >
> > On Friday, July 15, 2016 16:43 SGT, Walter Schwarzenfeld
> > <w.schwa...@utanet.at> wrote:
> >
> >> Also there are some ports who had USES=readline and stage-qa states
> >> You have to add USES+=readline.
> >> Here is also the statement wrong.
> >
> > That's interesting. When I said I did add USES+=iconv, actually I just
> > added iconv to the existing USES= declaration. I will try USES+=iconv
> > next time I work on the port.
>
> They should be equivalent.

Yes, but should and is are not the same thing.


--
Regards, Euan Thoms

[Euan Thoms]

On Saturday, July 16, 2016 00:10 SGT, Don Lewis <truc...@FreeBSD.org> wrote:

> On 15 Jul, Euan Thoms wrote:
> >

> > On Friday, July 15, 2016 15:26 SGT, Kubilay Kocak <ko...@FreeBSD.org>
> > wrote:
> >
> >> On 15/07/2016 5:17 PM, Martin Waschbüsch wrote:
> >> >
> >> >> Am 14.07.2016 um 23:29 schrieb Euan Thoms <eu...@potensol.com>:
> >> >>
> >> >>

> >> >> On Friday, July 15, 2016 01:11 SGT, Walter Schwarzenfeld

Aha, in that case perhaps ignore my last email. This starts to make more sense now. although the stage-qa error message is misleading.

Is this case, would I not be better adding a LIB_DEPENDS instead of USES=iconv.wchar_t or USES=iconv:translit? I don't even know where to find out which one I need.

A bit off tpic, but personally I prefer to just use the LIB_DEPENDS for a straight dependency. Keeping track of which macros to use can be more difficult than the time they save. I've only been porting for about a year, yet the ports system seems to be going through a lot of changes in this time. All good changes I'm sure. As a user I do find installing and upgrading easier than I did when I strated using ports about 5 years ago.

I'm just about to start working on the port again now.

[Euan Thoms]

On Friday, July 15, 2016 14:27 SGT, mokhi <mok...@gmail.com> wrote:

> > I'll look into this as soon as I can
> Okay :) thanks
> As I'm maintainer of mysql57, someone mailed me logs of that problem,
> AFAIK There's no problem for mysql56 but it happens when 57 is found
> instead of 56
>
> Thanks and regards, Mokhi.

Now that's interesting. I'm glad you mentioned that, it could save me a lot of time. Coincidentally, just going through my emails, I read a headline for BSD Magazine article about problems with MySQL 5.7 on FreeBSD, Since I still haven't got round to subscribing I can't read the article yet. I am not up on the issue, is there anywhere I can read up on the issue?

[Euan Thoms]

On Friday, July 15, 2016 14:27 SGT, mokhi <mok...@gmail.com> wrote:

> > I'll look into this as soon as I can
> Okay :) thanks
> As I'm maintainer of mysql57, someone mailed me logs of that problem,
> AFAIK There's no problem for mysql56 but it happens when 57 is found
> instead of 56
>
> Thanks and regards, Mokhi.

Mokhi, a bit off topic but I'm just installing the mysql57-client port and the mysql-boost tarball fails on the first few mirrors, and even when one works (below) it's very slow download. Hard to believe a project like MySQL has such slow mirrors. This server is located in Singapore, but the speeds should not be explained by distance or route.

ftp://ftp.fi.muni.cz/pub/mysql/Downloads/MySQL-5.7/mysql-boost-5.7.13.tar.gz

[Euan Thoms]

It seems adding "libiconv.so:converters/libiconv" to LIB_DEPENDS clears all errors and warnings. This is what I will use unless anyone can tell me why it's not recommended.

Thanks everyone involved, for your help.

[Mathieu Arnold]

+--On 12 juillet 2016 23:08:52 +0800 Euan Thoms <eu...@potensol.com> wrote:
| I'm the maintainer of devel/sope2 (required for www/sogo2).
|
| Upon updating the port for an upstream version increment, I now get an
| error running "make" when DEVELOPER=yes is set in /etc/make.conf. The
| upstream project is in maintainence so I'm almost certain there's no
| changes in the upstream source requiring new dependencies. Especially not
| to do with iconv.
|
| It does NOT help if I add USES+=iconv to the Makefile.
|
| I will continue to submit the ports update patches, since I use things
| like "make check-plist" and "portlint -AC" always. I suspect it may fail
| in poudriere though.
|
| Below is the error message after runnning "make":
|
| gmake[2]: Leaving directory '/usr/ports/devel/sope2/work/SOPE'

| ====> Compressing man pages (compress-man)
| ===> Installing ldconfig configuration file

| ====> Running Q/A tests (stage-qa)
| Error:
| /usr/local/GNUstep/Local/Library/Libraries/libNGExtensions.so.4.9.203 is
| linked to /usr/local/lib/libiconv.so.2 from converters/libiconv but it is
| not declared as a dependency Warning: you need USES+=iconv

In that case, you will need USES=iconv:port.

--
Mathieu Arnold

[Mathieu Arnold]

+--On 15 juillet 2016 11:02:23 +0200 Walter Schwarzenfeld

<w.schwa...@utanet.at> wrote:
| USES? ssl:libressl
|
| the question mark is a typo, should be
| USES= ssl:libressl

Yes, because this doesn't mean anything, there is no USES=ssl:libressl, ssl
does not take any argument.

I'll change the ssl.mk file so that it errors out if an argument is there.

--
Mathieu Arnold

[Euan Thoms]

Thanks, but if you look elsewhere in this thread, I mentioned I fixed it by just adding the LIB_DEPENDS myself (libiconv.so:converters/libiconv). In other words, I didn't use the USES macro since I don't know which variant to use (USES=iconv:wchar_t or USES=iconv:translit). If I'm still missing something, please let me know.

Reference: https://lists.freebsd.org/pipermail/freebsd-ports/2016-July/104026.html

[rinatk...@gmail.com]

суббота, 16 июля 2016 г., 3:40:19 UTC+3 пользователь Euan Thoms написал:

For mysql 5.6 I`ve got the error:

optional library not found: mysqlclient

when i debug configure process, i saw the empty variable LOCALBASE in checkLinking procedure fro mysqlclient library check.

I changed patch-configure file for direct write /usr/local instead ${LOCALBASE} and it`s work fine.