Re: zsh-4.3.4-doc Bug when creating the pdf, html doc?
I tried to reproduce the same trouble but it seems to be gone. I guess i may have done somethings wrong before. Anyway, the docs seems to be right at all. I'm sorry for this, please ignore my previous message. Btw is zsh and zsh-4.3.4 been expected to be in /usr/bin/ ? I moved these to /bin/. Kind regards, David Van Mosselbeen -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: zsh-4.3.4-doc Bug when creating the pdf, html doc?
Hi David, On Fri, Nov 09, at 11:22 David Van Mosselbeen wrote: Is there's an error in the zsh-4.3.4-doc install process. The part texi2pdf Doc/zsh.texi -o Doc/zsh.pdf. We first need to create the directory Doc/zsh.pdf/ in the source tree. Otherwise it's not able to create the final Doc/zsh.pdf/zsh.pdf file. Same goes for the other docs. Someone aware and tested this? I tested the commands and I can't reproduce the behavior you are describing. By the way, the generated docs are the same with the precompiled documentation (zsh-dev-doc.tar.bz2 [1]), so there are no really need to regenerate them (for those that don't have tetex installed). Another thing that I am interesting, is to update the book to the development version (see ticket #2360 [2]). So, if you or anyone else have any opinion (to update or not to the dev version) or just to give feedback for this release, please comment in that ticket. [1]. ftp://ftp.zsh.org/zsh/zsh-dev-doc.tar.bz2 [2]. http://wiki.linuxfromscratch.org/blfs/ticket/2360 -- http://wiki.linuxfromscratch.org/blfs/wiki/Hacking -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: zsh-4.3.4-doc Bug when creating the pdf, html doc?
On Sat, Nov 10, at 12:18 David Van Mosselbeen wrote: I tried to reproduce the same trouble but it seems to be gone. I guess i may have done somethings wrong before. Anyway, the docs seems to be right at all. I'm sorry for this, please ignore my previous message. Btw is zsh and zsh-4.3.4 been expected to be in /usr/bin/ ? Yes, according with the prefix. I moved these to /bin/. If you want to be in /bin using the normal procedure, you can use the --bindir=/bin switch. Maybe it's the right thing to do actually. What will be happen, if the /usr is in another partition? Wait, from the ldd output, I think we can safely use the --bindir=/bin switch (all the dependent libraries are on /lib). Feedback and testing is welcome. -- http://wiki.linuxfromscratch.org/blfs/wiki/Hacking -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Problem with OO and JDK
Le Fri, 9 Nov 2007 15:30:18 +0100 Alessandro Alocci
[EMAIL PROTECTED] a écrit :
Hi, it seems that you have uudecode installed, can you check if you have the
version installed from gmime?
Run uudecode --version
if you see something like
uudecode (GNU sharutils) x.x.x
then my guess is wrong, just ignore the rest of my mail.
If you see
uudecode - GMime x.x.x
this can be the problem.
You can try this:
-) move your {uudecode,uuencode} to so something like
{gmime-uudecode,gmime-uuencode}
-) Reinstall sharutils if you have installed it previously and gmime had
overwrited uu{decode,encode}
You should see this problem also if you try to recompile berkeleydb, so you
can use this package to see if the workaround works instead of using OO.
HTH, AA
OK, this worked, Alessandro. Amazing how right you pointed my problem :-)
Now, I have another problem, later :
/sources/OOG680_m5/canvas/source/cairo
--
Making: ../../unxlngi6.pro/slo/cairo_cairo.obj
g++ -fmessage-length=0 -c -Os -fno-strict-aliasing -DPNG_NO_MMX_CODE
-I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -I.
-I../../unxlngi6.pro/inc/cairocanvas -I../inc -I../../inc/pch -I../../inc
-I../../unx/inc -I../../unxlngi6.pro/inc -I.
-I/sources/OOG680_m5/solver/680/unxlngi6.pro/inc/stl
-I/sources/OOG680_m5/solver/680/unxlngi6.pro/inc/external
-I/sources/OOG680_m5/solver/680/unxlngi6.pro/inc
-I/sources/OOG680_m5/solenv/unxlngi6/inc -I/sources/OOG680_m5/solenv/inc
-I/sources/OOG680_m5/res -I/sources/OOG680_m5/solver/680/unxlngi6.pro/inc/stl
-I/sources/OOG680_m5/solenv/inc/Xp31 -I/opt/jdk/include
-I/opt/jdk/include/linux -I/opt/jdk/include/native_threads/include
-I/usr/include -I/sources/OOG680_m5/solver/680/unxlngi6.pro/inc/offuh -I.
-I../../res -I. -pipe -mtune=pentiumpro -fvisibility-inlines-hidden -Wall
-Wextra -Wendif-labels -Wshadow -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -fpic -DLINUX -DUNX -DVCL -DGCC -DC341 -DINTEL
-DCVER=C341 -DNPTL -DGLIBC=2 -DX86 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR
-D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -DHAVE_GCC_VISIBILITY_FEATURE
-D__DMAKE -DUNIX -DCPPU_ENV=gcc3
-DGXX_INCLUDE_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../include/c++/4.2.1
-DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE
-DCUI -DSOLAR_JAVA -DOOG680=OOG680 -DSHAREDLIB -D_DLL_ -fexceptions
-fno-enforce-eh-specs -DEXCEPTIONS_ON -o ../../unxlngi6.pro/slo/cairo_cairo.o
/sources/OOG680_m5/canvas/source/cairo/cairo_cairo.cxx
/sources/OOG680_m5/canvas/source/cairo/cairo_cairo.cxx: In member function
'cairo::Surface* cairo::Surface::getSimilar(cairo::Content, int, int)':
/sources/OOG680_m5/canvas/source/cairo/cairo_cairo.cxx:202: error:
'PictStandardA8' was not declared in this scope
/sources/OOG680_m5/canvas/source/cairo/cairo_cairo.cxx:205: error:
'PictStandardRGB24' was not declared in this scope
/sources/OOG680_m5/canvas/source/cairo/cairo_cairo.cxx:209: error:
'PictStandardARGB32' was not declared in this scope
/sources/OOG680_m5/canvas/source/cairo/cairo_cairo.cxx:213: error:
'XRenderFindStandardFormat' was not declared in this scope
dmake: Error code 1, while making '../../unxlngi6.pro/slo/cairo_cairo.obj'
---* tg_merge.mk *---
ERROR: Error 65280 occurred while making /sources/OOG680_m5/canvas/source/cairo
dmake: Error code 1, while making 'build_instsetoo_native'
---* *---
Can you explain this one ? I know you can ;-)
\bye
--
Nicolas FRANCOIS
http://nicolas.francois.free.fr
A TRUE Klingon programmer does NOT comment his code
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: your ssh / sshd config
Hi there... [As too often: Sorry for the late reply.] randd wrote: [Unable to start X applications in a chroot] You certainly can still do what you're wanting to; what's changed is the defaults in the SSH server config. There are a number of machines here that are headless and only accessible via X. What has ssh got to do with it? ... From the way I read your previous post(s), I thought you were doing something like this: Host A: $ ssh hostB (hostB)$ xclock [ a lot of can't open display ... errors] Or on host B: $ export DISPLAY=hostA:0 $ xclock [ errors r.e. can't open display hostA:0 instead ] [of a clock appearing on host A's display ] etc.; there are a number of different ways to do this similar things; I'm sure you catch the drift of what I was thinking / suggesting. Doesn't sound like any of them are applicable in your case though. About a year ago after I upgraded to a newer openSSH and discovered that I couldn't run apps on another host and have their output render on mine (etc.) I ended up delving into the ssh config files and figuring out how to get everything working the way that I wanted it to, again. In any event, I only caught one post of yours, which, when I read it, sounded like this was what you were running into. I'm quite curious now w/ respect to what, exactly, the problem you were having, was; I'll have to go back and re-read your previous post later on (I'm working on a different machine than the one I download messages from this newsgroup to). Just to make sure, everything's working the way you want it to at this point? - Larry -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Problem with OO and JDK
On Saturday 10 November 2007 14:20:22 Nicolas FRANCOIS wrote: /sources/OOG680_m5/canvas/source/cairo/cairo_cairo.cxx:202: error: 'PictStandardA8' was not declared in this scope /sources/OOG680_m5/canvas/source/cairo/cairo_cairo.cxx:205: error: 'PictStandardRGB24' was not declared in this scope /sources/OOG680_m5/canvas/source/cairo/cairo_cairo.cxx:209: error: 'PictStandardARGB32' was not declared in this scope /sources/OOG680_m5/canvas/source/cairo/cairo_cairo.cxx:213: error: 'XRenderFindStandardFormat' was not declared in this scope dmake: Error code 1, while making '../../unxlngi6.pro/slo/cairo_cairo.obj' ---* tg_merge.mk *--- Hi Nicolas, the various PictStandard* and XRenderFindStandardFormat are defined in Xrender.h For example: [EMAIL PROTECTED] ~$ grep PictStandard /usr/include/X11/extensions/Xrender.h #define PictStandardARGB32 0 #define PictStandardRGB24 1 #define PictStandardA8 2 #define PictStandardA4 3 #define PictStandardA1 4 #define PictStandardNUM 5 [EMAIL PROTECTED] ~$ grep XRenderFindStandardFormat -A1 \ /usr/include/X11/extensions/Xrender.h XRenderFindStandardFormat (Display *dpy, int format); The problem seems to be that OO use by default an internal Xrender.h file without these definitions. So, it seems that you are obliged to use the switch --with-system-xrender-headers if you want to compile OO with --enable-cairo (At least, I had the same problem with OO-2.2.1) Bye, AA -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: your ssh / sshd config
randd wrote: etc.; there are a number of different ways to do this similar things; I'm sure you catch the drift of what I was thinking / suggesting. Doesn't sound like any of them are applicable in your case though. Yes. Apologies for not making it clearer. Let's try again: HostA:xterm1$ xhost +localhost HostA:xterm2$ chroot $LFS/bin/bash HostA:chroot$ export DISPLAY=:0.0 HostA:chroot$ xterm xterm Xt error: Can't open display: :0.0 HostA:chroot$ export DISPLAY=HostB:0.0 HostB:xterm3$ xhost +HostA HostA:chroot$ xterm [works perfectly] Just to make sure, everything's working the way you want it to at this point? Alas, no. I used the different host approach today, but while a 'make test' of PMW (Python Megawidgets) was running, HostB died horribly. No idea whether it had something to do with the test, but the machine froze completely. So, not even that did really work. BTW, ssh does work for me, no problem with that. Regards, Hans-Joachim -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Problem with OO and JDK
Le Sat, 10 Nov 2007 17:11:21 +0100 Alessandro Alocci [EMAIL PROTECTED] a écrit : The problem seems to be that OO use by default an internal Xrender.h file without these definitions. So, it seems that you are obliged to use the switch --with-system-xrender-headers if you want to compile OO with --enable-cairo (At least, I had the same problem with OO-2.2.1) It worked. Thank you very much again, Alessabdro. This build is very complex, your help was unvaluable. May the great white penguin bless you ;-) \bye -- Nicolas FRANCOIS http://nicolas.francois.free.fr A TRUE Klingon programmer does NOT comment his code -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
