Options set: DCCD DCCGREY DCCIFD IPV6 DCCM # make stage-qa ====> Running Q/A tests (stage-qa) Warning: 'bin/cdcc' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Warning: 'bin/dccif-test' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Warning: 'bin/dccproc' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Warning: 'dcc/libexec/dns-helper' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Warning: 'dcc/libexec/ck2ip' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Warning: 'dcc/libexec/dbclean' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Warning: 'dcc/libexec/dccd' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Warning: 'dcc/libexec/dump-clients' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Warning: 'dcc/libexec/dblist' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Warning: 'dcc/libexec/dccm' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Warning: 'dcc/libexec/dccifd' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Warning: 'dcc/libexec/dccsight' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Warning: 'dcc/libexec/wlist' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Warning: 'dcc/libexec/check_ip_range' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} Error: Bad linking on [libedit.so.7] please add USES=libedit Error: Bad linking on [libedit.so.7] please add USES=libedit Error: Bad linking on [libedit.so.7] please add USES=libedit *** Error code 1 10.2-STABLE
I've tried a few things, I can't seem to make it see reason and use the ports installed libedit. Can you provide a patch ?
Created attachment 164331 [details] patch The patch fixes stage-qa, though causes some extra compile warnings. I don't think it is easy to fix that.
Created attachment 164332 [details] patch
mat@ When I made it to link with the ports libedit.so, port tests messed up the terminal, which indicates that this is the wrong libedit.so. There are several versions floating round, and these two might be incompatible.
Created attachment 164334 [details] patch Minimal patch performing these actions: * Disable libedit * Strips executables
(In reply to yuri from comment #4) Can you clarify what you mean by 'port tests messed up the terminal' when you linked with the libedit port? I'm looking into getting this working with the ports version of libedit.
When I enabled the ports version of libedit, the terminal settings were getting changed after the build or test, so that I had to run /usr/bin/reset to bring them back.
Created attachment 167457 [details] [patch] alternate method for stripping installed binaries Attached is a different method for getting the binaries stripped. It's a bit simpler and is a possible candidate for submitting upstream.
(In reply to yuri from comment #7) I narrowed it down a bit. In my xterm the following line from dcc-1.3.158/homedir/fix-map changes my baud rate (as seen by stty -a) from 38400 to 50: USING_DCC=`$CDCC_CMD info \ | sed -n -e 's/^\([-a-z0-9]*\.dcc-servers\.net\),-.*/\1/p'` CDCC_CMD is ../cdcc/cdcc. Just running '../cdcc/cdcc info' doesn't cause the problem. But piping it to something ('| cat' will do) perturbs the terminal settings as described. That seems to be enough to mess up the xterm. For example, if I 'vi' a file after that I only see the top 8 lines. 'stty speed 38400' "fixes" the issue. This is after manually replacing -ledit in Makefile.inc with /usr/local/lib/libedit.so before 'make build'. ldd ../cdcc/cdcc ../cdcc/cdcc: libmd.so.5 => /lib/libmd.so.5 (0x33c98000) libm.so.5 => /lib/libm.so.5 (0x33cb0000) libedit.so.0 => /usr/local/lib/libedit.so.0 (0x33ccb000) libncurses.so.8 => /lib/libncurses.so.8 (0x33cf9000) libc.so.7 => /lib/libc.so.7 (0x33d3a000) This doesn't trigger the issue: env LD_PRELOAD=/lib/libedit.so.7 ../cdcc/cdcc info | cat I don't have a fix or deeper analysis at the moment. But it's not clear that this edge case bug is enough to avoid the ports version of libedit or not. Seems like it might be helpful to narrow it down even a little more and possibly engage upstream maintainer of devel/libedit. But I don't know if it matters enough for deciding whether to link with it for mail/dcc-dccd. The basic line editing capability works fine when running cdcc at the command line when linked with the ports libedit.
I tracked it down. This program reproduces it: ================== % cat foo.c #include <stdio.h> #include <histedit.h> static EditLine *el_e = 0; int main(int argc, char **argv) { printf("start\n"); el_e = el_init("foo", stdin, stdout, stderr); if (el_e) el_end(el_e); else printf("el_init failed\n"); printf("end\n"); printf("end\n"); return 0; } ==================== cc foo.c /usr/local/lib/libedit.so -o foo && ./foo | cat 'stty -a' shows the baud rate at 50. If you look in the devel/libedit code, it looks like there's a case where code in el_end() tries to restore the original tty settings. But if the output is not a tty, the original tty settings were never saved. So it restores invalid termios settings. It's possible cdcc should check for isatty() on the output file descriptor and not used libedit (it currently checks for the input file descriptor). But libedit should not try to use termios settings for a structure that was never correctly populated. So that's definitely a bug in libedit. The [older] base version of libedit in freebsd just doesn't have the check for isatty() in tty_setup, so it doesn't short circuit the initialization code that populates the original termios settings structure.
upstream report for libedit bug: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50863
(In reply to John Hein from comment #11) Fix committed upstream in netbsd libedit. Now we just need the "mid-stream" portable package of libedit used by devel/libedit to sync with netbsd upstream. But I wouldn't let this minor quibble of a bug to stop anyone from getting mail/dcc-dccd to use ports' libedit rather than the base version. Or patch libedit with the upstream commit if you really want to.
Thanks for getting to the root of the problem!
I don't see any reason why this port couldn't use libedit from ports. The diff is simple: Index: Makefile =================================================================== --- Makefile (revision 410510) +++ Makefile (working copy) @@ -22,7 +22,7 @@ HAS_CONFIGURE= yes -USES= gmake tar:Z +USES= gmake libedit tar:Z OPTIONS_DEFINE= DCCIFD DCCD DCCGREY IPV6 ALT_HOME OPTIONS_DEFAULT= DCCIFD DCCM DCCD DCCGREY It compiles fine on Poudriere with 10.2-RELEASE/amd64.
Actually, PORTREVISION should also be bumped.
Piotr, Just adding USES+=libedit will not fix stage-qa, I still see a bad linking message (I checked with synth). I suggest that you make both attached patches "obsolete" and attach your own patch set that fixes it after testing with either "synth test" or "poudriere testport". From what I can tell, none of the suggested fixed attached or in the comments fully/correctly addresses the issue.
(In reply to John Marino from comment #16) Actually, the patch provided by Yuri fixes the issue (output from Poudriere): =========================================================================== ====> Running Q/A tests (stage-qa) ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist ===> Checking for items in pkg-plist which are not in STAGEDIR ===> No pkg-plist issues found (check-plist) ====>> Checking for staging violations... done =======================<phase: package >============================ ===> Building package for dcc-dccd-1.3.158_1 I think we can commit it.
(In reply to Piotr Kubaj from comment #17) Hmm, I try to set maintainer-approval+, but nothing is set and I get: Changes to attachment 164334 [details] of bug 205191 submitted Email sent to: no one It seems to be some bug in Bugzilla, anyway, I approve it.
Piotr, Yuri's patch isn't good. The first part of the patch, the stripping, is done better by John Hein's patch. The second part of the patch, is attempted to break the detection for libedit. 1) The method to this this is a complete hack, that can be done by setting CONFIGURE_ARG+= ac_cv_header_histedit_h=no 2) It removes the functionality that libedit would provide It appears your criteria for "good" is that the error message goes away, but I don't share the same opinion on the patch. I would start by changing the configure script to add -L$(prefix)/lib before -ledit and changing -ltermcap to -lncurses and I would use John's patch to fix the stripping. Let's fix the actual problem, rather than cripple this to satisfy a qa message.
actually john's patch isn't right either because it strips unconditionally which is wrong when stripping is disabled.
A commit references this bug: Author: marino Date: Mon Aug 22 14:31:40 UTC 2016 New revision: 420617 URL: https://svnweb.freebsd.org/changeset/ports/420617 Log: mail/dcc-dccd: fix stage-qa issues 1) implements stripping of executable binaries 2) disables libedit detection and linking dcc-dccd keeps trying to link to the base libedit instead of the required ports version (when USES+=libedit is added). For now, just build without until somebody finds a way get libedit linkage correct. This solves both issues seen with stage-qa PR: 205191 Reported by: Yuri (rawbw.com) Utimate fix: marino@ Approved by: maintainer (conceptually) Changes: head/mail/dcc-dccd/Makefile head/mail/dcc-dccd/files/patch-Makefile.inc2.in head/mail/dcc-dccd/files/patch-homedir_Makefile.in head/mail/dcc-dccd/files/patch-misc_Makefile.in
i tried a few times to make USES=libedit work, but I wasn't success. I only fiddled with the configure script but apparently the linking is done differently. Since it was indicated disabling libedit was desired, that's what I did (but without a patch, I just used CONFIGURE_ENV in the port makefile). The *correct* fixing of installing binaries required 3 patches. Internally it's using one install command for both scripts and executables and those have to be separated because you can't strip a script without error messages.