Page MenuHomeFreeBSD
Differential D22806

devel/sope4: fix libiconv
AbandonedPublic
Actions

Authored by otis on Dec 13 2019, 10:00 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 22 2024, 1:17 PM
Unknown Object (File)
Jan 2 2024, 5:06 AM
Unknown Object (File)
Dec 20 2023, 1:59 AM
Unknown Object (File)
Dec 31 2022, 10:54 PM
Unknown Object (File)
Dec 10 2022, 4:51 AM
Subscribers
bapt
lwhsu
mat
Contributor Reviewers (ports)

Details

Reviewers
None

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

otis created this revision.Dec 13 2019, 10:00 PM
Herald added subscribers: Contributor Reviewers (ports), mat. · View Herald TranscriptDec 13 2019, 10:00 PM
lwhsu added a subscriber: lwhsu.Dec 15 2019, 11:39 PM

I guess this change needs bump PORTREVISION?

bapt added a subscriber: bapt.Dec 16 2019, 8:31 AM
bapt added inline comments.
devel/sope4/Makefile
18

there is a USES to deal with iconv dependency in a precise way

otis added a comment.Dec 21 2019, 2:20 PM

The main reason is that sope4 without any zeroconf mechanisms (either avahi or mdns) does not pull in libiconv while it is still being referenced in makefiles.

poudriere log with avahi:
https://pdr1.wilbury.net/data/12_STABLE_amd64-default/2019-12-21_14h26m18s/logs/sope4-4.2.0.log

Poudriere log without avahi:
https://pdr1.wilbury.net/data/12_STABLE_amd64-default-ns2/2019-12-21_14h15m02s/logs/errors/sope4-4.2.0.log

The other possible solution would be to tweak sope-core/NGExtensions/GNUmakefile.preamble to not depend upon -liconv on FreeBSD.

devel/sope4/Makefile
18

Yes, but sope4 still refers to the external one. The other way around would be to patch the build bits to not look for -liconv or better, to find out why is it still trying to use -liconv

otis abandoned this revision.Nov 27 2020, 9:19 AM

Revision Contents
Changeset List

PathSize
devel/
sope4/
6 lines

Diff 65632

View Options

devel/sope4/Makefile

Loading...