libtool issues
I am maintainer of the science/vis5d+ port. It doesn't build on the
i386 with FreeBSD-8.0-RELEASE, as is shown here:
http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/a.8.20110223062852/vis5d+-1.2.1_15.log
I know that other ports have this problem such as science/libctl. This
port is currently marked broken for exactly this reason.
I have a work around at this PR: ports/155105. This work around was
improved in ports/155655 (see the follow up comment by the maintainer,
who submits a patch to libctl).
I also reported the problem at ports/155546, although I don't think my
solution there is very good, and my description of the bug wa very
incomplete. Furthermore, it turns out that this problem does not take
place under the FreeBSD-8.2-STABLE. This can make the problem a little
bit hard to diagnose. Nevertheless I can see this problem recurring
systematically again in the future, because libtool was not designed for
multiple compiler environments.
It would be great to find a work around. One way would be to put in
some kind of construction like ports/155105 or ports/155655 into
Mk/bsd.autotools.mk. So whenever the port has USE_LIBTOOLS set, we have
the following code
LIBTOOLS_DIR=${WRKDIR}/.libtools.dir.${PORTNAME}.${PREFIX:S/\//_/g}
${LN} -s ${LOCALBASE}/bin/${CC} ${LIBTOOLS_DIR}/cc
${LN} -s ${LOCALBASE}/bin/${CXX} ${LIBTOOLS_DIR}/c++
MAKE_ENV+= PATH=${LIBTOOLS_DIR}:$$PATH
Or one could instead modify devel/libtools, maybe something like this.
Rename bin/libtool to libexec/libtool.sh, and then rewrite the libtool
script as something like:
#!/bin/sh
PREFIX=/usr/local
TEMPCCDIR=`mktemp -d -t /tmp`
export PATH=${WRKDIR}:$PATH
${LN} -s ${LOCALBASE}/bin/${CC} ${TEMPCCDIR}/cc
${LN} -s ${LOCALBASE}/bin/${CXX} ${TEMPCCDIR}/c++
${PREFIX}/libexec/libtool.sh $@
rm -r ${TEMPCCDIR}
I know these are real hacks. But since we are trying to patch something
into libtool that it really isn't designed for, perhaps my hackish
approach has advantages. In particular, one doesn't have to redesign
different patches every time there is a libtool version update.
Just some ideas. In the meantime, do you think it is OK to commit
ports/155105 and the libctl part of ports/155655? It would be nice to
get these ports working again on the i386, at least on a temporary basis.
Thanks, Stephen
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/157868: mail/mailman: Possible problem with MAIL_GID
On 20 June 2011 10:22, Guido Falsi m...@madpilot.net wrote: On Sat, Jun 18, 2011 at 12:57:47PM +, Chris Rees wrote: Hi, I've reverted the problem commit, but I will push forward with changing the method for creating users because the state of the port at the moment is unacceptable (fiddling with base files before install phase). Please would you give the attached patch to mailman a spin, and let me know? Madpilot, this is mostly your patch! Tested the patch, it works correctly. I'm happy my fix was useful :) This patch adds the need to manually add MAIL_GID to make.conf for people using postfix integration and maybe similar options for other MTAs. Perhaps it's better to mention this in UPDATING to avoid surprises to users. Hi, Bear in mind that I reverted the MAIL_GID=nobody change for postfix after huge amounts of hatemail... I'll remove that from this patch too -- is that what you meant? Chris Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libtool issues
Dear Stephen,
Or one could instead modify devel/libtools, maybe something like this.
Rename bin/libtool to libexec/libtool.sh, and then rewrite the libtool
script as something like:
#!/bin/sh
PREFIX=/usr/local
TEMPCCDIR=`mktemp -d -t /tmp`
export PATH=${WRKDIR}:$PATH
${LN} -s ${LOCALBASE}/bin/${CC} ${TEMPCCDIR}/cc
${LN} -s ${LOCALBASE}/bin/${CXX} ${TEMPCCDIR}/c++
${PREFIX}/libexec/libtool.sh $@
rm -r ${TEMPCCDIR}
besides the obvious point that ${TMPCCDIR} should be under ${WRKDIR}, I'm
getting nervous reading ${LOCALBASE}/bin/${CC} which seems to assume that
${CC} is the name of a binary to be found in ${LOCALBASE}/bin; this might
well be if libtool is used in conjunction with USE_GCC -- but are you sure
that this will always be the case? devel/libtool does not have such a
dependency,
and if using ccache (as I do on my machines) you get something like
/usr/ports/devel/libtoolmake -V CC
/usr/local/libexec/ccache/world/cc
/usr/ports/devel/libtool
Am I missing something which makes your suggested changes to devel/libtool still
save?
Best,
Klaus
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: net/samba-libsmbclient SAMBA_PORT= - SAMBA_PORT?=
On 12 March 2011 18:18, J. Hellenthal jh...@dataix.net wrote:
In any case would you mind adding a variable to the Makefile then ?
SAMBA_PORT = ${SAMBA_LIBSMBPORT:=samba34}
Translated from sh to Mk:
.if defined (SAMBA_LIBSMBPORT)
SAMBA_PORT= ${SAMBA_LIBSMBPORT}
.else
SAMBA_PORT= samba34
.endif
Not that I think it's a good idea, but just pointing out how make
differs from sh.
Chris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libtool issues
On Mon, Jun 20, 2011 at 01:03:01AM -0500, Stephen Montgomery-Smith wrote:
I am maintainer of the science/vis5d+ port. It doesn't build on the
i386 with FreeBSD-8.0-RELEASE, as is shown here:
http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/a.8.20110223062852/vis5d+-1.2.1_15.log
I know that other ports have this problem such as science/libctl. This
port is currently marked broken for exactly this reason.
I have a work around at this PR: ports/155105. This work around was
improved in ports/155655 (see the follow up comment by the maintainer,
who submits a patch to libctl).
I also reported the problem at ports/155546, although I don't think my
solution there is very good, and my description of the bug wa very
incomplete. Furthermore, it turns out that this problem does not take
place under the FreeBSD-8.2-STABLE. This can make the problem a little
bit hard to diagnose. Nevertheless I can see this problem recurring
systematically again in the future, because libtool was not designed for
multiple compiler environments.
It would be great to find a work around. One way would be to put in
some kind of construction like ports/155105 or ports/155655 into
Mk/bsd.autotools.mk. So whenever the port has USE_LIBTOOLS set, we have
the following code
LIBTOOLS_DIR=${WRKDIR}/.libtools.dir.${PORTNAME}.${PREFIX:S/\//_/g}
${LN} -s ${LOCALBASE}/bin/${CC} ${LIBTOOLS_DIR}/cc
${LN} -s ${LOCALBASE}/bin/${CXX} ${LIBTOOLS_DIR}/c++
MAKE_ENV+= PATH=${LIBTOOLS_DIR}:$$PATH
Or one could instead modify devel/libtools, maybe something like this.
Rename bin/libtool to libexec/libtool.sh, and then rewrite the libtool
script as something like:
#!/bin/sh
PREFIX=/usr/local
TEMPCCDIR=`mktemp -d -t /tmp`
export PATH=${WRKDIR}:$PATH
${LN} -s ${LOCALBASE}/bin/${CC} ${TEMPCCDIR}/cc
${LN} -s ${LOCALBASE}/bin/${CXX} ${TEMPCCDIR}/c++
${PREFIX}/libexec/libtool.sh $@
rm -r ${TEMPCCDIR}
I know these are real hacks. But since we are trying to patch something
into libtool that it really isn't designed for, perhaps my hackish
approach has advantages. In particular, one doesn't have to redesign
different patches every time there is a libtool version update.
Just some ideas. In the meantime, do you think it is OK to commit
ports/155105 and the libctl part of ports/155655? It would be nice to
get these ports working again on the i386, at least on a temporary basis.
The libtool binding to the compiler is done for the reason. Your hack
will cause more subtle breakage, since it causes libtool to be used with
compiler with different internals. In particular, libtool overrides the
linking stage arguments, manually providing crt* objects. This is what
breaks your ports, but the hack has the same undefined consequences
there. You are just lucky that you do not see them.
Wouldn't it be easier to have per-compiler libtool port ?
devel/libtool for the base compiler, devel/libtool-gcc45 for lang/gcc45,
probably devel/libtool-clang_base for clang from base and so on.
pgpJ4CA85dymd.pgp
Description: PGP signature
Re: ports/157868: mail/mailman: Possible problem with MAIL_GID
On Mon, Jun 20, 2011 at 10:30:58AM +0100, Chris Rees wrote: On 20 June 2011 10:22, Guido Falsi m...@madpilot.net wrote: On Sat, Jun 18, 2011 at 12:57:47PM +, Chris Rees wrote: Hi, I've reverted the problem commit, but I will push forward with changing the method for creating users because the state of the port at the moment is unacceptable (fiddling with base files before install phase). Please would you give the attached patch to mailman a spin, and let me know? Madpilot, this is mostly your patch! Tested the patch, it works correctly. I'm happy my fix was useful :) This patch adds the need to manually add MAIL_GID to make.conf for people using postfix integration and maybe similar options for other MTAs. Perhaps it's better to mention this in UPDATING to avoid surprises to users. Hi, Bear in mind that I reverted the MAIL_GID=nobody change for postfix after huge amounts of hatemail... I'll remove that from this patch too -- is that what you meant? I think that's a good solution. I'm sorry for the hatemail. I hope I wasn't that rude! -- Guido Falsi m...@madpilot.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/157868: mail/mailman: Possible problem with MAIL_GID
On 20 June 2011 11:10, Guido Falsi m...@madpilot.net wrote: On Mon, Jun 20, 2011 at 10:30:58AM +0100, Chris Rees wrote: On 20 June 2011 10:22, Guido Falsi m...@madpilot.net wrote: On Sat, Jun 18, 2011 at 12:57:47PM +, Chris Rees wrote: Hi, I've reverted the problem commit, but I will push forward with changing the method for creating users because the state of the port at the moment is unacceptable (fiddling with base files before install phase). Please would you give the attached patch to mailman a spin, and let me know? Madpilot, this is mostly your patch! Tested the patch, it works correctly. I'm happy my fix was useful :) This patch adds the need to manually add MAIL_GID to make.conf for people using postfix integration and maybe similar options for other MTAs. Perhaps it's better to mention this in UPDATING to avoid surprises to users. Hi, Bear in mind that I reverted the MAIL_GID=nobody change for postfix after huge amounts of hatemail... I'll remove that from this patch too -- is that what you meant? I think that's a good solution. I'm sorry for the hatemail. I hope I wasn't that rude! No serious rudeness from anyone, and anything coming my way was fully deserved :) Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Current unassigned ports problem reports
(Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o ports/158061New ports: net-im/sofia-sip and net-im/telepathy-sofia o ports/158044Multiple net/iaxmodem instances started o ports/158036database/py-redis: [2.2.4] this port don't actually in f ports/158031[patch] security/snort to add SSL support to MySQL con o ports/158020deprecate net-p2p/gift and dependent ports o ports/158005[maintainer update] graphics/cfdg: 2.2.1 - 2.2.2 o ports/158001new port: www/p5-Apache2-SiteControl, Perl web site au o ports/157991[MAINTAINER] palm/jpilot: update to 1.8.1 o ports/157987[new port] databases/delayed_job_data_mapper o ports/157979security/py-fail2ban fails 2 ban since update of June, o ports/157949[PATCH] devel/php5-Ice: update to 3.4.2 o ports/157948[PATCH] devel/py27-Ice: update to 3.4.2 f ports/157947[PATCH] devel/Ice: update to 3.4.2 f ports/157876[patch] fix REQUIRE in net/gateway6 's rc.d script o ports/157842[NEW PORT] devel/py27-pythonbrew: Python Environment m o ports/157840[NEW PORT] net-im/py-turpial, Identi.ca and Twitter cl f ports/157807security/sshguard-ipfw fails to work with -b option o ports/157791audo/midimountain fails to copy all xpm files and fail o ports/157738New port: net/py-ldaptor o ports/157735[new port] deskutils/virt-manager: Toolkit to interact o ports/157719[new port] net-mgmt/zenpack-CheckPing: Provides nagios o ports/157715[new port] net-mgmt/zenpack-libvirt: Provides monitori f ports/157707[PATCH] update of x11-fonts/terminus-font o ports/157703New port: devel/git-annex Manage file heirarchies with o ports/157697[new port] net-mgmt/virtinst: Module to help in starti o ports/157695[new port] net-mgmt/virt-viewer: Provides a graphical o ports/157654New port: textproc/libsphinxclient C++ client library o ports/157645[maintainer update] net/bird additional patches o ports/157628[patch] www/red5 remove user data while reinstalling u o ports/157551New port: multimedia/umplayer - A modern front-end for o ports/157505[new port] net-mgmt/zenpack-DeviceSearch: Provides the o ports/157504[new port] net-mgmt/zenpack-NetApp: Provides monitorin o ports/157503[new port] net-mgmt/zenpack-InterfaceGraphs: Provides f ports/157494lang/ezm3 fails to compile o ports/157459config error with lang/guile 1.8.6_6 f ports/157458lang/guile: configure: error: libltdl not found. See o ports/157426New port: sysutils/fusefs-rar2fs Mount rar archives as o ports/157415New port: games/openssn Submarine simulator o ports/157301[New port] net-mgmt/zbxlog: Syslog server receives mes o ports/157282[MAINTAINER PATCH] net/xrdp: effective login name is n o ports/157242Updating port sysutils/swapexd for legacy compatibilit o ports/157212japanese/font-alias: use shell instead of perl for pkg o ports/157197[new port] net-mgmt/zenpack-deviceAdvDetail: Provides o ports/157196[new port] net-mgmt/zenpack-DellMon: Provides addition o ports/157194[new port] net-mgmt/zenpack-NtpMonitor: Monitors the o o ports/157191[new port] net-mgmt/zenpack-MACReport: Lists MAC addre o ports/157176[patch] sysutils/heartbeat crashes when clock_t (signe o ports/157172[NEW PORT] devel/libunistring: Unicode string library o ports/157149[MAINTAINER] databases/tuning-primer: Resolve file fet f ports/157137audio/glurp: updates to 0.12.3 o ports/157136[new port] net-mgmt/zenpack-Domain: Provides expiratio o ports/157135[new port] net-mgmt/zenpack-DellMonitor: Provides Zeno o ports/157133[new port] net-mgmt/zenpack-ApacheMonitor: Provides pe o ports/157130net-mgmt/collectd BIND plugin dependency check is inva f ports/157109conflict between net/netpipes and sysutils/timelimit f ports/157107conflict between mail/p5-Mail-SPF and mail/libspf2 o ports/157100New port: audio/umurmur - Newest version of the minima o ports/157098[PATCH] multimedia/mplayer: Add USE_NCURSES=yes o ports/157077New port: mail/sieve-connect - Command-line client for f ports/157044
UPDATING file
quote 20110620: AFFECTS: users of net/samba35 AUTHOR: ti...@freebsd.org A bug, introduced by local patch to pam_winbind.so, that made it coredump was spotted by Martin Minkus. It is fixed in the 3.5.9 version of the port. So, if pam_winbind.so strated to work for you - send him kudos. /quote Interestingly enough, while strated http://www.urbandictionary.com/define.php?term=f***strated might be apropos, I think the author meant started. -- Jerry ✌ jerry+po...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libtool issues
On 06/20/2011 04:18 AM, Klaus T. Aehlig wrote:
Dear Stephen,
Or one could instead modify devel/libtools, maybe something like this.
Rename bin/libtool to libexec/libtool.sh, and then rewrite the libtool
script as something like:
#!/bin/sh
PREFIX=/usr/local
TEMPCCDIR=`mktemp -d -t /tmp`
export PATH=${WRKDIR}:$PATH
${LN} -s ${LOCALBASE}/bin/${CC} ${TEMPCCDIR}/cc
${LN} -s ${LOCALBASE}/bin/${CXX} ${TEMPCCDIR}/c++
${PREFIX}/libexec/libtool.sh $@
rm -r ${TEMPCCDIR}
besides the obvious point that ${TMPCCDIR} should be under ${WRKDIR},
I was thinking that libtool might be used in a situation other than a
port build.
... I'm
getting nervous reading ${LOCALBASE}/bin/${CC} which seems to assume that
${CC} is the name of a binary to be found in ${LOCALBASE}/bin; this might
well be if libtool is used in conjunction with USE_GCC -- but are you sure
that this will always be the case? devel/libtool does not have such a
dependency,
and if using ccache (as I do on my machines) you get something like
/usr/ports/devel/libtoolmake -V CC
/usr/local/libexec/ccache/world/cc
/usr/ports/devel/libtool
Am I missing something which makes your suggested changes to devel/libtool still
save?
I must admit that cache is something I didn't know about (nor do I fully
understand). But I am getting the feeling that you have found an issue
that kills my second suggestion.
Stephen
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libtool issues
On 06/20/2011 04:16 AM, Kostik Belousov wrote:
On Mon, Jun 20, 2011 at 01:03:01AM -0500, Stephen Montgomery-Smith wrote:
I am maintainer of the science/vis5d+ port. It doesn't build on the
i386 with FreeBSD-8.0-RELEASE, as is shown here:
http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/a.8.20110223062852/vis5d+-1.2.1_15.log
I know that other ports have this problem such as science/libctl. This
port is currently marked broken for exactly this reason.
I have a work around at this PR: ports/155105. This work around was
improved in ports/155655 (see the follow up comment by the maintainer,
who submits a patch to libctl).
I also reported the problem at ports/155546, although I don't think my
solution there is very good, and my description of the bug wa very
incomplete. Furthermore, it turns out that this problem does not take
place under the FreeBSD-8.2-STABLE. This can make the problem a little
bit hard to diagnose. Nevertheless I can see this problem recurring
systematically again in the future, because libtool was not designed for
multiple compiler environments.
It would be great to find a work around. One way would be to put in
some kind of construction like ports/155105 or ports/155655 into
Mk/bsd.autotools.mk. So whenever the port has USE_LIBTOOLS set, we have
the following code
LIBTOOLS_DIR=${WRKDIR}/.libtools.dir.${PORTNAME}.${PREFIX:S/\//_/g}
${LN} -s ${LOCALBASE}/bin/${CC} ${LIBTOOLS_DIR}/cc
${LN} -s ${LOCALBASE}/bin/${CXX} ${LIBTOOLS_DIR}/c++
MAKE_ENV+= PATH=${LIBTOOLS_DIR}:$$PATH
Or one could instead modify devel/libtools, maybe something like this.
Rename bin/libtool to libexec/libtool.sh, and then rewrite the libtool
script as something like:
#!/bin/sh
PREFIX=/usr/local
TEMPCCDIR=`mktemp -d -t /tmp`
export PATH=${WRKDIR}:$PATH
${LN} -s ${LOCALBASE}/bin/${CC} ${TEMPCCDIR}/cc
${LN} -s ${LOCALBASE}/bin/${CXX} ${TEMPCCDIR}/c++
${PREFIX}/libexec/libtool.sh $@
rm -r ${TEMPCCDIR}
I know these are real hacks. But since we are trying to patch something
into libtool that it really isn't designed for, perhaps my hackish
approach has advantages. In particular, one doesn't have to redesign
different patches every time there is a libtool version update.
Just some ideas. In the meantime, do you think it is OK to commit
ports/155105 and the libctl part of ports/155655? It would be nice to
get these ports working again on the i386, at least on a temporary basis.
The libtool binding to the compiler is done for the reason. Your hack
will cause more subtle breakage, since it causes libtool to be used with
compiler with different internals. In particular, libtool overrides the
linking stage arguments, manually providing crt* objects. This is what
breaks your ports, but the hack has the same undefined consequences
there. You are just lucky that you do not see them.
I must admit that I am just trying things out. But based up what you
said, I think I can now see why this would be a problem.
Wouldn't it be easier to have per-compiler libtool port ?
devel/libtool for the base compiler, devel/libtool-gcc45 for lang/gcc45,
probably devel/libtool-clang_base for clang from base and so on.
That would be great if someone were willing to do the work. To be
honest, I don't fully comprehend how libtool really works, so I couldn't
do it.
Stephen
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libtool issues
On 06/20/2011 01:03 AM, Stephen Montgomery-Smith wrote:
I am maintainer of the science/vis5d+ port. It doesn't build on the
i386 with FreeBSD-8.0-RELEASE, as is shown here:
http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/a.8.20110223062852/vis5d+-1.2.1_15.log
I know that other ports have this problem such as science/libctl. This
port is currently marked broken for exactly this reason.
I have a work around at this PR: ports/155105. This work around was
improved in ports/155655 (see the follow up comment by the maintainer,
who submits a patch to libctl).
I also reported the problem at ports/155546, although I don't think my
solution there is very good, and my description of the bug wa very
incomplete. Furthermore, it turns out that this problem does not take
place under the FreeBSD-8.2-STABLE. This can make the problem a little
bit hard to diagnose. Nevertheless I can see this problem recurring
systematically again in the future, because libtool was not designed for
multiple compiler environments.
It would be great to find a work around. One way would be to put in
some kind of construction like ports/155105 or ports/155655 into
Mk/bsd.autotools.mk. So whenever the port has USE_LIBTOOLS set, we have
the following code
LIBTOOLS_DIR=${WRKDIR}/.libtools.dir.${PORTNAME}.${PREFIX:S/\//_/g}
${LN} -s ${LOCALBASE}/bin/${CC} ${LIBTOOLS_DIR}/cc
${LN} -s ${LOCALBASE}/bin/${CXX} ${LIBTOOLS_DIR}/c++
MAKE_ENV+= PATH=${LIBTOOLS_DIR}:$$PATH
Or one could instead modify devel/libtools, maybe something like this.
Rename bin/libtool to libexec/libtool.sh, and then rewrite the libtool
script as something like:
#!/bin/sh
PREFIX=/usr/local
TEMPCCDIR=`mktemp -d -t /tmp`
export PATH=${WRKDIR}:$PATH
${LN} -s ${LOCALBASE}/bin/${CC} ${TEMPCCDIR}/cc
${LN} -s ${LOCALBASE}/bin/${CXX} ${TEMPCCDIR}/c++
${PREFIX}/libexec/libtool.sh $@
rm -r ${TEMPCCDIR}
I know these are real hacks. But since we are trying to patch something
into libtool that it really isn't designed for, perhaps my hackish
approach has advantages. In particular, one doesn't have to redesign
different patches every time there is a libtool version update.
Just some ideas. In the meantime, do you think it is OK to commit
ports/155105 and the libctl part of ports/155655? It would be nice to
get these ports working again on the i386, at least on a temporary basis.
It looks like my random ideas are not good.
However, in the meantime, do you think it would be OK to remove the
broken status of the port science/libctl? It does build just fine
under i386 FreeBSD-8.2-stable.
Or maybe a better idea is to rewrite the BROKEN message:
BROKEN= Does not build with some versions of FreeBSD with i386 or
sparc64. But try make -DTRYBROKEN to see if it works for you.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[ANNOUNCE]: clang compiling ports
Hi! Flz@ just run an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A lot of these failures are trivial to fix (ie. not respecting CC setting, etc.) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us! Roman Divacky pgpFKX1RRwGhM.pgp Description: PGP signature
Re: [ANNOUNCE]: clang compiling ports
On 2011-06-20 17:37, Roman Divacky wrote: Hi! Flz@ just run an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A lot of these failures are trivial to fix (ie. not respecting CC setting, etc.) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us! Roman Divacky Would it be helpful to add a wiki page where people can annotate failed ports etc.? Much like what was done for the update to gmake... Regards -- Niclas ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
Hi, Roman. Can you specify what environment and which make options
where used? I'm somewhat confused because of log [1]: the Makefile
basically does the compiling this way:
${MAKE} PROG=lemon NOMAN=1 NO_MAN=1 \
CFLAGS=-g ${CFLAGS} \
-f /usr/share/mk/bsd.prog.mk
Since bsd.prog.mk does respect CC, and the log says that cc was
invoked, it must follow that CC is cc (or empty). What am I missing?
[1]
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/lemon-1.69.log
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On 06/20/2011 11:22 AM, Niclas Zeising wrote: On 2011-06-20 17:37, Roman Divacky wrote: Hi! Flz@ just run an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A lot of these failures are trivial to fix (ie. not respecting CC setting, etc.) and prevent a lot of other ports from building. It would be great if you could skim over the list to see if some of the ports you maintain are broken and possibly try to fix them. A small introduction into the Clang+Ports can be read at: http://wiki.freebsd.org/PortsAndClang. Please focus on the biggest offenders (ie. ports that prevent the most other ports from building). Thank you for helping us! Roman Divacky Would it be helpful to add a wiki page where people can annotate failed ports etc.? Much like what was done for the update to gmake... Regards What I would like is a primer on how to suppress all the warnings and errors created by KR code. Also, why is this an error: error: non-void function 'top_button_cross' should return a value [-Wreturn-type] when most everything else is a warning. (See http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/xppaut-5.99.log.) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On Jun 20, 2011, at 9:35 AM, Stephen Montgomery-Smith wrote: What I would like is a primer on how to suppress all the warnings and errors created by KR code. OK: http://clang.llvm.org/docs/UsersManual.html#cl_diagnostics Of course, you can only suppress warnings; you cannot suppress actual errors. clang doesn't currently support -traditional aka pure KR C. It's possible that compiling with -ansi aka -std=c89 might help-- at least you should get -Wno-implicit-function-declaration and maybe -Wno-implicit-int. Also, why is this an error: error: non-void function 'top_button_cross' should return a value [-Wreturn-type] when most everything else is a warning. (See http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/xppaut-5.99.log.) top_button_cross() probably should be declared as returning void. What's presumably happening is that it gets a default return type of int since it doesn't otherwise specify a return type, and then fails to have an explicit return, which is an error. Regards, -- -Chuck ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On 06/20/2011 12:59 PM, Chuck Swiger wrote: On Jun 20, 2011, at 9:35 AM, Stephen Montgomery-Smith wrote: What I would like is a primer on how to suppress all the warnings and errors created by KR code. OK: http://clang.llvm.org/docs/UsersManual.html#cl_diagnostics Yes, I did see that. Of course, you can only suppress warnings; you cannot suppress actual errors. clang doesn't currently support -traditional aka pure KR C. It's possible that compiling with -ansi aka -std=c89 might help-- at least you should get -Wno-implicit-function-declaration and maybe -Wno-implicit-int. Also, why is this an error: error: non-void function 'top_button_cross' should return a value [-Wreturn-type] when most everything else is a warning. (See http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/xppaut-5.99.log.) top_button_cross() probably should be declared as returning void. What's presumably happening is that it gets a default return type of int since it doesn't otherwise specify a return type, and then fails to have an explicit return, which is an error. Is a return with no value, from a function of type int, meant to be an error in KR code? If so, I will change the code so that return becomes return 0. Otherwise, I think the clang compiler should be changed so that this is a warning, not an error. Or at least an error that can be switched off with -Wno-return-type. I will say that I have no desire to put ansii patches into working KR code. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On Jun 20, 2011, at 12:09 PM, Stephen Montgomery-Smith wrote: top_button_cross() probably should be declared as returning void. What's presumably happening is that it gets a default return type of int since it doesn't otherwise specify a return type, and then fails to have an explicit return, which is an error. Is a return with no value, from a function of type int, meant to be an error in KR code? I don't believe so, but pure KR didn't require compilers to perform any sanity checking of function return types. This led to all sorts of bugs, which is why lint was invented and why ANSI-C compilers do expect function prototypes and perform function return-type checking. If so, I will change the code so that return becomes return 0. Otherwise, I think the clang compiler should be changed so that this is a warning, not an error. Or at least an error that can be switched off with -Wno-return-type. I will say that I have no desire to put ansii patches into working KR code. It sounds like you want Clang to support -traditional. It explicitly does not do so, although there is a bug filed as: http://llvm.org/bugs/show_bug.cgi?id=4557 The best course is to convert KR C code to C89/ANSI; failing that, perhaps use gcc for things which require -traditional instead of Clang (although GCC seems to be depreciating -traditional also). Regards, -- -Chuck ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On 06/20/2011 02:28 PM, Chuck Swiger wrote: On Jun 20, 2011, at 12:09 PM, Stephen Montgomery-Smith wrote: top_button_cross() probably should be declared as returning void. What's presumably happening is that it gets a default return type of int since it doesn't otherwise specify a return type, and then fails to have an explicit return, which is an error. Is a return with no value, from a function of type int, meant to be an error in KR code? I don't believe so, but pure KR didn't require compilers to perform any sanity checking of function return types. This led to all sorts of bugs, which is why lint was invented and why ANSI-C compilers do expect function prototypes and perform function return-type checking. If so, I will change the code so that return becomes return 0. Otherwise, I think the clang compiler should be changed so that this is a warning, not an error. Or at least an error that can be switched off with -Wno-return-type. I will say that I have no desire to put ansii patches into working KR code. It sounds like you want Clang to support -traditional. It explicitly does not do so, although there is a bug filed as: http://llvm.org/bugs/show_bug.cgi?id=4557 The best course is to convert KR C code to C89/ANSI; failing that, perhaps use gcc for things which require -traditional instead of Clang (although GCC seems to be depreciating -traditional also). This is someone else's code in math/xppaut. I have no desire to write extensive patches to his code. It would be a nightmare to maintain. I'll go with return 0. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
PR ports/155331
Some time ago (actually, it has been the beginning of March), I submitted a proposition to include Emacs Speaks Statistics (ESS) (http://ess.r-project.org/), which is an interface to the language/statistics package R into ports. I have also included a probably erroneous patch (was my first one). I have asked for inclusion and correction and advice on the errors I am sure I have made. (http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/155331) I have not heard of any activity since then. I would be grateful to hear whether there is any interest in having ESS in ports. Of course I myself advocate for ESS, however, there might be valid reasons for choosing not to. Anyway, I would be glad if any decision could be reached on that subject. (I do not mean to be harsh, I just have found no other wording to formulate my request in a kinder fashion. If it sounds harsh, please do not be offended.) @miwi: Please take no offence of my public posting. I have been unsuccessful reaching you off list - which I hope you have not taken as spamming. Kind regards, -- Christopher J. Ruwe TZ GMT + 2 signature.asc Description: PGP signature
Re: [ANNOUNCE]: clang compiling ports
Roman Divacky rdiva...@freebsd.org writes: Flz@ just run an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A lot of these failures are trivial to fix (ie. not respecting CC setting, etc.) and prevent a lot of other ports from building. Any extra libtool patches? I'm curious how did you work around ports/155157 foo.o: relocation R_X86_64_PC32 against symbol `bar' can not be used when making a shared object; recompile with -fPIC due to failing lt_cv_prog_compiler_pic_works check on clang warnings. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On 06/20/2011 02:44 PM, Stephen Montgomery-Smith wrote: On 06/20/2011 02:28 PM, Chuck Swiger wrote: On Jun 20, 2011, at 12:09 PM, Stephen Montgomery-Smith wrote: top_button_cross() probably should be declared as returning void. What's presumably happening is that it gets a default return type of int since it doesn't otherwise specify a return type, and then fails to have an explicit return, which is an error. Is a return with no value, from a function of type int, meant to be an error in KR code? I don't believe so, but pure KR didn't require compilers to perform any sanity checking of function return types. This led to all sorts of bugs, which is why lint was invented and why ANSI-C compilers do expect function prototypes and perform function return-type checking. If so, I will change the code so that return becomes return 0. Otherwise, I think the clang compiler should be changed so that this is a warning, not an error. Or at least an error that can be switched off with -Wno-return-type. I will say that I have no desire to put ansii patches into working KR code. It sounds like you want Clang to support -traditional. It explicitly does not do so, although there is a bug filed as: http://llvm.org/bugs/show_bug.cgi?id=4557 The best course is to convert KR C code to C89/ANSI; failing that, perhaps use gcc for things which require -traditional instead of Clang (although GCC seems to be depreciating -traditional also). This is someone else's code in math/xppaut. I have no desire to write extensive patches to his code. It would be a nightmare to maintain. I'll go with return 0. After all my fussing, I tried clang out, and -Wno-return-type kills the error message. So I am OK. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
Pan Tsu iny...@gmail.com writes: Roman Divacky rdiva...@freebsd.org writes: Flz@ just run an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A lot of these failures are trivial to fix (ie. not respecting CC setting, etc.) and prevent a lot of other ports from building. Any extra libtool patches? I'm curious how did you work around ports/155157 foo.o: relocation R_X86_64_PC32 against symbol `bar' can not be used when making a shared object; recompile with -fPIC due to failing lt_cv_prog_compiler_pic_works check on clang warnings. Looking closely at the logs it uses full path to the compiler. I tried same and the error is gone. Apparently, smth is broken on my box when clang is used together with ccache. $ /usr/bin/clang -c -fPIC -DPIC -DPIC foo.c $ CCACHE_RECACHE=1 ccache /usr/bin/clang -c -fPIC -DPIC -DPIC foo.c clang: warning: argument unused during compilation: '-D PIC' clang: warning: argument unused during compilation: '-D PIC' Sorry for the noise. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PR ports/155331
Some time ago (actually, it has been the beginning of March), I submitted a proposition to include Emacs Speaks Statistics (ESS) (http://ess.r-project.org/), which is an interface to the language/statistics package R into ports. I have also included a probably erroneous patch (was my first one). I have asked for inclusion and correction and advice on the errors I am sure I have made. (http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/155331) I have not heard of any activity since then. I would be grateful to hear whether there is any interest in having ESS in ports. Of course I myself advocate for ESS, however, there might be valid reasons for choosing not to. Anyway, I would be glad if any decision could be reached on that subject. I've been looking after R, with wen@. I didn't see your PR -- I'll take a look, and try to find out what Martin had in mind. I know that he has been busy lately (as I have). b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: UPDATING file
On Mon, Jun 20, 2011 at 1:41 PM, Jerry je...@seibercom.net wrote: quote 20110620: AFFECTS: users of net/samba35 AUTHOR: ti...@freebsd.org A bug, introduced by local patch to pam_winbind.so, that made it coredump was spotted by Martin Minkus. It is fixed in the 3.5.9 version of the port. So, if pam_winbind.so strated to work for you - send him kudos. /quote Interestingly enough, while strated http://www.urbandictionary.com/define.php?term=f***strated might be apropos, I think the author meant started. Author has sloppy fingers :) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libtool issues
On 06/20/2011 04:16 AM, Kostik Belousov wrote:
On Mon, Jun 20, 2011 at 01:03:01AM -0500, Stephen Montgomery-Smith wrote:
I am maintainer of the science/vis5d+ port. It doesn't build on the
i386 with FreeBSD-8.0-RELEASE, as is shown here:
http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/a.8.20110223062852/vis5d+-1.2.1_15.log
I know that other ports have this problem such as science/libctl. This
port is currently marked broken for exactly this reason.
I have a work around at this PR: ports/155105. This work around was
improved in ports/155655 (see the follow up comment by the maintainer,
who submits a patch to libctl).
I also reported the problem at ports/155546, although I don't think my
solution there is very good, and my description of the bug wa very
incomplete. Furthermore, it turns out that this problem does not take
place under the FreeBSD-8.2-STABLE. This can make the problem a little
bit hard to diagnose. Nevertheless I can see this problem recurring
systematically again in the future, because libtool was not designed for
multiple compiler environments.
It would be great to find a work around. One way would be to put in
some kind of construction like ports/155105 or ports/155655 into
Mk/bsd.autotools.mk. So whenever the port has USE_LIBTOOLS set, we have
the following code
LIBTOOLS_DIR=${WRKDIR}/.libtools.dir.${PORTNAME}.${PREFIX:S/\//_/g}
${LN} -s ${LOCALBASE}/bin/${CC} ${LIBTOOLS_DIR}/cc
${LN} -s ${LOCALBASE}/bin/${CXX} ${LIBTOOLS_DIR}/c++
MAKE_ENV+= PATH=${LIBTOOLS_DIR}:$$PATH
Or one could instead modify devel/libtools, maybe something like this.
Rename bin/libtool to libexec/libtool.sh, and then rewrite the libtool
script as something like:
#!/bin/sh
PREFIX=/usr/local
TEMPCCDIR=`mktemp -d -t /tmp`
export PATH=${WRKDIR}:$PATH
${LN} -s ${LOCALBASE}/bin/${CC} ${TEMPCCDIR}/cc
${LN} -s ${LOCALBASE}/bin/${CXX} ${TEMPCCDIR}/c++
${PREFIX}/libexec/libtool.sh $@
rm -r ${TEMPCCDIR}
I know these are real hacks. But since we are trying to patch something
into libtool that it really isn't designed for, perhaps my hackish
approach has advantages. In particular, one doesn't have to redesign
different patches every time there is a libtool version update.
Just some ideas. In the meantime, do you think it is OK to commit
ports/155105 and the libctl part of ports/155655? It would be nice to
get these ports working again on the i386, at least on a temporary basis.
The libtool binding to the compiler is done for the reason. Your hack
will cause more subtle breakage, since it causes libtool to be used with
compiler with different internals. In particular, libtool overrides the
linking stage arguments, manually providing crt* objects. This is what
breaks your ports, but the hack has the same undefined consequences
there. You are just lucky that you do not see them.
I must admit that I am just trying things out. But based up what you
said, I think I can now see why this would be a problem.
Wouldn't it be easier to have per-compiler libtool port ?
devel/libtool for the base compiler, devel/libtool-gcc45 for lang/gcc45,
probably devel/libtool-clang_base for clang from base and so on.
That would be great if someone were willing to do the work. To be
honest, I don't fully comprehend how libtool really works, so I couldn't
do it.
As I told you when this came up some months ago, and Kostik has noted
again, libtool caches more than just the name of the compiler -- there
are also other important bits of information that may need to be
preserved. Unless there are some changes upstream to accommodate
different toolchains at run-time, I think that making separate libtool
ports for each compiler that is widely-used in Ports is the best
solution, even though it is a nuisance to do so. Another alternative
would be to alter the autotools infrastructure so that a temporary
libtool was built for each port that needed it, using the compiler
specified for the port, as is now done by some ports that use a
bundled version of libtool, but this would somewhat prolong builds.
The main problem with either of these alternatives is to uncouple the
devel/libltdl port from libtool, because this port installs shared
libraries that may be needed after some port builds, at run-time. I
haven't looked at whether different versions of libltdl would also be
needed. If so, the patching and renaming required to point ports to
different versions of those libraries would be the main obstacle.
Here is a rough version that I use as a workaround on my system, for
gcc46. I didn't make the necessary changes to libltdl, because I
didn't need them. Also, I didn't bother to save space by unifying the
separate 'plists.
b.
bsd.autotool.mk.diff
Description: Binary data
libtool.diff
Description: Binary data
___
freebsd-ports@freebsd.org mailing list
Re: gcc-clang issue (was: cvs commit: ports/sysutils/e2fsprogs Makefile)
I'v commited this half an hour ago: mandree 2011-06-20 22:02:53 UTC FreeBSD ports repository Modified files: sysutils/e2fsprogs Makefile Log: [1] USE_GCC=4.2+, to avoid clang. Port needs -lgcc and -lgcc_s explicitly. [...] [1] is actually (a) a quick excuse and (b) based on the assumption that USE_GCC will override a clang default ports compiler. I HAVE tried clang, and got a particular kind of linker errors, namely that unrelated .o files redefine the same unrelated symbols - and a crc32.o file redefining libext2fs symbols is curious, to put it mildly. I currently suspect that there are inline handling differences between clang and gcc, combined with definitions (implementations) in .h files, and possibly either different linker behaviour with clang, or actually different symbols. Has anyone seen similar issues (duplicate symbol errors) after switching to clang? Haven't had time to check things in detail, and thought I'd commit USE_GCC right away to unwedge the build for future -exp runs. -- Matthias Andree ports committer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [ANNOUNCE]: clang compiling ports
On Mon, Jun 20, 2011 at 05:37:53PM +0200, Roman Divacky wrote: Flz@ just ran an exp-build with CC=clang and CXX=clang++. The results can be seen here: http://pointyhat.freebsd.org/errorlogs/amd64-9-exp-latest/ A permanent URL to this run is: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110616185105/ That will stick around even if we use amd64-9-exp for something else. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gcc-clang issue
On 6/21/2011 0:31 , Matthias Andree wrote: I'v commited this half an hour ago: mandree 2011-06-20 22:02:53 UTC FreeBSD ports repository Modified files: sysutils/e2fsprogs Makefile Log: [1] USE_GCC=4.2+, to avoid clang. Port needs -lgcc and -lgcc_s explicitly. [...] [1] is actually (a) a quick excuse and (b) based on the assumption that USE_GCC will override a clang default ports compiler. I HAVE tried clang, and got a particular kind of linker errors, namely that unrelated .o files redefine the same unrelated symbols - and a crc32.o file redefining libext2fs symbols is curious, to put it mildly. I currently suspect that there are inline handling differences between clang and gcc, combined with definitions (implementations) in .h files, and possibly either different linker behaviour with clang, or actually different symbols. Hey, could you try this patch? I try the USE_CSTD=gnu89 trick if I get symbol troubles when linking. This is because clang defaults to gnu99 while gcc still defaults to gnu89. From what I remember the inline keyword has different meanings between the two, or how you use it atleast. Someone explained it to my last year but I can't remember all the gory details about it. http://people.freebsd.org/~kwm/e2fsprogs-clang.diff Has anyone seen similar issues (duplicate symbol errors) after switching to clang? Haven't had time to check things in detail, and thought I'd commit USE_GCC right away to unwedge the build for future -exp runs. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: UPDATING file
On Mon, 2011-06-20 at 07:41:56 -0400, Jerry wrote: 20110620: AFFECTS: users of net/samba35 AUTHOR: ti...@freebsd.org A bug, introduced by local patch to pam_winbind.so, that made it coredump was spotted by Martin Minkus. It is fixed in the 3.5.9 version of the port. So, if pam_winbind.so strated to work for you - send him kudos. I think the author meant started. Thanks, fixed. -- Sahil Tandon sa...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PR ports/155331
Christopher, a nice tool to test your ports before submitting them is ports-mgmt/porttools: Just run `port test` and it'll run portlint and try to build you port etc. You can then submit your port with `port submit`. Read the manpage for all details. Simon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
