When I attempt to compile the zsh 4.3.11 port on CURRENT, I receive the following error: cc -c -I. -I/usr/local/include -DHAVE_CONFIG_H -O2 -fno-strict-aliasing -pipe -march=core2 -o watch.o watch.c watch.c: In function 'readwtab': watch.c:465: error: 'struct utmp' has no member named 'ut_type' watch.c: In function 'dowatch': watch.c:519: error: 'struct utmp' has no member named 'ut_type' *** Error code 1 Researching this a bit, I found that utmpx.h is a new /usr/include header introduced with FreeBSD 9. (http://svn.FreeBSD.org/viewvc/base/head/include/utmpx.h?view=log) However, as you can see in the compile output, zsh is still using struct utmp instead of struct utmpx. I believe this is caused by some configure macros in zsh which look for a utmpx / wtmpx but aren't able to find it... I'm not an expert on GNU Autoconf though: checking for utmp file... no checking for wtmp file... /var/log/wtmp checking for utmpx file... no checking for wtmpx file... no Anyway, to get back to the underlying problem.. if you look at the erroring lines in watch.c, they are pulled in due to a #define USER_PROCESS. Where is this coming from? I found it in /usr/include/utmpx.h. Zsh is including that file even when it is using utmp.h instead, due to GNU Configure defining HAVE_UTMPX_H. From zsh watch.c: #ifdef HAVE_UTMPX_H # include <utmpx.h> #endif Fix: If you comment out the utmpx.h include at the top of watch.c, it compiles. I am now using zsh as my login shell on -CURRENT. I am not sure if the 'watch' functionality actually works - I am still testing that. (I doesn't seem to be working but I need to make some changes to my shell configs to test it further.) How-To-Repeat: Attempt to install the zsh port on FreeBSD-current.
Responsible Changed From-To: freebsd-ports-bugs->bapt Over to maintainer
This appears to be fixed now. I am able to compile and use zsh.
State Changed From-To: open->closed Seems to be fixed now, thanks for the feedback, closing.
I just want to leave a note -- I was upgrading from 8-STABLE to 9.0-BETA1 on one box and hit this bug. I actually had to delete the leftover wtmp files in /var/log before it would correctly compile. Cheers, Mark
State Changed From-To: closed->open Thisis still an issue. Someone switching from utmp to utmpx either has to run make delete-old or manually patch zsh to get it to build. zsh can't deal with finding both headers on the same system. This issue should be caught prior to build.
Okay I think the reason I thought it was fixed before was this: When upgrading from a 9-series snapshot to 9-current, the problem = doesn't happen. When upgrading from a 8-series to 9-current, it does happen. I have been using 9 series snapshots so I missed it.=
bapt 2011-11-13 09:56:08 UTC FreeBSD ports repository Added files: shells/zsh/files patch-Src_watch.c Log: - Fix build for badly upgraded systems which have both utmp.h and utmpx.h PR: ports/156263 Submitted by: Matthew Cashdollar <matthew@cashdollar.org> Feature safe: yes Revision Changes Path 1.1 +15 -0 ports/shells/zsh/files/patch-Src_watch.c (new) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: open->closed Committed. Thanks!