Re: MAKE_JOBS and openjdk6
On Saturday 04 September 2010 23:26:27 Greg Lewis wrote: On Sun, Aug 29, 2010 at 10:37:37AM +0200, David Naylor wrote: On Saturday 28 August 2010 23:30:22 Greg Lewis wrote: On Sun, Aug 29, 2010 at 12:44:39AM +0400, Anonymous wrote: Greg Lewis gle...@eyesbeyond.com writes: Your attached patch does not explicitly define either MAKE_JOBS_(UN)SAFE. I would by happy with it being defined as _UNSAFE. If there are no other problems with your patch (see my comment at the bottom) then I'm happy for this patch to be committed. I'd already committed a change that marked the port as MAKE_JOBS_UNSAFE, so the patch didn't include that. Yes, sorry I didn't see that. Is it safe to pass an empty HOTSPOT_BUILD_JOBS to MAKE_ENV? (i.e. when DISABLE_MAKE_JOBS is defined.) Good thought. I tried the build with DISABLE_MAKE_JOBS set and experienced no problems, so I think we're ok on that front. +.endif COPYDIRS=\ hotspot/src/os/linux/launcher \ I'm going to commit the change in a day or two if there are no further objections. I'll then use it as a template for changes to the other JDK ports. No objections here. Thank you for your patience in resolving this. signature.asc Description: This is a digitally signed message part.
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 2010-Aug-31 17:14:50 -0400, jhell jh...@dataix.net wrote: On 08/31/2010 15:06, b. f. wrote: Would you elaborate, please? Where is a transcript showing the linking failure? Would you mail it to me off-list? Simply -lgfortran by it self should not work. Since lib directories Actually, IMO, since libgfortran.so is a support library for gfortran (much like libgcc_s.so is), it is reasonable for a user to expect that '-lgfortran' _is_ sufficient and the current behaviour is a bug. ports/129518 says I'm not the only person who think that. -L/usr/local/lib/gcc44 would have to be passed to LDFLAGS in order for it to be found. And '-R/usr/local/lib/gcc44' as well. Note that a work-around has been added to bsd.gcc.mk so that ports with USE_GCC shouldbehave correctly and the problem is limited to using a non-base gcc outside the ports system. -- Peter Jeremy pgpPCGMr47ZD4.pgp Description: PGP signature
[SOLVED]: math/blas linking to gfortran with LDADD?= -lgfortran
On 09/05/2010 15:12, Peter Jeremy wrote: On 2010-Aug-31 17:14:50 -0400, jhell jh...@dataix.net wrote: On 08/31/2010 15:06, b. f. wrote: Would you elaborate, please? Where is a transcript showing the linking failure? Would you mail it to me off-list? Simply -lgfortran by it self should not work. Since lib directories Actually, IMO, since libgfortran.so is a support library for gfortran (much like libgcc_s.so is), it is reasonable for a user to expect that '-lgfortran' _is_ sufficient and the current behaviour is a bug. ports/129518 says I'm not the only person who think that. -L/usr/local/lib/gcc44 would have to be passed to LDFLAGS in order for it to be found. And '-R/usr/local/lib/gcc44' as well. Note that a work-around has been added to bsd.gcc.mk so that ports with USE_GCC shouldbehave correctly and the problem is limited to using a non-base gcc outside the ports system. Unfortunately this was caused by devel/ccache ;( or probably better said ccache attributed to finding this bug. The problem was that ccache was or is not liable for finding the lib/gccXX installs and therefore being called before, discards appropriate paths or whatnot ultimately borking the build. How I missed the problem was assuming that src.conf(5) is not used by ports(7) I had put the appropriate ccache, if then else statements in src.conf(5) to specifically keep it away from ports(7). As explained by b.f. math/blas being as old as it is uses files from /usr/src, so with that noted src.conf(5) gets pulled in and resulted in ccache being set by CC CXX defines. The default if statement that I had in src.conf(5) was the one from the FreeBSD ccache example... Shouldn't have caught that right ??? think again... I had also set WRKDIRPREFIX=/usr/obj for ports(7)! in a if statement in make.conf(5) ARG!!! Here is the example: .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) !defined(NOCCACHE) Of course /usr/src is not empty here and of course /usr/obj is not empty, thats where I am compiling and of course I did not specify NOCCACHE because IMHO src.conf(5) should not be pulled into ports(7) at all. So needless to say I went the harder route of non-automation and changed that quickly to: .if defined(MY_LOCAL_DEFINE_HERE) !defined(NOCCACHE) And now compiling graciously the ports I want with -DMY_LOCAL_DEFINE_HERE It would be real nice if someone could add NOCCACHE WITHOUT_CCACHE to the ports .mk files so ports like math/blas can quickly override the use of ccache if the user decides to use the default example provided in local/share/doc/ccache/ccache-howto-freebsd.txt So to say the least there were multiple faulted layers here at play including me! Also math/lapack will not compile if a user has specified WITHOUT_PROFILE in there src.conf(5) specifically it wants libc_p.so.7 but a system with the above set will not have that installed. They are fixing this. Regards, -- jhell,v ___ 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
kdehier4 upgrade - Operation not permitted
When trying to install kdehier4, the following errors show up. Any ideas? -Troy /usr/ports/misc/kdehier4# make install === Installing for kdehier4-1.0.6 === Generating temporary packing list === Checking if misc/kdehier4 already installed /bin/ln -sf /usr/local/libdata/ldconfig /usr/local/kde4/libdata/ /bin/ln -sf /usr/local/libdata/ldconfig32 /usr/local/kde4/libdata/ /bin/ln -sf /usr/local/libdata/pkgconfig /usr/local/kde4/libdata/ /bin/ln -sf /usr/local/share/PolicyKit/policy /usr/local/kde4/share/PolicyKit/ ln: /usr/local/kde4/share/PolicyKit//policy: Operation not permitted *** Error code 1 Stop in /usr/ports/misc/kdehier4. Exit 1 ___ 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: kdehier4 upgrade - Operation not permitted
On Sun, Sep 05, 2010 at 10:19:50PM -0500, Troy wrote: When trying to install kdehier4, the following errors show up. Any ideas? -Troy /usr/ports/misc/kdehier4# make install === Installing for kdehier4-1.0.6 === Generating temporary packing list === Checking if misc/kdehier4 already installed /bin/ln -sf /usr/local/libdata/ldconfig /usr/local/kde4/libdata/ /bin/ln -sf /usr/local/libdata/ldconfig32 /usr/local/kde4/libdata/ /bin/ln -sf /usr/local/libdata/pkgconfig /usr/local/kde4/libdata/ /bin/ln -sf /usr/local/share/PolicyKit/policy /usr/local/kde4/share/PolicyKit/ ln: /usr/local/kde4/share/PolicyKit//policy: Operation not permitted *** Error code 1 Please provide output from the following: /sbin/sysctl kern.securelevel /bin/ls -ldo /usr/local/share/PolicyKit/policy /bin/ls -ldo / /bin/ls -ldo /usr/local /bin/ls -ldo /usr/local/kde4 /bin/ls -ldo /usr/local/kde4/share /bin/ls -ldo /usr/local/kde4/share/PolicyKit -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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
Testing editors/emacs-devel on 9-CURRENT
Hi everyone, Could some running 9-CURRENT try building a package of editors/emacs-devel port (latest version available in the tree) with default OPTIONS ? Something like: #v+ % script emacs-devel.log sudo make -C /usr/ports/editors/emacs-devel build deinstall package #v- And after building the package, could you paste the generated log (emacs-devel.log) at some pastebin[1] and post a link here, irrespective of any errors you received ? References: [1] http://pastebin.com/ Thanks in advance. -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ Avoid Success At All Costs !! pgp5UHGy2sn3X.pgp Description: PGP signature
Re: kdehier4 upgrade - Operation not permitted
On 09/05/2010 10:54 PM, Jeremy Chadwick wrote: /sbin/sysctl kern.securelevel /bin/ls -ldo /usr/local/share/PolicyKit/policy /bin/ls -ldo / /bin/ls -ldo /usr/local /bin/ls -ldo /usr/local/kde4 /bin/ls -ldo /usr/local/kde4/share /bin/ls -ldo /usr/local/kde4/share/PolicyKit oz:112:/usr/ports/misc/kdehier4# /sbin/sysctl kern.securelevel kern.securelevel: -1 oz:113:/usr/ports/misc/kdehier4# /bin/ls -ldo /usr/local/share/PolicyKit/policy/bin/ls -ldo / drwxr-xr-x 2 root wheel - 512 Sep 4 21:23 /usr/local/share/PolicyKit/policy oz:114:/usr/ports/misc/kdehier4# /bin/ls -ldo / drwxr-xr-x 27 root wheel - 1024 Aug 28 16:54 / oz:115:/usr/ports/misc/kdehier4# /bin/ls -ldo /usr/local drwxr-xr-x 24 root wheel - 512 Aug 28 14:59 /usr/local oz:116:/usr/ports/misc/kdehier4# /bin/ls -ldo /usr/local/kde4 drwxr-xr-x 14 root wheel - 512 Sep 5 22:02 /usr/local/kde4 oz:117:/usr/ports/misc/kdehier4# /bin/ls -ldo /usr/local/kde4/share drwxr-xr-x 34 root wheel - 1024 Sep 5 22:02 /usr/local/kde4/share oz:118:/usr/ports/misc/kdehier4# /bin/ls -ldo /usr/local/kde4/share/PolicyKit drwxr-xr-x 3 root wheel - 512 Jun 21 00:57 /usr/local/kde4/share/PolicyKit ___ 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
Which DEPENDS if something is just needed during port install
What kind of dependency should I define if I just need something for the install target? It's not needed before, not after and not for the package. I used to think it's INSTALL_DEPENDS, but I just found out, that doesn't even exist. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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
