Re: redports.org - The public FreeBSD ports development infrastructure
Bernhard Froehlich wrote: Hi Porters! I am happy to announce that redports.org has finally reached the point where I think It's safe to be used by everybody! First of all, this is pretty great. Next, questions, comments feature requests. 1. It would be good to see what is currently in the queue for each backend (or buildgroup) right now; just to get an estimation of when your build will finish (e.g. in a few minutes vs. in a month). An actual estimation would be even better. 2. GCC 4.5 buildgroup currently shows 0 queued builds, but for some reason my build in that buildgroup does not start. Is there really nothing queued there? 3. On My builds page I see two strange builds in waiting state: one for buildgroup GCC another for 4.5; should that be one buidgroup GCC 4.5? 4. Is each backend a separate physical (or virtual) machine (i.e. do they all operate independently)? Are more machines planned? 5. Is there a way to see all the build archive, not just yours when you are logged in? ___ 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: lang/lua: /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC
Am 12/29/11 12:59, schrieb Kostik Belousov: On Thu, Dec 29, 2011 at 12:19:40PM +0100, O. Hartmann wrote: Am 12/29/11 11:48, schrieb Rainer Hurling: On 28.12.2011 19:31 (UTC+1), Kostik Belousov wrote: On Wed, Dec 28, 2011 at 07:21:00PM +0100, O. Hartmann wrote: Am 12/28/11 19:10, schrieb Ed Schouten: * Rainer Hurlingrhur...@gwdg.de, 20111228 17:31: error: macro _Static_assert passed 3 arguments, but takes just 2 In file included from /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:103:0: Hmmm... This seems to apply to my changes. I will look into this tomorrow. Thanks for the report! Be aware that the error produced by the linker I mentioned in the initial post occurs on FreeBSD 10 as well as FreeBSD 9.0. I already filed a PR about the problem of a non compiling lang/gcc46 today (ports/163672: lang/gcc46: make failed for lang/gcc46). For test puproses, I rebuild gcc46 on our FreeBSD 9.0 boxes - without any problem. I guess, the commit r228902 has been done to FreeBSD 10.0 and not 9.0. Obviously, linker error during the compilation of third-party software has nothing to do with compiler error occuring when building gcc. Do people ever read the texts of the messages ? Kostik, probably you are right. I had read the messages, but there are some strange errors with gcc46 on head for two days now, which leaded me in the wrong direction. So sorry for erroneously 'hijacking' this thread with another problem most certain only existing in head. I found another trail, which hopefully is more usefull for solving the problem Oliver described. Whe I try to build lang/lua I get this error: [..snip..] cc -o liblua.so -O2 -fno-strict-aliasing -pipe -msse3 -Wall -DLUA_USE_LINUX -shared -Wl,-soname=liblua-5.1.so.1 lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o ranlib liblua.a cc -o lua lua.o liblua.a -lm -Wl,-E -lreadline cc -o luac luac.o print.o liblua.a -lm -Wl,-E -lreadline /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC lapi.o: could not read symbols: Bad value *** Error code 1 It also gives a linker error, almost the same relocation is named. This does only happen with option '-msse3' enabled in /etc/make.conf: CFLAGS= -O2 -fno-strict-aliasing -pipe -msse3 Using CLFAGS without -msse3 (default) works well: CFLAGS= -O2 -fno-strict-aliasing -pipe The systems processor, were this happens, is a CPU: AMD Phenom(tm) II X6 1090T Processor (3214.32-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100fa0 Family = 10 Model = a Stepping = 0 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT TSC: P-state invariant, performance statistics FreeBSD 10-CURRENT (amd64) r228920 In hope of a more belonging posting, Rainer ___ WOW! I tried lang/lua on FreeBSD 9.0-PRE and see exactly this error: clang -O2 -fno-strict-aliasing -pipe -march=core2 -Wall -DLUA_USE_LINUX -c print.c clang -o liblua.so -O2 -fno-strict-aliasing -pipe -march=core2 -Wall -DLUA_USE_LINUX -shared -Wl,-soname=liblua-5.1.so.1 lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC lapi.o: could not read symbols: Bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o ranlib liblua.a 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 1 Stop in /usr/ports/lang/lua. === make failed for lang/lua === Aborting update On FreeBSD 10.0-CURRENT I see this: clang -O2
Re: lang/lua: /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC
On 29.12.2011 13:59 (UTC+1), O. Hartmann wrote: Am 12/29/11 13:34, schrieb Daniel Kalchev: On 29.12.11 14:19, O. Hartmann wrote: Am 12/29/11 12:59, schrieb Kostik Belousov: On Thu, Dec 29, 2011 at 12:19:40PM +0100, O. Hartmann wrote: [...] /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC lapi.o: could not read symbols: Bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/ports/lang/lua/work/lua-5.1.4/src. *** Error code 1 Stop in /usr/ports/lang/lua/work/lua-5.1.4/src. *** Error code 1 Stop in /usr/ports/lang/lua/work/lua-5.1.4. *** Error code 1 Stop in /usr/ports/lang/lua. === make failed for lang/lua === Aborting update Terminated Terminated This is very strange! What is strange ? It is exactly the same problem as in the first message started this thread. You must use -fPIC flag for compiler when compiling objects that shall be later linked into dso. So, for lua case, -fPIC must be present on the cc -c command line. This therefore strange, since this problem with lua occurs on machines, where I've set CFLAGS= and COPTFLAGS= as in /usr/share/examples/etc/make.conf and on one box, one box I accidentally set those flags to CFLAGS+= and COPTFLAGS+= and there it works and the -fPIC flag is set by the FreeBSD's port framework. So I guess there is a bug introduced with one of the last Mk-files updates. As suggested by the howto for using newer GCC versions, http://www.freebsd.org/doc/en/articles/custom-gcc/article.html you are supposed to use CFLAGS+= to add additional compile flags. Just for the record I'd like to repeat, that the error above mentioned is also with the legacy FreeBSD's gcc 4.2.X compiler. As Kostik Belousov made clear in his last posting, the error occurs due to a missing -fPIC - which is now clear to me. People not sleeping with their OS, like myself, would simply copy the make.conf from /usr/share/examples/etc/ and set some additional flags. Then the problem will occur again. Maybe it would be wise to reflect this issue by some additional words in make.conf? As stated earlier, the following fails in /etc/make.conf for lang/lua: CFLAGS= -O2 -fno-strict-aliasing -pipe -msse3 The next one works ( += instead of = ) and -fPIC is preserved this way: CFLAGS+= -O2 -fno-strict-aliasing -pipe -msse3 Thanks, Kostik and Daniel for clearing this. I think, like Oliver, that this should be mentioned in /etc/make.conf or make.conf(5). Rainer By the way, -O2 -fno-strict-aliasing -pipe are the default flags, that are used when CFLAGS is not set by the user. COPTFLAGS is used only to build the kernel and doing it with non-system GCC is not likely to be safe. Daniel Oliver ___ 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: New mailing list for ports announcements
On Thu, Dec 29, 2011 at 11:19:00AM +0400, Yuri Pankov wrote: On Thu, Dec 29, 2011 at 09:23:05AM +0300, Sergey V. Dyatko wrote: On Thu, 29 Dec 2011 00:59:26 -0500 Thomas Abthorpe tabtho...@freebsd.org wrote: At the request of adamw@ (and others) we have setup a ports-announce@ mailing list to try distinguish the usual traffic on the ports@ list vs the announcements that seem to get lost in there. Useless and harmful list, IMO. People who can 'lost' announcements here likely lose it on another list, but there is a chance that people who read ports@ lose announce/CFT from _only_ freebsd-ports-announce. Of course, you can write to multiple lists.. But lets look at current@ stable@ and performance@ archives... tadam! Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server. You seem to miss the moderated part.. Thank you, Yuri As implied, but not necessarily stated, moderated and not intended for discussions. Discussion are welcome in this forum, as always. Is that ok ? I think 'No' ( Tons of spam in [ 3 of N ] ML that I subscribed ) You can subscribe at http://lists.freebsd.org/mailman/listinfo/freebsd-ports-announce It is intended, but not limited, to be a means of communicating portmgr@ announcements, Calls for Testing, plus other relevant information to be used by our committers and ports maintainer community. It is our hope to keep this relatively low in traffic. It is a moderated list, under the auspices of portmgr@. ^ Please subscribe sit back, and enjoy. Yuri Thomas -- Thomas Abthorpe | FreeBSD Committer tabtho...@freebsd.org | http://people.freebsd.org/~tabthorpe pgp7n7RfKbueq.pgp Description: PGP signature
Re: redports.org - The public FreeBSD ports development infrastructure
On Do., 29. Dez. 2011 15:26:12 CET, Vitaly Magerya vmage...@gmail.com wrote: Bernhard Froehlich wrote: Hi Porters! I am happy to announce that redports.org has finally reached the point where I think It's safe to be used by everybody! First of all, this is pretty great. Next, questions, comments feature requests. 1. It would be good to see what is currently in the queue for each backend (or buildgroup) right now; just to get an estimation of when your build will finish (e.g. in a few minutes vs. in a month). An actual estimation would be even better. Showing the buildqueue is easy but making predictions from the list is nearly impossible. There is a scheduling algorithm that tries to be fair but it cannot do much more than that. 2. GCC 4.5 buildgroup currently shows 0 queued builds, but for some reason my build in that buildgroup does not start. Is there really nothing queued there? Currently all builds are on the same machine and there is a limit of 2 parallel builds for this machine. 3. On My builds page I see two strange builds in waiting state: one for buildgroup GCC another for 4.5; should that be one buidgroup GCC 4.5? Sounds like a bug. I will have a look at that. 4. Is each backend a separate physical (or virtual) machine (i.e. do they all operate independently)? Are more machines planned? There is currently only one backend machine that is limited to two parallel builds. It is a 6 core Phenom II with 16GB Ram so performance is quite decent but more hardware will be needed over time. I would also like to get get some Tier-2 hardware like powerpc or sparc if there is enough interest. So organizing more hardware is on my todo but it will take some time. 5. Is there a way to see all the build archive, not just yours when you are logged in? No currently not but this is only a cosmetic thing and easy to fix. I've put it on my todo. ___ 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: redports.org - The public FreeBSD ports development infrastructure
FYI: me too. 502 Bad Gateway -- nginx/1.0.11 * -- * *Iqbal Aroussi* *+212 665 025 032* *iq...@aroussi.name* On Thu, Dec 29, 2011 at 16:08, Frank Laszlo fr...@franksworld.org wrote: On 12/29/11 6:44 AM, Bernhard Froehlich wrote: Hi Porters! I am happy to announce that redports.org has finally reached the point where I think It's safe to be used by everybody! FYI, I'm getting a 502 bad gateway error when loading the page. -- Frank Laszlo __**_ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-portshttp://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscribe@**freebsd.orgfreebsd-ports-unsubscr...@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
[Resolved] GCC 4.6 compilation problems w.r.t. static_assert
* Ed Schouten e...@80386.nl, 20111228 19:10: Hmmm... This seems to apply to my changes. I will look into this tomorrow. Thanks for the report! Just to clarify, as mentioned earlier in this thread, the linking problems problems are not related by my C11 patches, as they are only part of HEAD. It seems they were caused due to local configuration problems and have been resolved. The GCC 4.6 compilation problem on HEAD was caused by one of my changes. Please update your system to r228955 or later. Thanks for reporting. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgp80d5lu6HSh.pgp Description: PGP signature
Re: lang/lua: /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC
Am 12/29/11 13:34, schrieb Daniel Kalchev: On 29.12.11 14:19, O. Hartmann wrote: Am 12/29/11 12:59, schrieb Kostik Belousov: On Thu, Dec 29, 2011 at 12:19:40PM +0100, O. Hartmann wrote: [...] /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC lapi.o: could not read symbols: Bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/ports/lang/lua/work/lua-5.1.4/src. *** Error code 1 Stop in /usr/ports/lang/lua/work/lua-5.1.4/src. *** Error code 1 Stop in /usr/ports/lang/lua/work/lua-5.1.4. *** Error code 1 Stop in /usr/ports/lang/lua. === make failed for lang/lua === Aborting update Terminated Terminated This is very strange! What is strange ? It is exactly the same problem as in the first message started this thread. You must use -fPIC flag for compiler when compiling objects that shall be later linked into dso. So, for lua case, -fPIC must be present on the cc -c command line. This therefore strange, since this problem with lua occurs on machines, where I've set CFLAGS= and COPTFLAGS= as in /usr/share/examples/etc/make.conf and on one box, one box I accidentally set those flags to CFLAGS+= and COPTFLAGS+= and there it works and the -fPIC flag is set by the FreeBSD's port framework. So I guess there is a bug introduced with one of the last Mk-files updates. As suggested by the howto for using newer GCC versions, http://www.freebsd.org/doc/en/articles/custom-gcc/article.html you are supposed to use CFLAGS+= to add additional compile flags. Just for the record I'd like to repeat, that the error above mentioned is also with the legacy FreeBSD's gcc 4.2.X compiler. As Kostik Belousov made clear in his last posting, the error occurs due to a missing -fPIC - which is now clear to me. People not sleeping with their OS, like myself, would simply copy the make.conf from /usr/share/examples/etc/ and set some additional flags. Then the problem will occur again. Maybe it would be wise to reflect this issue by some additional words in make.conf? By the way, -O2 -fno-strict-aliasing -pipe are the default flags, that are used when CFLAGS is not set by the user. COPTFLAGS is used only to build the kernel and doing it with non-system GCC is not likely to be safe. Daniel Oliver signature.asc Description: OpenPGP digital signature
lang/lua: /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC
Am 12/29/11 11:48, schrieb Rainer Hurling: On 28.12.2011 19:31 (UTC+1), Kostik Belousov wrote: On Wed, Dec 28, 2011 at 07:21:00PM +0100, O. Hartmann wrote: Am 12/28/11 19:10, schrieb Ed Schouten: * Rainer Hurlingrhur...@gwdg.de, 20111228 17:31: error: macro _Static_assert passed 3 arguments, but takes just 2 In file included from /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:103:0: Hmmm... This seems to apply to my changes. I will look into this tomorrow. Thanks for the report! Be aware that the error produced by the linker I mentioned in the initial post occurs on FreeBSD 10 as well as FreeBSD 9.0. I already filed a PR about the problem of a non compiling lang/gcc46 today (ports/163672: lang/gcc46: make failed for lang/gcc46). For test puproses, I rebuild gcc46 on our FreeBSD 9.0 boxes - without any problem. I guess, the commit r228902 has been done to FreeBSD 10.0 and not 9.0. Obviously, linker error during the compilation of third-party software has nothing to do with compiler error occuring when building gcc. Do people ever read the texts of the messages ? Kostik, probably you are right. I had read the messages, but there are some strange errors with gcc46 on head for two days now, which leaded me in the wrong direction. So sorry for erroneously 'hijacking' this thread with another problem most certain only existing in head. I found another trail, which hopefully is more usefull for solving the problem Oliver described. Whe I try to build lang/lua I get this error: [..snip..] cc -o liblua.so -O2 -fno-strict-aliasing -pipe -msse3 -Wall -DLUA_USE_LINUX -shared -Wl,-soname=liblua-5.1.so.1 lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o ranlib liblua.a cc -o lua lua.o liblua.a -lm -Wl,-E -lreadline cc -o luac luac.o print.o liblua.a -lm -Wl,-E -lreadline /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC lapi.o: could not read symbols: Bad value *** Error code 1 It also gives a linker error, almost the same relocation is named. This does only happen with option '-msse3' enabled in /etc/make.conf: CFLAGS= -O2 -fno-strict-aliasing -pipe -msse3 Using CLFAGS without -msse3 (default) works well: CFLAGS= -O2 -fno-strict-aliasing -pipe The systems processor, were this happens, is a CPU: AMD Phenom(tm) II X6 1090T Processor (3214.32-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100fa0 Family = 10 Model = a Stepping = 0 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT TSC: P-state invariant, performance statistics FreeBSD 10-CURRENT (amd64) r228920 In hope of a more belonging posting, Rainer ___ WOW! I tried lang/lua on FreeBSD 9.0-PRE and see exactly this error: clang -O2 -fno-strict-aliasing -pipe -march=core2 -Wall -DLUA_USE_LINUX -c print.c clang -o liblua.so -O2 -fno-strict-aliasing -pipe -march=core2 -Wall -DLUA_USE_LINUX -shared -Wl,-soname=liblua-5.1.so.1 lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC lapi.o: could not read symbols: Bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o ranlib liblua.a 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 1 Stop in /usr/ports/lang/lua. === make failed for lang/lua === Aborting update On FreeBSD 10.0-CURRENT I see this: clang -O2 -fno-strict-aliasing -pipe -march=core2 -Wall -DLUA_USE_LINUX -c linit.c ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o
Re: redports.org - The public FreeBSD ports development infrastructure
On 12/29/11 6:44 AM, Bernhard Froehlich wrote: Hi Porters! I am happy to announce that redports.org has finally reached the point where I think It's safe to be used by everybody! FYI, I'm getting a 502 bad gateway error when loading the page. -- Frank Laszlo ___ 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: hplip fails to build
Am 29.12.2011 05:55, schrieb Jeffrey McFadden: Hello, Porters. I mentioned this a couple of days ago but it appears to me that my email lacked necessary information. the first failure looks like this: Attempting to fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/skv/BSDPAN-2007.tar.bz2 BSDPAN-2007.tar.bz2 100% of 8448 B 21 kBps === perl-5.12.4_3 conflicts with installed package(s): perl-5.10.1_3 They will not build together. Please remove them first with pkg_delete(1). *** Error code 1 Stop in /usr/ports/lang/perl5.12. *** Error code 1 Stop in /usr/ports/lang/perl5.12. *** Error code 1 Stop in /usr/ports/net-mgmt/net-snmp. *** Error code 1 Stop in /usr/ports/net-mgmt/net-snmp. *** Error code 1 Stop in /usr/ports/print/hplip. *** Error code 1 Stop in /usr/ports/print/hplip. [jeff@Midget] /usr/ports/print/hplip# On my previous attempt I did deinstall the older perl and install the requested version, but it went ahead and failed again later. Jeff, how exactly did you upgrade to Perl 5.12? Please check /etc/make.conf if there is a PERL_VERSION= line pointing to the old version somehow. Else, please try to follow the instructions from /usr/ports/UPDATING (which you should check regularly): - 20100715: AFFECTS: users of lang/perl* AUTHOR: s...@freebsd.org lang/perl5.12 is out. If you want to switch to it from, for example lang/perl5.10, that is: Portupgrade users: 0) Fix pkgdb.db (for safety): pkgdb -Ff 1) Reinstall new version of Perl (5.12): env DISABLE_CONFLICTS=1 portupgrade -o lang/perl5.12 -f perl-5.10.\* 2) Reinstall everything that depends on Perl: portupgrade -fr perl Portmaster users: portmaster -o lang/perl5.12 lang/perl5.10 Conservative: portmaster p5- Comprehensive (but perhaps overkill): portmaster -r perl- Note: If the perl- glob matches more than one port you will need to specify the name of the Perl directory in /var/db/pkg explicitly. - Hope that helps. Best regards, ___ 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: redports.org - The public FreeBSD ports development infrastructure
On Thu, Dec 29, 2011 at 6:08 PM, Frank Laszlo fr...@franksworld.org wrote: On 12/29/11 6:44 AM, Bernhard Froehlich wrote: Hi Porters! I am happy to announce that redports.org has finally reached the point where I think It's safe to be used by everybody! FYI, I'm getting a 502 bad gateway error when loading the page. Me too :( BTW, has anyone considered evaluating Jenkins [1] for doing the same thing? Jenkins is quite interesting IMO, and is worth testing it out :) [1] http://jenkins-ci.org/ Regards, Marin -- Frank Laszlo ___ 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 -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.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: x11/nvidia-{driver, settings, xconfig}: why not the latest available version (290.10)?
On Sat, 24 Dec 2011 02:44:04 -0600, Denise H. G. darc...@gmail.com wrote: 290.10 has some issues on text redrawing as far I experience. I have also been running 290.10 for quite a while. Some apps, especially emacs and gnome-terminal will fail redrawing text areas while, e.g. scrolling. And x11 cursor cannot sometimes be displayed correctly. Are we sure this isn't a bug somewhere else? I've been having redrawing problems on 285.05.09 and moving to 290.10 is what fixed it for me ___ 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: redports.org - The public FreeBSD ports development infrastructure
On Thu, 29 Dec 2011, Frank Laszlo wrote: I am happy to announce that redports.org has finally reached the point where I think It's safe to be used by everybody! FYI, I'm getting a 502 bad gateway error when loading the page. In nginx case, it's usually a sympthom of broken/stalled/stopped backend. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: redports.org - The public FreeBSD ports development infrastructure
Account created. Am I the first user of your redports.org ? wen 2011/12/29 Bernhard Froehlich de...@freebsd.org Hi Porters! I am happy to announce that redports.org has finally reached the point where I think It's safe to be used by everybody! In case you never heard of it before redports is the result of an idea born at EuroBSDCon 2011 in Karlsruhe to give Port Maintainers and Port Committers a public service to test their new ports or ports patches during development or before submitting a ports PR. Many people test ports only on their own machine because of lack of hardware. Redports gives you instant access to build environments for FreeBSD 7.4, 8.2, 9-CURRENT, 10-CURRENT on i386 and amd64 and even special ones that use CLANG/LLVM or GCC 4.5 as ports compiler. For everyone familiar with FreeBSD Ports Tinderbox [1] it's pretty obvious how it works. In fact redports is build on top of multiple Tinderboxes so it is scalable, fast and reliable. With your account you get your own Subversion Repository to maintain your ports and with every commit to the repository all affected ports are automatically built. When registering an account please read the UserGuide [2] first to get an idea of how to work with it. Feedback and new Ideas are welcome! Best regards, Bernhard Fröhlich (decke@) [1] http://tinderbox.marcuscom.**com/ http://tinderbox.marcuscom.com/ [2] http://redports.org/wiki/**UserGuidehttp://redports.org/wiki/UserGuide -- Bernhard Froehlich http://www.bluelife.at/ __**_ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-portshttp://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscribe@**freebsd.orgfreebsd-ports-unsubscr...@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: redports.org - The public FreeBSD ports development infrastructure
I am trying this out. Looking at the instructions on https://redports.org/wiki/UserGuide: svn co https://svn.redports.org/yourusername mkdir www cp -pr /usr/ports/www/phpvirtualbox www/ svn add www svn commit -m phpvirtualbox added shouldn't there be a second line cd yourusername or something like that? ___ 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
redports.org - The public FreeBSD ports development infrastructure
Hi Porters! I am happy to announce that redports.org has finally reached the point where I think It's safe to be used by everybody! In case you never heard of it before redports is the result of an idea born at EuroBSDCon 2011 in Karlsruhe to give Port Maintainers and Port Committers a public service to test their new ports or ports patches during development or before submitting a ports PR. Many people test ports only on their own machine because of lack of hardware. Redports gives you instant access to build environments for FreeBSD 7.4, 8.2, 9-CURRENT, 10-CURRENT on i386 and amd64 and even special ones that use CLANG/LLVM or GCC 4.5 as ports compiler. For everyone familiar with FreeBSD Ports Tinderbox [1] it's pretty obvious how it works. In fact redports is build on top of multiple Tinderboxes so it is scalable, fast and reliable. With your account you get your own Subversion Repository to maintain your ports and with every commit to the repository all affected ports are automatically built. When registering an account please read the UserGuide [2] first to get an idea of how to work with it. Feedback and new Ideas are welcome! Best regards, Bernhard Fröhlich (decke@) [1] http://tinderbox.marcuscom.com/ [2] http://redports.org/wiki/UserGuide -- Bernhard Froehlich http://www.bluelife.at/ ___ 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: /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd9.0/4.6.3/../../../libstdc++.a: could not read symbols: Bad value
On 28.12.2011 19:31 (UTC+1), Kostik Belousov wrote: On Wed, Dec 28, 2011 at 07:21:00PM +0100, O. Hartmann wrote: Am 12/28/11 19:10, schrieb Ed Schouten: * Rainer Hurlingrhur...@gwdg.de, 20111228 17:31: error: macro _Static_assert passed 3 arguments, but takes just 2 In file included from /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:103:0: Hmmm... This seems to apply to my changes. I will look into this tomorrow. Thanks for the report! Be aware that the error produced by the linker I mentioned in the initial post occurs on FreeBSD 10 as well as FreeBSD 9.0. I already filed a PR about the problem of a non compiling lang/gcc46 today (ports/163672: lang/gcc46: make failed for lang/gcc46). For test puproses, I rebuild gcc46 on our FreeBSD 9.0 boxes - without any problem. I guess, the commit r228902 has been done to FreeBSD 10.0 and not 9.0. Obviously, linker error during the compilation of third-party software has nothing to do with compiler error occuring when building gcc. Do people ever read the texts of the messages ? Kostik, probably you are right. I had read the messages, but there are some strange errors with gcc46 on head for two days now, which leaded me in the wrong direction. So sorry for erroneously 'hijacking' this thread with another problem most certain only existing in head. I found another trail, which hopefully is more usefull for solving the problem Oliver described. Whe I try to build lang/lua I get this error: [..snip..] cc -o liblua.so -O2 -fno-strict-aliasing -pipe -msse3 -Wall -DLUA_USE_LINUX -shared -Wl,-soname=liblua-5.1.so.1 lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o ranlib liblua.a cc -o lua lua.o liblua.a -lm -Wl,-E -lreadline cc -o luac luac.o print.o liblua.a -lm -Wl,-E -lreadline /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC lapi.o: could not read symbols: Bad value *** Error code 1 It also gives a linker error, almost the same relocation is named. This does only happen with option '-msse3' enabled in /etc/make.conf: CFLAGS= -O2 -fno-strict-aliasing -pipe -msse3 Using CLFAGS without -msse3 (default) works well: CFLAGS= -O2 -fno-strict-aliasing -pipe The systems processor, were this happens, is a CPU: AMD Phenom(tm) II X6 1090T Processor (3214.32-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100fa0 Family = 10 Model = a Stepping = 0 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT TSC: P-state invariant, performance statistics FreeBSD 10-CURRENT (amd64) r228920 In hope of a more belonging posting, Rainer ___ 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: lang/lua: /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC
On Thu, Dec 29, 2011 at 12:19:40PM +0100, O. Hartmann wrote: Am 12/29/11 11:48, schrieb Rainer Hurling: On 28.12.2011 19:31 (UTC+1), Kostik Belousov wrote: On Wed, Dec 28, 2011 at 07:21:00PM +0100, O. Hartmann wrote: Am 12/28/11 19:10, schrieb Ed Schouten: * Rainer Hurlingrhur...@gwdg.de, 20111228 17:31: error: macro _Static_assert passed 3 arguments, but takes just 2 In file included from /usr/ports/lang/gcc46/work/gcc-4.6-20111209/libstdc++-v3/include/precompiled/stdc++.h:103:0: Hmmm... This seems to apply to my changes. I will look into this tomorrow. Thanks for the report! Be aware that the error produced by the linker I mentioned in the initial post occurs on FreeBSD 10 as well as FreeBSD 9.0. I already filed a PR about the problem of a non compiling lang/gcc46 today (ports/163672: lang/gcc46: make failed for lang/gcc46). For test puproses, I rebuild gcc46 on our FreeBSD 9.0 boxes - without any problem. I guess, the commit r228902 has been done to FreeBSD 10.0 and not 9.0. Obviously, linker error during the compilation of third-party software has nothing to do with compiler error occuring when building gcc. Do people ever read the texts of the messages ? Kostik, probably you are right. I had read the messages, but there are some strange errors with gcc46 on head for two days now, which leaded me in the wrong direction. So sorry for erroneously 'hijacking' this thread with another problem most certain only existing in head. I found another trail, which hopefully is more usefull for solving the problem Oliver described. Whe I try to build lang/lua I get this error: [..snip..] cc -o liblua.so -O2 -fno-strict-aliasing -pipe -msse3 -Wall -DLUA_USE_LINUX -shared -Wl,-soname=liblua-5.1.so.1 lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o ranlib liblua.a cc -o lua lua.o liblua.a -lm -Wl,-E -lreadline cc -o luac luac.o print.o liblua.a -lm -Wl,-E -lreadline /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC lapi.o: could not read symbols: Bad value *** Error code 1 It also gives a linker error, almost the same relocation is named. This does only happen with option '-msse3' enabled in /etc/make.conf: CFLAGS= -O2 -fno-strict-aliasing -pipe -msse3 Using CLFAGS without -msse3 (default) works well: CFLAGS= -O2 -fno-strict-aliasing -pipe The systems processor, were this happens, is a CPU: AMD Phenom(tm) II X6 1090T Processor (3214.32-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100fa0 Family = 10 Model = a Stepping = 0 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT TSC: P-state invariant, performance statistics FreeBSD 10-CURRENT (amd64) r228920 In hope of a more belonging posting, Rainer ___ WOW! I tried lang/lua on FreeBSD 9.0-PRE and see exactly this error: clang -O2 -fno-strict-aliasing -pipe -march=core2 -Wall -DLUA_USE_LINUX -c print.c clang -o liblua.so -O2 -fno-strict-aliasing -pipe -march=core2 -Wall -DLUA_USE_LINUX -shared -Wl,-soname=liblua-5.1.so.1 lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o /usr/bin/ld: lapi.o: relocation R_X86_64_32 against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC lapi.o: could not read symbols: Bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o ranlib liblua.a 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 1 Stop in /usr/ports/lang/lua. === make failed for lang/lua ===
Re: CFT: mplayer and mencoder updates
Hi, thank you all for your comments on the first iteration of the ports. A heavily revised version can be found on http://www.rrr.de/~riggs/mplayer/m20111230.tar.bz2 Changes: - reduce the number of explicit --enable-feature where it seemed reasonable, hence deviate less from the intention of the configure script - remove patching and reinplacing homegrown tweaks whenever possible, hence deviate less from the intention of the configure script - fix the reported pthread issue - always use internal libass - adopt patches to support 24 bit OSS output and keep volume during seek - use newer gcc and binutils thus enabling significant speed-ups (and also, since most mplayer and ffmpeg development is done on newer gcc and binutils than we have in the base system, it's slowly getting tedious to ensure compatibility with older toolchain) Caveats: - bluray does not work right now - keep it/turn it off in OPTIONS for now I hope the refactoring (removing mostly) of the tweaks to the configure and build environment does not impose noticeable changes for most users, but we may encounter difficulties in some configurations I couldn't check. Please give it a try! As always, comments, suggestions and especially patches are more than welcome. Best regards Riggs ___ 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: CFT: mplayer and mencoder updates
Zhihao Yuan lich...@gmail.com writes: On Thu, Dec 29, 2011 at 6:07 PM, Thomas Zander thomas.e.zan...@googlemail.com wrote: Hi, thank you all for your comments on the first iteration of the ports. A heavily revised version can be found on http://www.rrr.de/~riggs/mplayer/m20111230.tar.bz2 Changes: [...] - use newer gcc and binutils thus enabling significant speed-ups (and also, since most mplayer and ffmpeg development is done on newer gcc and binutils than we have in the base system, it's slowly getting tedious to ensure compatibility with older toolchain) So, with the new toolchain --disable-ssse3 is dropped but why BROKEN_RELOCATIONS is still there? GJ. Tested with clang, no problem either. Even though the port now explicitly uses gcc, ignoring CC from make.conf or Makefile.local ? And on clang with -integrated-as being default gnu as is not used, e.g. try to remove /usr/bin/as, it'd still build fine. ___ 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: CFT: mplayer and mencoder updates
On Thu, Dec 29, 2011 at 8:01 PM, Jan Beich jbe...@tormail.net wrote: Zhihao Yuan lich...@gmail.com writes: On Thu, Dec 29, 2011 at 6:07 PM, Thomas Zander thomas.e.zan...@googlemail.com wrote: Hi, thank you all for your comments on the first iteration of the ports. A heavily revised version can be found on http://www.rrr.de/~riggs/mplayer/m20111230.tar.bz2 Changes: [...] - use newer gcc and binutils thus enabling significant speed-ups (and also, since most mplayer and ffmpeg development is done on newer gcc and binutils than we have in the base system, it's slowly getting tedious to ensure compatibility with older toolchain) So, with the new toolchain --disable-ssse3 is dropped but why BROKEN_RELOCATIONS is still there? GJ. Tested with clang, no problem either. Even though the port now explicitly uses gcc, ignoring CC from make.conf or Makefile.local ? And on clang with -integrated-as being default gnu as is not used, e.g. try to remove /usr/bin/as, it'd still build fine. It's not ignoring CC. It sets USE_GCC=, which can be overwrite by make CC=clang. -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ 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
