Re: lesstif doesn't find Xrender by default
Andreas Turriff wrote: > Guy Dalziel wrote: > >> Matthew Burgess wrote: >> >> >>> Using the book's default instructions, I get the following output in the >>> run of ./configure for lesstif-0.95.0... >>> >>> Checking X11/extensions/Xrender.h usability... no >>> Checking X11/extensions/Xrender.h presence... no >>> >>> >> The same problem does indeed occur on my system, however it is not >> "broken" as a result of it. >> >> > I had the same thing. > Has this been addressed? I don't have the issue, but X is not in /usr for me. On a default run, what does the "checking for X" message produce? checking for X... libraries /opt/X11/lib, headers /opt/X11/include checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking whether gethostname() is available... yes checking for Xt Revision Number 6... revision 6 checking whether libXp is available... no checking whether to link -lXp... no checking for Motif... no checking whether libXt was compiled with -DXTHREADS... yes checking for lynx... no checking for links... no checking for suitable man2html... checking for man2html... no checking whether to build the tests... no checking for freetype-config... freetype-config checking for freetype/freetype.h... yes checking for FT_Init_FreeType... yes checking X11/extensions/Xrender.h usability... yes checking X11/extensions/Xrender.h presence... yes checking for X11/extensions/Xrender.h... yes checking for XRenderParseColor... yes checking for fontconfig-config... no checking fontconfig/fontconfig.h usability... yes checking fontconfig/fontconfig.h presence... yes checking for fontconfig/fontconfig.h... yes checking for FcInit... yes configure: creating ./config.status -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xorg depends on openssl?
On Sun, Jan 4, 2009 at 4:05 PM, bob foltrigg wrote: >> I think the first thing most people install is ssl/ssh so you c/an ssh into >> the >> box and run additional builds from another workstation that has a gui. > > I believe that with the advent of all these virtualization platforms > out there, this is not necessarily true, cf. my actual case. > >> >> That said, I think you are right about ssl being needed for xorg-server. In >> configure is the comment: >> >> # OpenSSL used for SHA1 hashing in render/glyph.c, but we don't need all of >> # the OpenSSL libraries, just libcrypto >> >> If you logged the configure command, look for the message: >> error: Package requirements (openssl) were not met: ... >> >> I'm surprised that configure didn't fail. > > Bugs me too, tho I'm not an autoconf guru... Anyways the actual output > of configure didn't mention anything related to openssl but config.log > has this: There had been numerous attempts to "fix" the detection of a sha1 library since one exists in different libraries on different platforms. It sounds like it's still not working quite right. Know that you probably do want the openssl version since libcrypto is optimized for many different architectures. For instance, on x86 it is an optimized assembler routine. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: kelibs 3-5.10 again
Bruce Dubbs wrote: > I got kdelibs to build, but the 'make apidocs' command hangs on me in the > kdeprint subdirectory. Has anyone else seen this? s/apidocs/apidox/ Yes, it still hangs. >-- Bruce > -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xorg depends on openssl?
> I think the first thing most people install is ssl/ssh so you c/an ssh into > the > box and run additional builds from another workstation that has a gui. I believe that with the advent of all these virtualization platforms out there, this is not necessarily true, cf. my actual case. > > That said, I think you are right about ssl being needed for xorg-server. In > configure is the comment: > > # OpenSSL used for SHA1 hashing in render/glyph.c, but we don't need all of > # the OpenSSL libraries, just libcrypto > > If you logged the configure command, look for the message: > error: Package requirements (openssl) were not met: ... > > I'm surprised that configure didn't fail. Bugs me too, tho I'm not an autoconf guru... Anyways the actual output of configure didn't mention anything related to openssl but config.log has this: configure:33092: $PKG_CONFIG --exists --print-errors "openssl" Package openssl was not found in the pkg-config search path. Perhaps you should add the directory containing 'openssl.pc' to the PKG_CONFIG_PATH environment variable No package 'openssl' found configure:33095: $? = 1 configure:33256: checking if SVR4 needs to be defined Of course I'd been better off installing ssh beforehand, so I hadn't had to type above lines instead of copy-pasting. J Sorry if I was overly proactive with this. -Bob. > > -- Bruce > -- > http://linuxfromscratch.org/mailman/listinfo/blfs-dev > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
kelibs 3-5.10 again
I got kdelibs to build, but the 'make apidocs' command hangs on me in the kdeprint subdirectory. Has anyone else seen this? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xorg depends on openssl?
bob foltrigg wrote: > Hello, > > this is my first (b)lfs experiment so what I've found may not be a > genuine build-description-bug, but still, here it comes. > > I have a working LFS 6.4 setup, and am now building X, based on > chapter 23 of blfs-svn-20090103. Everything went fine and dandy until > compiling the server which produces this error in > xorg-server-1.5.3/render: > > > glyph.c:30:25: error: openssl/sha.h: No such file or directory > glyph.c: In function 'HashGlyph': > > make[1]: *** [glyph.lo] Error 1 > > > This can be resolved by installing openssl, so maybe this should be > added as a dependency? > > Note: I went straight to building X after I was able to boot into my > base LFS system, and installed only the required (and transitively > required) dependencies for the X components plus Mesa. I think the first thing most people install is ssl/ssh so you c/an ssh into the box and run additional builds from another workstation that has a gui. That said, I think you are right about ssl being needed for xorg-server. In configure is the comment: # OpenSSL used for SHA1 hashing in render/glyph.c, but we don't need all of # the OpenSSL libraries, just libcrypto If you logged the configure command, look for the message: error: Package requirements (openssl) were not met: ... I'm surprised that configure didn't fail. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
xorg depends on openssl?
Hello, this is my first (b)lfs experiment so what I've found may not be a genuine build-description-bug, but still, here it comes. I have a working LFS 6.4 setup, and am now building X, based on chapter 23 of blfs-svn-20090103. Everything went fine and dandy until compiling the server which produces this error in xorg-server-1.5.3/render: glyph.c:30:25: error: openssl/sha.h: No such file or directory glyph.c: In function 'HashGlyph': make[1]: *** [glyph.lo] Error 1 This can be resolved by installing openssl, so maybe this should be added as a dependency? Note: I went straight to building X after I was able to boot into my base LFS system, and installed only the required (and transitively required) dependencies for the X components plus Mesa. Can you help me sort out whether I've missed something? Thank you, -Bob. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Problem building kde libs
Alexander E. Patrakov wrote: > Bruce Dubbs wrote: >> Basically Petr's approach is to remove the following lines: ... >> and replace #include with #include >> where the above calls are defined. The functions are found in >> /lib/libc-2.8.so. > > Yes, that's the correct approach. Such inline functions were added to > programs in times where the kernel supported inotify, but glibc didn't. OK Alex. Thanks for the confirmation. I'll go with that. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Problem building kde libs
Bruce Dubbs wrote:
> Basically Petr's approach is to remove the following lines:
>
> static inline int inotify_init (void)
> {
>return syscall (__NR_inotify_init);
> }
>
> static inline int inotify_add_watch (int fd, const char *name, __u32 mask)
> {
>return syscall (__NR_inotify_add_watch, fd, name, mask);
> }
>
> static inline int inotify_rm_watch (int fd, __u32 wd)
> {
>return syscall (__NR_inotify_rm_watch, fd, wd);
> }
>
> and replace #include with #include
> where the above calls are defined. The functions are found in
> /lib/libc-2.8.so.
Yes, that's the correct approach. Such inline functions were added to
programs in times where the kernel supported inotify, but glibc didn't.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Problem building kde libs
I ran into a problem building kdelibs tonight and I'm not sure how to address
the problem. I got:
/bin/sh ../../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
-I. -I../.. -I../../dcop -I../../kdecore -I../../kio/kssl -I../../kjs -I../..
-I./.. -I../../kdecore/network -I./../kssl -I../kssl -I./../../interfaces
-I../../dcop -I../../libltdl -I../../kdefx -I../../kdecore -I../../kdecore
-I../../kdecore/network -I../../kdeui -I../../kio -I../../kio/kio
-I../../kio/kfile -I../.. -I/opt/qt/include -I. -I/opt/kde-3.5.10/include
-D_LARGEFILE64_SOURCE -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef
-ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W
-Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -Wformat-security
-Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new
-fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT
-DQT_NO_TRANSLATION -c -o libksycoca_la.all_cpp.lo libksycoca_la.all_cpp.cpp
In file included from /usr/include/asm/fcntl.h:1,
from /usr/include/linux/fcntl.h:4,
from /usr/include/linux/inotify.h:11,
from kdirwatch.cpp:74,
from libksycoca_la.all_cpp.cpp:2:
/usr/include/asm-generic/fcntl.h:117: error: redefinition of 'struct flock'
/usr/include/bits/fcntl.h:145: error: previous definition of 'struct flock'
/usr/include/asm-generic/fcntl.h:140: error: redefinition of 'struct flock64'
/usr/include/bits/fcntl.h:160: error: previous definition of 'struct flock64'
There was an earlier report of the same thing (Oct 30) by Petr Ovtchenkov:
http://linuxfromscratch.org/pipermail/blfs-dev/2008-October/018968.html
and a discussion on the kernel list (Sep 16/17):
http://patchwork.ozlabs.org/patch/316/
I'm not sure the fix by Petr Ovtchenkov is the right thing to do, but I can't
find anywhere where the kernel headers were changed after 2.6.27.4. I also
can't find any KDE bug filed that addresses the problem.
Basically Petr's approach is to remove the following lines:
static inline int inotify_init (void)
{
return syscall (__NR_inotify_init);
}
static inline int inotify_add_watch (int fd, const char *name, __u32 mask)
{
return syscall (__NR_inotify_add_watch, fd, name, mask);
}
static inline int inotify_rm_watch (int fd, __u32 wd)
{
return syscall (__NR_inotify_rm_watch, fd, wd);
}
and replace #include with #include
where the above calls are defined. The functions are found in /lib/libc-2.8.so.
Does anyone have any thoughts on this?
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: Proposed reorg of Chapter 35 - Multimedia Libraries and Drivers
Bruce Dubbs wrote: > I would like to propose a change to the organization of Multimedia Libraries > and > Drivers. I would like to see it divided into sections similar to the way > GNOME > Additional Packages is split into three sections. > > I would like to organize Chapter 35 into something like the list below. > > We might want to expand this to reorganize Chapters 36, Audio Utilities, > Chapter > 37, Video Utilities, and Chapter 38, CD/DVD-Writing Utilities. > > There is obviously multiple ways to reorganize these chapter(s). > Discussion is welcome. > >-- Bruce > > 35. Multimedia Low Level Packages > > Sound Servers > # Introduction (This describes the function of a sound server and why a user > would want to build one or more sound server. It would include mention of > MAS, > JACK, and PulseAudio. It would also discuss alsa vs oss.) > > # aRts-1.5.9 > # EsounD-0.2.40 > # NAS-1.9.1 Right, these are sound servers. > Low Level Sound Drivers and Utilities > # ALSA-1.0.18 > # ALSA Library-1.0.18 > # ALSA Plugins-1.0.18 > # ALSA Utilities-1.0.18 > # ALSA Tools-1.0.18 > # ALSA Firmware-1.0.17 > # ALSA OSS-1.0.17 Correct. This is also a place for OSS4. > Audio Libraries and CODECS IMHO libraries should be separated from CODECs. Since you managed to misclassify some packages (e.g., said that liba52 is a video codec), I propose my own classification below. > # SDL-1.2.13 > # Libao-0.8.8 These are output libraries that abstract platform differences from applications. > # libvorbis-1.2.0 > # FAAC-1.26 > # FAAD2-2.6.1 > # LibMPEG3-1.7 > # libmad-0.15.1b > # libFAME-0.9.1 > # Speex-1.0.5 > # FLAC-1.2.1 > # Libmikmod-3.1.11 > # Liba52-0.7.4 These are audio CODECs. > # libmusicbrainz-2.1.5 Unique creature, not sure where it belongs. > # Libdv-1.0.0 > # XviD-1.1.3 > # libtheora-1.0 > # libmpeg2-0.4.1 Video CODECs. > # libquicktime-1.0.0 > # libogg-1.1.3 > # Id3lib-3.8.3 Container and metadata modules. > # Xine Libraries-1.1.15 > # GStreamer-0.10.13 > # GStreamer Base Plug-ins-0.10.13 > # GStreamer Good Plug-ins-0.10.6 > # GStreamer Ugly Plug-ins-0.10.6 > # FFMpeg All-in-one multimedia frameworks. > > DVD Libraries > # libdvdcss-1.2.10 > # Libdvdread-0.9.7 We can classify these in some sense as container modules, too. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
