Re: xorg problems
On 25/05/2012 05:18, Baptiste Daroussin wrote: Without the cairo patch (because it doesn't work for me) I managed to workaround the bug creating a xorg.conf (I haven't done that for a while :)) containing this: Section Device Identifier bla Driver intel Option AccelMethod XAA EndSection note that my xorg-server is not built with hal (don't know if is important or not) Brilliant! Worked for me too with unpatched cairo-1.12.2. My xorg-server *is* built with HAL but I don't think that has any influence on the Intel driver problem. Prior to the explicit XAA config in my Intel Device Section, /var/log/Xorg.0.log showed that the method was defaulting to EXA and X would freeze very soon after starting. Thank you. -- John Marshall signature.asc Description: OpenPGP digital signature
kdebase3 + clang
Hi!
The attached patch make kdebase3 compilable with clang-3.1 on FreeBSD 9-STABLE.
--- ./kdebase-3.5.10/kicker/applets/launcher/easyvector.h.orig 2012-05-26 11:11:24.0 +0200
+++ ./kdebase-3.5.10/kicker/applets/launcher/easyvector.h 2012-05-26 11:12:38.0 +0200
@@ -87,7 +87,7 @@
template class VALUE, bool CHECKINDEX
void EasyVector VALUE, CHECKINDEX ::eraseAt(Index index)
{ _checkIndex(index);
-erase(this-begin()+index);
+this-erase(this-begin()+index);
}
@@ -108,7 +108,7 @@
this-push_back(value);
return;
}
-insert(this-begin()+index,value);
+this-insert(this-begin()+index,value);
}
@@ -116,7 +116,7 @@
void EasyVector VALUE, CHECKINDEX ::insertAt(EasyVector VALUE, CHECKINDEX ::Index index,const EasyVector VALUE, CHECKINDEX v)
{ index=_convertInsertIndex(index);
_checkInsertIndex(index);
-insert(this-begin()+index,v.begin(),v.end());
+this-insert(this-begin()+index,v.begin(),v.end());
}
___
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
libX11 and clang: compile error
Hi! Somewhere in config* or Makefile are a hardcoded /usr/bin/cpp ... Script started on Sat May 26 10:51:06 2012 op has logged on :0 from local. [1mroot[m@[4mopn[24m libX11# make === License MIT accepted by the user === Extracting for libX11-1.4.4,1 = SHA256 Checksum OK for xorg/lib/libX11-1.4.4.tar.bz2. === Patching for libX11-1.4.4,1 === libX11-1.4.4,1 depends on file: /usr/local/libdata/pkgconfig/xcb.pc - found === libX11-1.4.4,1 depends on file: /usr/local/share/aclocal/xorg-macros.m4 - found === libX11-1.4.4,1 depends on file: /usr/local/libdata/pkgconfig/bigreqsproto.pc - found === libX11-1.4.4,1 depends on file: /usr/local/libdata/pkgconfig/xcmiscproto.pc - found === libX11-1.4.4,1 depends on file: /usr/local/libdata/pkgconfig/xextproto.pc - found === libX11-1.4.4,1 depends on file: /usr/local/libdata/pkgconfig/xtrans.pc - found === libX11-1.4.4,1 depends on file: /usr/local/libdata/pkgconfig/kbproto.pc - found === libX11-1.4.4,1 depends on file: /usr/local/libdata/pkgconfig/inputproto.pc - found === libX11-1.4.4,1 depends on file: /usr/local/libdata/pkgconfig/xf86bigfontproto.pc - found === libX11-1.4.4,1 depends on file: /usr/local/libdata/pkgconfig/xau.pc - found === libX11-1.4.4,1 depends on file: /usr/local/libdata/pkgconfig/xdmcp.pc - found === libX11-1.4.4,1 depends on file: /usr/local/libdata/pkgconfig/xproto.pc - found === libX11-1.4.4,1 depends on executable: pkg-config - found === Configuring for libX11-1.4.4,1 checking build system type... amd64-portbld-freebsd9.0 checking host system type... amd64-portbld-freebsd9.0 checking for gcc... cc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking how to run the C preprocessor... cpp checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of cc... gcc3 checking whether to enable maintainer-specific portions of Makefiles... no checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for fgrep... /usr/bin/grep -F checking for ld used by cc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... (cached) 262144 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... no checking how to convert amd64-portbld-freebsd9.0 file names to amd64-portbld-freebsd9.0 format... func_convert_file_noop checking how to convert amd64-portbld-freebsd9.0 file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... no checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from cc object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking for dlfcn.h... yes checking for objdir... .libs checking if cc supports -fno-rtti -fno-exceptions... yes checking for cc option to produce PIC... -fPIC -DPIC checking if cc PIC flag -fPIC -DPIC works... yes checking if cc static flag -static works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.o... (cached) yes checking whether the cc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker
Re: Xorg freezes since last update
Martin wrote: Hi there! I am running a box with FreeBSD 9.0-Release amd64 and a GeForce GTS450. This setup is was running for several months without any issues. Since the last Xorg-update I have freezes of XOrg every day (minimum one, sometimes more). I first did an update without setting WITH_NEW_XORG. I got failures. Later I set WITH_NEW_XORG and did a build of xorg and all depended ports. Again freezes. I switched back and disabled WITH_NEW_XORG and again I build xorg and all dependencies. I was using the current nvidia-driver from the ports-tree. I switched to the current betra-driver. Again freezes. We tried shrinking the physmem-sysctl. Freezes look like this: The screen does not update any windows. The mouse can be moved but it can't interact with the GUI. If the screen was black (screensaving) it stays black. If the screen showed a desktop this will be shown (no screensaver oder backlight-offs). Pressing CTRL+ALT+Fx does nothing. The only thing I can do is to log in with my smartphone using ssh and kill Xorg. This needs a lot of time but then it stops. The last messages in the XOrg-log are: (II) XINPUT: Adding extended input device Keyboard0 (type: KEYBOARD) (WW) May 25 21:13:00 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0858, 0x21a4) (WW) May 25 21:13:07 NVIDIA(0): WAIT (1, 6, 0x8000, 0x0858, 0x21a4) (WW) May 25 21:13:10 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0858, 0x3d50) (WW) May 25 21:13:17 NVIDIA(0): WAIT (1, 6, 0x8000, 0x0858, 0x3d50) (WW) May 25 21:13:20 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0858, 0x5850) (WW) May 25 21:13:27 NVIDIA(0): WAIT (1, 6, 0x8000, 0x0858, 0x5850) (WW) May 25 21:13:30 NVIDIA(0): WAIT (2, 6, 0x8000, 0x0858, 0xb5d8) (WW) May 25 21:13:37 NVIDIA(0): WAIT (1, 6, 0x8000, 0x0858, 0xb5d8) [mi] EQ overflowing. The server is probably stuck in an infinite loop. Last thing I tried was deleting all ports (unsing pkg_delete -a), then deleting /usr/local and again building all ports. Nothing changed. Can you help me? What else could I do to regain a running system?! Thank you a lot! It is really annoying! CU Martin -- I have the following line in my xorg.conf for a long time. It's a panacea for all xorg problems I've seen (also on linux boxes). Especially for the symptoms you described. # To prevent system freeze with Xorg in drmwtq state. HdH jan 3, 2011 Option NoAccel# [bool] Good luck with it. Hans ___ 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
TeXLive merge into FreeBSD ports tree - is this going to happen or not?
Hi FreeBSD fellows, Those who are using LaTeX on FreeBSD must know that tetex has been discontinued years ago and that TeXLive is now recommended, however TeXLive has never been merged in the ports tree on FreeBSD and that tetex is still used on FreeBSD ports. Although there have been some customized work so that FreeBSD users can install and use TeXLive on FreeBSD machine (for example, http://code.google.com/p/freebsd-texlive/wiki/Installing), this is quite confusing and may still cause conflict on the system side when using or maintaining it. There has also been years of gossips that a Japanese developer Hiroki Sato (hrs@freebsd) has been working on this matter for the last years and therefore the FreeBSD admin panel don't want anyone else to work on this and merge it into the ports tree. I actually contacted Hiroki Sato in the beginning of last year (2011) regarding this, and in his reply he said that there had been several technical issues but most of them had been solved and almost ready to merge into the port tree, and that he was planning to go forward after the 8.2/7.4 releases (one or two weeks later from that time stage) are out. However, more than a year has passed since then and still nothing happened. I tried to contact him several times after that (email, tweet, etc) but haven't heard anything back from him at all. Is TeXLive really going to be merged into the FreeBSD ports tree as Hiroki Sato mentioned previously? Or is this just a myth?? I am now thinking that this should be put into the FreeBSD Project ideas List [http://wiki.freebsd.org/IdeasPage]. Regards, Sam ___ 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: Xorg freezes since last update
Am Sat, 26 May 2012 12:01:23 +0200 schrieb Hans de Hartog h...@dehartog.nl: -- I have the following line in my xorg.conf for a long time. It's a panacea for all xorg problems I've seen (also on linux boxes). Especially for the symptoms you described. # To prevent system freeze with Xorg in drmwtq state. HdH jan 3, 2011 Option NoAccel # [bool] I've tried it. But, XOrg becomes too slow to allow normal working. So this is no solution to me. :( Waiting seconds to refresh a normal window like claws, or xterm is not sufficient. Additionally I bought a nVidia-card to have OpenGL. I don't want to loose it. But thanks for your ideas :) Greets Martin ___ 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: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
Le 25.05.2012 22:49, Rainer Hurling a écrit :
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13 {} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig ports
can coexist in principle, only some docs share the same places (which
should be changed, of course).
Maybe you're right. I've see on trac.osgeo.org that it uses swig-1.3.40.
I will try without specify version of swig.
___
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: TeXLive merge into FreeBSD ports tree - is this going to happen or not?
On 05/26/2012 09:19 AM, Nikola Lečić wrote: On Sat, 26 May 2012 09:01:37 -0400, Jerry wrote: On Sat, 26 May 2012 22:42:50 +1200 Sam Lin articulated: This was already repeated many times on this mailing list, but I guess it won't hurt to remind that vanilla TeX Live works on FreeBSD (from 7.0 to 10-CURRENT) out of the box. It lives in /usr/local/texlive/, has its own nice text and gui package manager and doesn't mess with the rest of your system. Just download ISO and install it. This is what I have done, and it has worked very well - except the xdvi program that came with texlive was linked to a different version of the xorg libraries! But http://code.google.com/p/freebsd-texlive/wiki/Installing didn't work for me. I tried the tlmgr command to change to letter paper size, and it gave me error messages. (I must admit that I haven't tried this recently so maybe it got fixed. But I didn't get any good responses when I complained on the freebsd-texlive mailing list - if I remember correctly I was told I shouldn't be using tlmgr.) But also, the current proposed freebsd texlive just looks way to difficult to maintain. Everytime the texlive distribution changes, the texlive ports have to update. If I were to implement texlive as a freebsd port, I would create a port called print/texlive-install. This port would build a texlive install-tl-unx.tar.gz program, just like can be found on the texlive web sites, but with xdvi and other binaries compiled by the port, but everything else operating according to the texlive philosophy. The port would run the install program, and then do a find /usr/local/texlive to fill in the appropriate /var/db/pkg/texlive files. I have written other ports where the ported software doesn't work well with the FreeBSD ports philosophy, and my approach has been to embrace the software's philosophy and make the freebsd port a wrapper for the software's installation process. This includes the math/sage port, and the math/octave-forge* ports. If I had the time, I would do the same for a texlive-install port. If wouldn't conflict with (but it would compete against) the current proposed freebsd texlive ports. The reason I haven't done this yet is (1) because of time constraints, and (2) I feel uncomfortable competing with someone elses proposed port structure. P.S. How did I solve the xdvi problem? I installed texlive from the texlive web site. Then I installed the FreeBSD print/teTeX port. Then I set PATH so that it picked up most of the commands from /usr/local/texlive/bin, but picked up xdvi from /usr/local/bin. I know it is an ugly hack. 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: qzeitgeist failed to compile on FreeBSD 9-STABLE
Quentin Schwerkolt develloper.u...@hotmail.fr writes: Hi, The port sysutils/qzeitgeist has failed to build on FreeBSD 9-STABLE. The configure phase seem run without issue. The build phase fails just after AUTOMOC4_EXECUTABLE-NOTFOUND was not found. How can I fix it? Can you post the contents of /usr/ports/sysutils/qzeitgeist/work/libqzeitgeist-0.8.0/CMakeCache.txt? ___ 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: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
On 26.05.2012 17:49 (UTC+2), coder.tuxfamily wrote:
Le 25.05.2012 22:49, Rainer Hurling a écrit :
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the
ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13 {} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig ports
can coexist in principle, only some docs share the same places (which
should be changed, of course).
Maybe you're right. I've see on trac.osgeo.org that it uses swig-1.3.40.
I will try without specify version of swig.
I saw in the news on http://www.swig.org/, that swig 2.0.6 is out with
many bug fixes and enhancements for templates and target languages like
php and python. Perhaps swig 2.0.6 is ready now for gdal?
I just checked, that swig 1.3.40 and 2.0.4 should be able to coexist at
the same time. At least they do not share any filenames.
___
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: libX11 and clang: compile error
On 26-5-2012 11:39, Oliver Pinter wrote: Somewhere in config* or Makefile are a hardcoded /usr/bin/cpp ... Stop in /usr/ports/x11/libX11. [1mroot[m@[4mopn[24m libX11# cat /etc/src.conf This file is irrelevant. It is not used by ports (or closer to the truth - it's turned off by /usr/share/mk/bsd.port.mk). -- Mel ___ 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: TeXLive merge into FreeBSD ports tree - is this going to happen or not?
On Sat, 26 May 2012 10:38:18 -0500, Stephen Montgomery-Smith wrote: On 05/26/2012 09:19 AM, Nikola Lečić wrote: This is what I have done, and it has worked very well - except the xdvi program that came with texlive was linked to a different version of the xorg libraries! [...] P.S. How did I solve the xdvi problem? I installed texlive from the texlive web site. Then I installed the FreeBSD print/teTeX port. Then I set PATH so that it picked up most of the commands from /usr/local/texlive/bin, but picked up xdvi from /usr/local/bin. I know it is an ugly hack. Please read this document: http://anthesphoria.net/FreeBSD/TeXLive-2011/bin/README.txt TeX Live FreeBSD binaries are a compromise between portability and easiness to resolve problems in cases such as yours. We did a lot of work over the last 3 years (minimalistic compiler options, customised perl binaries/libs...) to reduce the number of shared libraries dependencies as much as possible. The result: the installer, package manager and ca. 350 non-graphic utilities work for all FreeBSD=7. If you use asymptote, xdvi or xindy (compiled with clisp) on FreeBSD7, simply install misc/compat7. Best, Nikola (maintainer of TeX Live for FreeBSD) -- Nikola Lečić = Никола Лечић fingerprint : FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B ___ 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: libX11 and clang: compile error
I think src.conf is relevant, while it changes the system behavior, as changed the default cc from gcc-4.2 to clang. The error in this case is with cc -E command, which not pass configure test. On 5/26/12, Mel Flynn rfl...@acsalaska.net wrote: On 26-5-2012 11:39, Oliver Pinter wrote: Somewhere in config* or Makefile are a hardcoded /usr/bin/cpp ... Stop in /usr/ports/x11/libX11. [1mroot [m@ [4mopn [24m libX11# cat /etc/src.conf This file is irrelevant. It is not used by ports (or closer to the truth - it's turned off by /usr/share/mk/bsd.port.mk). -- Mel ___ 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: libX11 and clang: compile error
On 26-5-2012 19:17, Oliver Pinter wrote: I think src.conf is relevant, while it changes the system behavior, as changed the default cc from gcc-4.2 to clang. Thinking it doesn't make it so. Run: grep _WITHOUT_SRCCONF /usr/share/mk/*.mk Then investigate. Setting CC in /etc/src.conf has *no effect on CC passed to the ports*. Really. It does not. The file that can do that is /etc/make.conf. Another way is setting CC in your environment variables, through /etc/login.conf, /etc/yourshellrc ~/.profile ~/.[cz]?shrc and what not. In order to debug your issue, you should provide the output of what make thinks CC and CPP are and backtrack where they are set. Start with: make -C /usr/ports/x11/libX11 -V CC -V CPP -- Mel ___ 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: pkgng updating math/gmp : *** [fake-pkg] Signal 11
On Tue, May 22, 2012 at 04:34:20PM +0100, Anton Shterenlikht wrote: On Tue, May 22, 2012 at 04:28:45PM +0200, Alberto Villa wrote: On Tue, May 22, 2012 at 4:21 PM, Anton Shterenlikht me...@bristol.ac.uk wrote: Track shlibs: yes bapt@ or whoever will track this bug: this is the problem I had with graphics/dri which you were unable to reproduce. Anton: can you please try rebuilding the package with track shlibs feature off? Yes, this works: install-info --quiet /usr/local/info/gmp.info /usr/local/info/dir === Running ldconfig /sbin/ldconfig -m /usr/local/lib === Registering installation for gmp-5.0.5 Installing gmp-5.0.5... done === Cleaning for gmp-5.0.5 === Re-installation of gmp-5.0.5 succeeded -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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 Can you please add an issue about it on our github? https://github.com/pkgng/pkgng ? regards, Bapt pgpbXYtskvKWj.pgp Description: PGP signature
Re: TeXLive merge into FreeBSD ports tree - is this going to happen or not?
On 05/26/2012 11:33 AM, Nikola Lečić wrote: On Sat, 26 May 2012 10:38:18 -0500, Stephen Montgomery-Smith wrote: On 05/26/2012 09:19 AM, Nikola Lečić wrote: This is what I have done, and it has worked very well - except the xdvi program that came with texlive was linked to a different version of the xorg libraries! [...] P.S. How did I solve the xdvi problem? I installed texlive from the texlive web site. Then I installed the FreeBSD print/teTeX port. Then I set PATH so that it picked up most of the commands from /usr/local/texlive/bin, but picked up xdvi from /usr/local/bin. I know it is an ugly hack. Please read this document: http://anthesphoria.net/FreeBSD/TeXLive-2011/bin/README.txt TeX Live FreeBSD binaries are a compromise between portability and easiness to resolve problems in cases such as yours. We did a lot of work over the last 3 years (minimalistic compiler options, customised perl binaries/libs...) to reduce the number of shared libraries dependencies as much as possible. The result: the installer, package manager and ca. 350 non-graphic utilities work for all FreeBSD=7. If you use asymptote, xdvi or xindy (compiled with clisp) on FreeBSD7, simply install misc/compat7. Best, Nikola (maintainer of TeX Live for FreeBSD) Do you have instructions for how to build customized texlive binaries? Then we could create a port that creates amd64-freebsd-tl2011.tar.xz or i386-freebsd-tl2011.tar.xz. ___ 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: libX11 and clang: compile error
On 5/26/12, Mel Flynn rfl...@acsalaska.net wrote:
On 26-5-2012 19:17, Oliver Pinter wrote:
I think src.conf is relevant, while it changes the system behavior, as
changed the default cc from gcc-4.2 to clang.
Thinking it doesn't make it so. Run:
grep _WITHOUT_SRCCONF /usr/share/mk/*.mk
Then investigate.
Setting CC in /etc/src.conf has *no effect on CC passed to the ports*.
Really. It does not.
The file that can do that is /etc/make.conf.
Another way is setting CC in your environment variables, through
/etc/login.conf, /etc/yourshellrc ~/.profile ~/.[cz]?shrc and what not.
In order to debug your issue, you should provide the output of what make
thinks CC and CPP are and backtrack where they are set.
Start with:
make -C /usr/ports/x11/libX11 -V CC -V CPP
--
Mel
After setting WITH_CLANG_IS_CC in src.conf the base system cc,cpp and
c++ has changed:
op@opn ~ cc --version
FreeBSD clang version 3.1 (branches/release_31 155985) 20120503
Target: x86_64-unknown-freebsd9.0
Thread model: posix
op@opn ~ cpp --version
FreeBSD clang version 3.1 (branches/release_31 155985) 20120503
Target: x86_64-unknown-freebsd9.0
Thread model: posix
op@opn ~ c++ --version
FreeBSD clang version 3.1 (branches/release_31 155985) 20120503
Target: x86_64-unknown-freebsd9.0
Thread model: posix
This is the new behavior after this patch:
commit 61fe77c5c9eb33f033bd89d869b05ce6dcd5fd5f
Author: dim dim@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Date: Sat Mar 17 22:29:05 2012 +
MFC 232322:
Add a WITH_CLANG_IS_CC option for src.conf(5), disabled by default, that
installs clang as /usr/bin/cc, /usr/bin/c++ and /usr/bin/cpp.
Note this does *not* disable building and installing gcc, which will
still be available as /usr/bin/gcc, /usr/bin/g++ and /usr/bin/gcpp. If
you want to disable gcc completely, you must use WITHOUT_GCC.
MFC 232323:
Regenerate src.conf(5) after r232322.
MFC 232323:
Regenerate src.conf(5) after r232322.
MFC 232477:
In r232322, I forgot one case where a check for MK_CLANG_IS_CC was
needed, in sys/conf/kern.pre.mk. Add it now.
MFC 232522:
Fix a thinko in r232322, where gcc (and its tools) are not built during
the cross-tools stage, if CC=clang and WITH_CLANG_IS_CC is not set.
This causes no 'cc' to be installed in the temporary cross-tools tree,
making lint fall over later in the build, because it ignores ${CC} and
attempts to run 'cc' anyway.
To fix this, only skip building gcc during cross-tools, if WITHOUT_GCC
is set, or if WITH_CLANG_IS_CC is set.
Pointy hat to:dim
git-svn-id: svn://svn.freebsd.org/base/stable/9@233099 ccf9f872-aa2e-dd11-9f
Script started on Sat May 26 20:38:09 2012
op has logged on :0 from local.
[1mroot[m@[4mopn[24m libX11# make extract
=== License MIT accepted by the user
=== Extracting for libX11-1.4.4,1
= SHA256 Checksum OK for xorg/lib/libX11-1.4.4.tar.bz2.
[1mroot[m@[4mopn[24m libX11# make 0[K-C
/usr/local/[K[K[K[K[K[Kports/x
x11-clocks/ x11-fm/ x11-servers/ x11-toolkits/ x11/
x11-drivers/ x11-fonts/x11-themes/ x11-wm/
[1mroot[m@[4mopn[24m libX11# make -C /usr/ports/x11/li
libICE/ libXprintUtil/ libgnomekbd/
libSM/ libXrandr/ libgnomemm/
libX11/ libXrender/ libgnomemm26/
libXScrnSaver/ libXres/ libkonq/
libXTrap/libXtrans/ liboldX/
libXau/ libXtst/ libsx/
libXcomposite/ libXv/ libsynaptics/
libXcursor/ libXvMC/ libxcb/
libXdamage/ libXxf86dga/ libxdg-basedir/
libXdmcp/libXxf86misc/libxfce4menu/
libXevie/libXxf86vm/ libxfce4util/
libXext/ libdmx/ libxkbfile/
libXfixes/ libdnd/ libxkbui/
libXi/ libexo/ libxklavier/
libXinerama/ libfm/ linux-f10-xorg-libs/
libXp/ libgnome-java/ linux-f8-xorg-libs/
libXpm/ libgnome-reference/ linux-xorg-libs/
libXprintAppUtil/libgnome/listres/
[1mroot[m@[4mopn[24m libX11# make -C /usr/ports/x11/libX
libX11/ libXdmcp/ libXpm/ libXtst/
libXScrnSaver/libXevie/ libXprintAppUtil/ libXv/
libXTrap/ libXext/ libXprintUtil/libXvMC/
libXau/ libXfixes/libXrandr/libXxf86dga/
libXcomposite/libXi/libXrender/ libXxf86misc/
libXcursor/ libXinerama/ libXres/ libXxf86vm/
libXdamage/ libXp/libXtrans/
[1mroot[m@[4mopn[24m libX11# make -C /usr/ports/x11/libX11/ -V CC -C[KV
CPP
cc
cpp
[1mroot[m@[4mopn[24m libX11# make -C /usr/ports/x11/libX11/ -V CC -V
Re: libX11 and clang: compile error
On 5/26/12, Oliver Pinter oliver.p...@gmail.com wrote:
On 5/26/12, Mel Flynn rfl...@acsalaska.net wrote:
On 26-5-2012 19:17, Oliver Pinter wrote:
I think src.conf is relevant, while it changes the system behavior, as
changed the default cc from gcc-4.2 to clang.
Thinking it doesn't make it so. Run:
grep _WITHOUT_SRCCONF /usr/share/mk/*.mk
Then investigate.
Setting CC in /etc/src.conf has *no effect on CC passed to the ports*.
Really. It does not.
The file that can do that is /etc/make.conf.
Another way is setting CC in your environment variables, through
/etc/login.conf, /etc/yourshellrc ~/.profile ~/.[cz]?shrc and what not.
In order to debug your issue, you should provide the output of what make
thinks CC and CPP are and backtrack where they are set.
Start with:
make -C /usr/ports/x11/libX11 -V CC -V CPP
--
Mel
After setting WITH_CLANG_IS_CC in src.conf the base system cc,cpp and
c++ has changed:
op@opn ~ cc --version
FreeBSD clang version 3.1 (branches/release_31 155985) 20120503
Target: x86_64-unknown-freebsd9.0
Thread model: posix
op@opn ~ cpp --version
FreeBSD clang version 3.1 (branches/release_31 155985) 20120503
Target: x86_64-unknown-freebsd9.0
Thread model: posix
op@opn ~ c++ --version
FreeBSD clang version 3.1 (branches/release_31 155985) 20120503
Target: x86_64-unknown-freebsd9.0
Thread model: posix
This is the new behavior after this patch:
commit 61fe77c5c9eb33f033bd89d869b05ce6dcd5fd5f
Author: dim dim@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Date: Sat Mar 17 22:29:05 2012 +
MFC 232322:
Add a WITH_CLANG_IS_CC option for src.conf(5), disabled by default,
that
installs clang as /usr/bin/cc, /usr/bin/c++ and /usr/bin/cpp.
Note this does *not* disable building and installing gcc, which will
still be available as /usr/bin/gcc, /usr/bin/g++ and /usr/bin/gcpp.
If
you want to disable gcc completely, you must use WITHOUT_GCC.
MFC 232323:
Regenerate src.conf(5) after r232322.
MFC 232323:
Regenerate src.conf(5) after r232322.
MFC 232477:
In r232322, I forgot one case where a check for MK_CLANG_IS_CC was
needed, in sys/conf/kern.pre.mk. Add it now.
MFC 232522:
Fix a thinko in r232322, where gcc (and its tools) are not built
during
the cross-tools stage, if CC=clang and WITH_CLANG_IS_CC is not set.
This causes no 'cc' to be installed in the temporary cross-tools
tree,
making lint fall over later in the build, because it ignores ${CC}
and
attempts to run 'cc' anyway.
To fix this, only skip building gcc during cross-tools, if
WITHOUT_GCC
is set, or if WITH_CLANG_IS_CC is set.
Pointy hat to:dim
git-svn-id: svn://svn.freebsd.org/base/stable/9@233099
ccf9f872-aa2e-dd11-9f
op@opn ~ less /tmp/failed-configure-test
Does cpp preserve whitespace?
_ACEOF
if test `${RAWCPP} conftest.$ac_ext | grep -c 'preserve \'` -eq 1 ; then
{ $as_echo $as_me:${as_lineno-$LINENO}: result: no 5
$as_echo no 6; }
else
if test `${RAWCPP} -traditional conftest.$ac_ext | grep -c
'preserve \'` -eq 1 ; then
RAWCPPFLAGS=${RAWCPPFLAGS} -traditional
{ $as_echo $as_me:${as_lineno-$LINENO}: result: yes 5
$as_echo yes 6; }
else
as_fn_error $? ${RAWCPP} does not preserve whitespace
with or without -traditional. I don't know what to do. $LINENO 5
fi
fi
rm -f conftest.$ac_ext
and the bad news, this failed in xorg-server too and in most xorg related ports
___
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: libX11 and clang: compile error
On 5/26/12, Mel Flynn rfl...@acsalaska.net wrote:
On 26-5-2012 20:40, Oliver Pinter wrote:
On 5/26/12, Mel Flynn rfl...@acsalaska.net wrote:
On 26-5-2012 19:17, Oliver Pinter wrote:
I think src.conf is relevant, while it changes the system behavior, as
changed the default cc from gcc-4.2 to clang.
Thinking it doesn't make it so. Run:
grep _WITHOUT_SRCCONF /usr/share/mk/*.mk
Then investigate.
Setting CC in /etc/src.conf has *no effect on CC passed to the ports*.
Really. It does not.
The file that can do that is /etc/make.conf.
Another way is setting CC in your environment variables, through
/etc/login.conf, /etc/yourshellrc ~/.profile ~/.[cz]?shrc and what not.
In order to debug your issue, you should provide the output of what make
thinks CC and CPP are and backtrack where they are set.
Start with:
make -C /usr/ports/x11/libX11 -V CC -V CPP
--
Mel
After setting WITH_CLANG_IS_CC in src.conf the base system cc,cpp and
c++ has changed:
See ports/166373.
Also, the fact that your /usr/bin/cpp == clang-cpp is relevant!
Especially if you report:
Somewhere in config* or Makefile are a hardcoded /usr/bin/cpp ...
--
Mel
this is a workaround, see the attached file
--- work/libX11-1.4.4/configure.orig 2012-05-26 21:04:29.0 +0200
+++ work/libX11-1.4.4/configure 2012-05-26 21:04:58.0 +0200
@@ -12808,22 +12808,22 @@
$as_echo_n checking if $RAWCPP requires -traditional... 6; }
cat confdefs.h - _ACEOF conftest.$ac_ext
/* end confdefs.h. */
-Does cpp preserve whitespace?
-_ACEOF
-if test `${RAWCPP} conftest.$ac_ext | grep -c 'preserve \'` -eq 1 ; then
- { $as_echo $as_me:${as_lineno-$LINENO}: result: no 5
-$as_echo no 6; }
-else
- if test `${RAWCPP} -traditional conftest.$ac_ext | grep -c 'preserve \'` -eq 1 ; then
- RAWCPPFLAGS=${RAWCPPFLAGS} -traditional
- { $as_echo $as_me:${as_lineno-$LINENO}: result: yes 5
-$as_echo yes 6; }
- else
- as_fn_error $? ${RAWCPP} does not preserve whitespace with or without -traditional. I don't know what to do. $LINENO 5
- fi
-fi
-rm -f conftest.$ac_ext
-
+#Does cpp preserve whitespace?
+#_ACEOF
+#if test `${RAWCPP} conftest.$ac_ext | grep -c 'preserve \'` -eq 1 ; then
+# { $as_echo $as_me:${as_lineno-$LINENO}: result: no 5
+#$as_echo no 6; }
+#else
+# if test `${RAWCPP} -traditional conftest.$ac_ext | grep -c 'preserve \'` -eq 1 ; then
+# RAWCPPFLAGS=${RAWCPPFLAGS} -traditional
+# { $as_echo $as_me:${as_lineno-$LINENO}: result: yes 5
+#$as_echo yes 6; }
+# else
+# as_fn_error $? ${RAWCPP} does not preserve whitespace with or without -traditional. I don't know what to do. $LINENO 5
+# fi
+#fi
+#rm -f conftest.$ac_ext
+#
___
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: libX11 and clang: compile error
On 26-5-2012 20:40, Oliver Pinter wrote: On 5/26/12, Mel Flynn rfl...@acsalaska.net wrote: On 26-5-2012 19:17, Oliver Pinter wrote: I think src.conf is relevant, while it changes the system behavior, as changed the default cc from gcc-4.2 to clang. Thinking it doesn't make it so. Run: grep _WITHOUT_SRCCONF /usr/share/mk/*.mk Then investigate. Setting CC in /etc/src.conf has *no effect on CC passed to the ports*. Really. It does not. The file that can do that is /etc/make.conf. Another way is setting CC in your environment variables, through /etc/login.conf, /etc/yourshellrc ~/.profile ~/.[cz]?shrc and what not. In order to debug your issue, you should provide the output of what make thinks CC and CPP are and backtrack where they are set. Start with: make -C /usr/ports/x11/libX11 -V CC -V CPP -- Mel After setting WITH_CLANG_IS_CC in src.conf the base system cc,cpp and c++ has changed: See ports/166373. Also, the fact that your /usr/bin/cpp == clang-cpp is relevant! Especially if you report: Somewhere in config* or Makefile are a hardcoded /usr/bin/cpp ... -- Mel ___ 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
More Heimdal 1.5.2 port problems
I've found another problem with the port. kadmind and kdc both look for krb5.conf in /usr/local/etc, but kpasswdd and kstash look for it in /etc. This can be fixed with a symlink, but I feel like that's not the best solution. Ultimately, all the heimdal utilities and daemons should be looking in the same location for krb5.conf, correct? I don't see any flags for kstash or kpasswdd to change where they look for krb5.conf. I'm going to go back and compile it from source again and see if there is another configure flag that is missing from the port. ___ 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: qzeitgeist failed to compile on FreeBSD 9-STABLE
Quentin Schwerkolt develloper.u...@hotmail.fr writes: //Path to a program. AUTOMOC4_EXECUTABLE:FILEPATH=AUTOMOC4_EXECUTABLE-NOTFOUND //The directory containing a CMake configuration file for Automoc4. Automoc4_DIR:PATH=/usr/lib64/automoc4 What are the contents of your /usr/lib64? I wonder what automoc is doing there. ___ 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: qzeitgeist failed to compile on FreeBSD 9-STABLE
/usr/lib64 is a symbolic link to /usr/locale/lib. On 05/26/12 21:22, Raphael Kubo da Costa wrote: Quentin Schwerkolt develloper.u...@hotmail.fr writes: //Path to a program. AUTOMOC4_EXECUTABLE:FILEPATH=AUTOMOC4_EXECUTABLE-NOTFOUND //The directory containing a CMake configuration file for Automoc4. Automoc4_DIR:PATH=/usr/lib64/automoc4 What are the contents of your /usr/lib64? I wonder what automoc is doing there. ___ 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 signature.asc Description: OpenPGP digital signature
Re: qzeitgeist failed to compile on FreeBSD 9-STABLE
On Sat, May 26, 2012 at 9:39 PM, Quentin Schwerkolt develloper.u...@hotmail.fr wrote: /usr/lib64 is a symbolic link to /usr/locale/lib. Can you put the attached patch into /usr/ports/devel/automoc4/files, rebuild automoc4 and retry with qzeitgeist? -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla patch-Automoc4Config.cmake Description: Binary data ___ 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: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
Le 26.05.2012 18:41, Rainer Hurling a écrit :
On 26.05.2012 17:49 (UTC+2), coder.tuxfamily wrote:
Le 25.05.2012 22:49, Rainer Hurling a écrit :
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the
ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13 {} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig ports
can coexist in principle, only some docs share the same places (which
should be changed, of course).
Maybe you're right. I've see on trac.osgeo.org that it uses swig-1.3.40.
I will try without specify version of swig.
I saw in the news on http://www.swig.org/, that swig 2.0.6 is out with
many bug fixes and enhancements for templates and target languages like
php and python. Perhaps swig 2.0.6 is ready now for gdal?
I just checked, that swig 1.3.40 and 2.0.4 should be able to coexist at
the same time. At least they do not share any filenames.
___
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
Ruby option seems have also a problem with SWIG.
PGSQL conflict with ssl.
I need to add condition between podofo and poppler.
___
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: TeXLive merge into FreeBSD ports tree - is this going to happen or not?
On Sat, 26 May 2012 13:05:26 -0500, Stephen Montgomery-Smith wrote: Do you have instructions for how to build customized texlive binaries? Then we could create a port that creates amd64-freebsd-tl2011.tar.xz or i386-freebsd-tl2011.tar.xz. All the work I mentioned is integrated into the TeX Live source tree, except for the two binaries, biber and xindy. Currently it is not possible to build biber within FreeBSD ports (see below). I'd recommend a separate port for xindy (see below). Therefore, just build the TeX Live source with --disable-xindy. You don't need --disable-biber (see below why). Besides obvious dependencies, such a wrapper port should include a dependency on x11-toolkits/p5-Tk, to enable install-tl/tlmgr GUI. As for biber and xindy: biber: biber is built with a huge number of not-yet-ported and newer-than-ported brand new perl modules. Then they are packed with PAR::Packer into a huge ~15M binary. Therefore it's currently not possible to build biber within FreeBSD ports. Please note that compiling TeX Live source *will* install a biber binary, however this binary is not built, it's simply a copy of the binary that I provide through the CTAN biber distribution. The wrapper port could do the same, i.e. use the binaries from the CTAN, through TeX Live build. Please take a look: http://sourceforge.net/projects/biblatex-biber/files/biblatex-biber/0.9.9/binaries/FreeBSD/ The binaries without FreeBSD release number run are portable, and run on __FreeBSD_version=701000. Biber is important because it is going to replace BibTeX as biblatex backend at some point in the future. (If you are anyway interested in what is needed to create biber binaries without ports, let me know.) xindy: I have clisp built with --with-ffcall --without-readline --disable-nls. However, this is not enough and the resulting binary is not portable. Therefore, it would be better to create a normal port for xindy. -- Nikola Lečić = Никола Лечић fingerprint : FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B ___ 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
Imagemagick: FAIL: Magick++/tests/averageImages.sh
What would be helpful to diagnose this? I'm on current r236118 Doug -- This .signature sanitized for your protection ___ 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
Imagemagick: FAIL: Magick++/tests/averageImages.sh
Doug Barton writes: What would be helpful to diagnose this? I'm on current r236118 I'm getting failures on tests also, whether I use clang, gcc42 of gcc46. (System: FreeBSD 10.0-CURRENT #0: Sun Mar 11 08:20:02 EDT 2012 amd64 ) Robert Huff ___ 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: Imagemagick: FAIL: Magick++/tests/averageImages.sh
On Sat, May 26, 2012 at 10:16:11PM -0400, Robert Huff wrote: Doug Barton writes: What would be helpful to diagnose this? I'm on current r236118 I'm getting failures on tests also, whether I use clang, gcc42 of gcc46. (System: FreeBSD 10.0-CURRENT #0: Sun Mar 11 08:20:02 EDT 2012 amd64 ) As a matter of fact I have had failures on 1-3 of the tests that have run for quite some time. I turned them off -- no problem. I must not be using the functionality that the tests were testing for so I really don't care. If something breaks or isnt working right... and uses Magick++ then it might be time to look into it then but I have not seen any significant failure just due to them failing. -- - (2^(N-1)) pgpAadmnThjnV.pgp Description: PGP signature
