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"
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 ___ 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: [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 (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: 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.
Re: "UPDATING" file
On Mon, Jun 20, 2011 at 1:41 PM, 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. > > > 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: 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: [ANNOUNCE]: clang compiling ports
Pan Tsu writes: > Roman Divacky 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: [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 K&R code? I don't believe so, but pure K&R 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 K&R 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 K&R 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
Roman Divacky 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"
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
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 K&R code? I don't believe so, but pure K&R 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 K&R 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 K&R 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"
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 K&R code? I don't believe so, but pure K&R 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 K&R 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 K&R 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 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 K&R 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 K&R 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 K&R 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 K&R 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 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 K&R 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 K&R 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 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 K&R 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
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 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"
[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: 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"
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 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/libtool>make -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"
"UPDATING" file
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. 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"
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/157044x11-toolkits/slgt
Re: ports/157868: mail/mailman: Possible problem with MAIL_GID
On 20 June 2011 11:10, Guido Falsi wrote: > On Mon, Jun 20, 2011 at 10:30:58AM +0100, Chris Rees wrote: >> On 20 June 2011 10:22, Guido Falsi 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"
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 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 ___ 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: net/samba-libsmbclient SAMBA_PORT= -> SAMBA_PORT?=
On 12 March 2011 18:18, J. Hellenthal 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
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/libtool>make -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: ports/157868: mail/mailman: Possible problem with MAIL_GID
On 20 June 2011 10:22, Guido Falsi 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"