From: <li...@ba...> - 2008-09-21 15:22:28
|
Hi, I have put a first pre-release for 0.8.4 online. I would like to make a release soon, so that all changes currently being done for kernel integration can also be merged back to CVS. http://www.lirc.org/software/snapshots/lirc-0.8.4pre1.tar.bz2 Christoph |
From: Paul B. <peb...@gm...> - 2008-09-21 18:19:11
|
Christoph Bartelmus wrote: > Hi, > > I have put a first pre-release for 0.8.4 online. > I would like to make a release soon, so that all changes currently being > done for kernel integration can also be merged back to CVS. > > http://www.lirc.org/software/snapshots/lirc-0.8.4pre1.tar.bz2 > > Christoph It appears to be missing 'daemons/hw_commandir.h'. Per <http://www.gnu.org/software/libtool/manual/automake/Python.html>, the python check lines in configure.ac should be replaced with AM_PATH_PYTHON(,, [:]) AM_CONDITIONAL([HAVE_PYTHON], [test "$PYTHON" != :]) so that it does not fail when Python is not installed. In addition, I am not sure that the Python path found should be used in files that will be run on the target machine as is done in 'tools/Makefile.am'. After all, the AM_PATH_PYTHON returns the Python path on the build system not on the target system. |
From: <li...@ba...> - 2008-09-21 18:52:16
|
Hi! Paul Bender "peb...@gm..." wrote: > Christoph Bartelmus wrote: >> I have put a first pre-release for 0.8.4 online. [...] > It appears to be missing 'daemons/hw_commandir.h'. Fixed. > Per <http://www.gnu.org/software/libtool/manual/automake/Python.html>, > the python check lines in configure.ac should be replaced with > > AM_PATH_PYTHON(,, [:]) > AM_CONDITIONAL([HAVE_PYTHON], [test "$PYTHON" != :]) > > so that it does not fail when Python is not installed. At first I tried the lines given by the documentation, but unfortunately this did not work on my system. The current version does work. > In addition, I am not sure that the Python path found should be used in > files that will be run on the target machine as is done in > 'tools/Makefile.am'. After all, the AM_PATH_PYTHON returns the Python > path on the build system not on the target system. What is the standard approach with python scripts? Just install the script somewhere and let the user call the python interpreter manually? Christoph |
From: Paul B. <peb...@gm...> - 2008-09-23 02:57:44
|
Christoph Bartelmus wrote: > > Paul Bender "peb...@gm..." wrote: > >> In addition, I am not sure that the Python path found should be used in >> files that will be run on the target machine as is done in >> 'tools/Makefile.am'. After all, the AM_PATH_PYTHON returns the Python >> path on the build system not on the target system. > > What is the standard approach with python scripts? Just install the script > somewhere and let the user call the python interpreter manually? I do not know, which is why I said that I was not sure. I have never developed any packages that depend on Python for either the build system or the target system. For many other packages, this is handled by defaulting to the most common answer (in this case $bindir/python) and providing an override configuration option. However, I have no idea whether or not this is the approach used for Python. |
From: Ludwig N. <lud...@su...> - 2008-09-23 09:03:40
|
Christoph Bartelmus wrote: > > In addition, I am not sure that the Python path found should be used in > > files that will be run on the target machine as is done in > > 'tools/Makefile.am'. After all, the AM_PATH_PYTHON returns the Python > > path on the build system not on the target system. > > What is the standard approach with python scripts? Just install the script > somewhere and let the user call the python interpreter manually? Hardcode #!/usr/bin/python. If any distro installs python elsewhere their lirc packager will have to fix it up IMO. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) |
From: <li...@ba...> - 2008-09-23 16:18:27
|
Hi! Ludwig Nussel "lud...@su..." wrote: > Christoph Bartelmus wrote: >>> In addition, I am not sure that the Python path found should be used in >>> files that will be run on the target machine as is done in >>> 'tools/Makefile.am'. After all, the AM_PATH_PYTHON returns the Python >>> path on the build system not on the target system. >> >> What is the standard approach with python scripts? Just install the script >> somewhere and let the user call the python interpreter manually? > Hardcode #!/usr/bin/python. If any distro installs python elsewhere > their lirc packager will have to fix it up IMO. Ok, then I'll leave it like it is now. For users that compile themselves and have python in /usr/local or /opt, hardcoding is not the best option and packagers will have to check it anyway. Christoph |
From: Duncan W. <dun...@li...> - 2008-09-24 09:51:19
|
On 23/09/2008 18:06, Christoph Bartelmus said the following: > Hi! > > Ludwig Nussel "lud...@su..." wrote: > > >> Christoph Bartelmus wrote: >> >>>> In addition, I am not sure that the Python path found should be used in >>>> files that will be run on the target machine as is done in >>>> 'tools/Makefile.am'. After all, the AM_PATH_PYTHON returns the Python >>>> path on the build system not on the target system. >>>> >>> What is the standard approach with python scripts? Just install the script >>> somewhere and let the user call the python interpreter manually? >>> > > >> Hardcode #!/usr/bin/python. If any distro installs python elsewhere >> their lirc packager will have to fix it up IMO. >> > > Ok, then I'll leave it like it is now. > For users that compile themselves and have python in /usr/local or /opt, > hardcoding is not the best option and packagers will have to check it > anyway. > Hope this helps Normally you should use #!/bin/env python, then it will be found in the path. Duncan |
From: Jarod W. <ja...@wi...> - 2008-09-24 14:53:01
|
On Wed, 2008-09-24 at 11:29 +0200, Duncan Webb wrote: > On 23/09/2008 18:06, Christoph Bartelmus said the following: > > Hi! > > > > Ludwig Nussel "lud...@su..." wrote: > > > > > >> Christoph Bartelmus wrote: > >> > >>>> In addition, I am not sure that the Python path found should be used in > >>>> files that will be run on the target machine as is done in > >>>> 'tools/Makefile.am'. After all, the AM_PATH_PYTHON returns the Python > >>>> path on the build system not on the target system. > >>>> > >>> What is the standard approach with python scripts? Just install the script > >>> somewhere and let the user call the python interpreter manually? > >>> > > > > > >> Hardcode #!/usr/bin/python. If any distro installs python elsewhere > >> their lirc packager will have to fix it up IMO. > >> > > > > Ok, then I'll leave it like it is now. > > For users that compile themselves and have python in /usr/local or /opt, > > hardcoding is not the best option and packagers will have to check it > > anyway. > > > > Hope this helps > > Normally you should use #!/bin/env python, then it will be found in the > path. Same problem there -- you're hardcoding a path again. On my boxes: $ which env /usr/bin/env I'm all for just hardcoding #!/usr/bin/python. -- Jarod Wilson ja...@wi... |
From: Stefan H. <ki...@fo...> - 2008-09-21 19:24:22
|
Christoph Bartelmus schrieb: > I have put a first pre-release for 0.8.4 online. > I would like to make a release soon, so that all changes currently being > done for kernel integration can also be merged back to CVS. > > http://www.lirc.org/software/snapshots/lirc-0.8.4pre1.tar.bz2 I still can't load lirc_serial with 0.8.4pre1 and CVS version: |root@zaphod:/usr/local/src/lirc# modprobe lirc_serial |FATAL: Error inserting lirc_serial (/lib/modules/2.6.26.5/misc/lirc_serial.ko): Unknown symbol in module, or unknown parameter (see dmesg) So for the moment i use 2.6.25. |
From: Jarod W. <ja...@wi...> - 2008-09-22 19:10:16
|
On Sun, 2008-09-21 at 20:57 +0200, Stefan Hußfeldt wrote: > Christoph Bartelmus schrieb: > > > I have put a first pre-release for 0.8.4 online. > > I would like to make a release soon, so that all changes currently being > > done for kernel integration can also be merged back to CVS. > > > > http://www.lirc.org/software/snapshots/lirc-0.8.4pre1.tar.bz2 > > I still can't load lirc_serial with 0.8.4pre1 and CVS version: > > |root@zaphod:/usr/local/src/lirc# modprobe lirc_serial > |FATAL: Error inserting lirc_serial (/lib/modules/2.6.26.5/misc/lirc_serial.ko): Unknown symbol in module, or unknown parameter (see dmesg) > > So for the moment i use 2.6.25. As the message there says, see dmesg for more details. Most importantly, it should list what symbol is causing the problem. Can you please provide said detail? -- Jarod Wilson ja...@wi... |
From: Dominique D. <dom...@fr...> - 2008-09-27 08:15:13
|
Stefan Hußfeldt <ki...@fo...> writes: > Jarod Wilson schrieb: > >>> |root@zaphod:/usr/local/src/lirc# modprobe lirc_serial >>> |FATAL: Error inserting lirc_serial (/lib/modules/2.6.26.5/misc/lirc_serial.ko): Unknown symbol in module, or unknown parameter (see dmesg) >>> So for the moment i use 2.6.25. >> As the message there says, see dmesg for more details. Most importantly, >> it should list what symbol is causing the problem. Can you please >> provide said detail? > > |Sep 21 20:44:32 zaphod kernel: lirc_serial: no symbol version for lirc_unregister_plugin > |Sep 21 20:44:32 zaphod kernel: lirc_serial: Unknown symbol lirc_unregister_plugin > |Sep 21 20:44:32 zaphod kernel: lirc_serial: no symbol version for lirc_register_plugin > |Sep 21 20:44:32 zaphod kernel: lirc_serial: Unknown symbol lirc_register_plugin > I've also experienced this problem on Debian's 2.6.26 kernel. There's a bug entry related to this problem [1] With latest debian kernel, I'm able to load lirc-0.8.4pre1 modules (lirc_serial) with 'modprobe -f' HTH |
From: Dominique D. <dom...@fr...> - 2008-09-27 08:23:06
|
Dominique Dumont <dom...@fr...> writes: > I've also experienced this problem on Debian's 2.6.26 > kernel. There's a bug entry related to this problem [1] Acutally giving the URL might be a good idea: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494144 Sorry for the trouble. |
From: Ruediger D. <rue...@fr...> - 2008-09-22 19:03:11
|
Christoph Bartelmus schrieb: > Hi, > > I have put a first pre-release for 0.8.4 online. > I would like to make a release soon, so that all changes currently being > done for kernel integration can also be merged back to CVS. > > http://www.lirc.org/software/snapshots/lirc-0.8.4pre1.tar.bz2 > Dear Christoph, the "tarball" does not compile on Suse-11.0. Suse-11.0 provides lirc-0.8.3. Hence my Philips Remote SRM5100 works fine. I could compile lirc-0.8.3 with SUSE-10.3 (gcc-4.2). Again, I do not depend on it. Hence, it is just a pity that I can't build it from your tarball anymore. Below follows configure and gcc version, the output of "configure" and the 1st line of "make". ------------------------------------------------------------------------------------------------------------------------------------- configure --version ->configure ->generated by GNU Autoconf 2.61 gcc --version ->gcc (SUSE Linux) 4.3.1 lirc-0.8.4pre1> ./configure --with-driver=mceusb2 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking whether gcc and cc understand -c and -o together... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether make sets $(MAKE)... (cached) yes checking for mknod... /bin/mknod checking for mkfifo... /usr/bin/mkfifo checking for depmod... /sbin/depmod checking for libusb-config... /usr/bin/libusb-config checking whether ln -s works... yes checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ld used by gcc... /usr/x86_64-suse-linux/bin/ld checking if the linker (/usr/x86_64-suse-linux/bin/ld) is GNU ld... yes checking for /usr/x86_64-suse-linux/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -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 dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... cat: /etc/ld.so.conf.d/*.conf: No such file or directory GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/x86_64-suse-linux/bin/ld -m elf_x86_64 checking if the linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) is GNU ld... yes checking whether the g++ linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... cat: /etc/ld.so.conf.d/*.conf: No such file or directory GNU/Linux ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking for python... /usr/bin/python checking local Python configuration... looks good checking for ANSI C header files... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking syslog.h usability... yes checking syslog.h presence... yes checking for syslog.h... yes checking for unistd.h... (cached) yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for off_t... yes checking for pid_t... yes checking for size_t... yes checking whether struct tm is in sys/time.h or time.h... time.h checking return type of signal handlers... void checking for vprintf... yes checking for _doprnt... no checking for gethostname... yes checking for gettimeofday... yes checking for mkfifo... yes checking for select... yes checking for socket... yes checking for strdup... yes checking for strerror... yes checking for strtoul... yes checking for snprintf... yes checking for strsep... yes checking for vsyslog... yes checking for forkpty... no checking for forkpty in -lutil... yes checking vga.h usability... no checking vga.h presence... no checking for vga.h... no checking for X... libraries /usr/lib64, headers checking whether -R must be followed by a space... neither works checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for getopt_long... yes checking for mktemp... yes checking for Linux kernel sources... ./configure: line 22850: test: too many arguments /lib/modules/2.6.25.16-0.1-default/source/ checking for which drivers can be installed on this system... checking for caraca_init in -lcaraca_client... no checking iguanaIR.h usability... no checking iguanaIR.h presence... no checking for iguanaIR.h... no checking for ir_strerror in -lirman... no checking for ir_strerror in -lirman_sw... no checking portaudio.h usability... no checking portaudio.h presence... no checking for portaudio.h... no checking alsa/asoundlib.h usability... yes checking alsa/asoundlib.h presence... yes checking for alsa/asoundlib.h... yes checking for snd_pcm_open in -lasound... yes checking for ALSA SB RC hwdep support... yes checking scsi/sg.h usability... yes checking scsi/sg.h presence... yes checking for scsi/sg.h... yes checking linux/input.h usability... yes checking linux/input.h presence... yes checking for linux/input.h... yes checking linux/types.h usability... yes checking linux/types.h presence... yes checking for linux/types.h... yes checking for linux/hiddev.h... yes checking for HIDDEV_FLAG_UREF support... yes checking sys/soundcard.h usability... yes checking sys/soundcard.h presence... yes checking for sys/soundcard.h... yes checking linux/i2c-dev.h usability... no checking linux/i2c-dev.h presence... no checking for linux/i2c-dev.h... no checking for daemon... yes configure: WARNING: Cache variable ac_cv_have_kernel contains a newline. configure: creating ./config.status config.status: creating Makefile config.status: WARNING: Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/Makefile config.status: WARNING: drivers/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_atiusb/Makefile config.status: WARNING: drivers/lirc_atiusb/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_bt829/Makefile config.status: WARNING: drivers/lirc_bt829/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_cmdir/Makefile config.status: WARNING: drivers/lirc_cmdir/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_dev/Makefile config.status: WARNING: drivers/lirc_dev/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_gpio/Makefile config.status: WARNING: drivers/lirc_gpio/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_i2c/Makefile config.status: WARNING: drivers/lirc_i2c/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_igorplugusb/Makefile config.status: WARNING: drivers/lirc_igorplugusb/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_ttusbir/Makefile config.status: WARNING: drivers/lirc_ttusbir/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_imon/Makefile config.status: WARNING: drivers/lirc_imon/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_it87/Makefile config.status: WARNING: drivers/lirc_it87/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_ite8709/Makefile config.status: WARNING: drivers/lirc_ite8709/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_mceusb/Makefile config.status: WARNING: drivers/lirc_mceusb/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_mceusb2/Makefile config.status: WARNING: drivers/lirc_mceusb2/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_parallel/Makefile config.status: WARNING: drivers/lirc_parallel/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_sasem/Makefile config.status: WARNING: drivers/lirc_sasem/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_serial/Makefile config.status: WARNING: drivers/lirc_serial/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_sir/Makefile config.status: WARNING: drivers/lirc_sir/Makefile.in seems to ignore the --datarootdir setting config.status: creating drivers/lirc_streamzap/Makefile config.status: WARNING: drivers/lirc_streamzap/Makefile.in seems to ignore the --datarootdir setting config.status: creating daemons/Makefile config.status: WARNING: daemons/Makefile.in seems to ignore the --datarootdir setting config.status: creating tools/Makefile config.status: WARNING: tools/Makefile.in seems to ignore the --datarootdir setting config.status: creating doc/Makefile config.status: WARNING: doc/Makefile.in seems to ignore the --datarootdir setting config.status: creating doc/man/Makefile config.status: WARNING: doc/man/Makefile.in seems to ignore the --datarootdir setting config.status: creating config.h config.status: executing default-1 commands You will have to use the lirc_mceusb2 kernel module. Now enter 'make' and 'make install' to compile and install the package. configure: WARNING: Cache variable ac_cv_have_kernel contains a newline. lirc-0.8.4pre1> make Makefile:109: *** missing separator (Meinten Sie TAB anstelle von 8 Leerzeichen?). Schluss. lirc-0.8.4pre1> ------------------------------------------------------------------------------------------------------------------------------------------- Do I need to provide more? Thanks Ruediger |
From: <li...@ba...> - 2008-09-22 19:25:22
|
Hi! Ruediger Dohmhardt "rue...@fr..." wrote: [...] > the "tarball" does not compile on Suse-11.0. [...] > checking for Linux kernel sources... ./configure: line 22850: test: too > many arguments > /lib/modules/2.6.25.16-0.1-default/source/ There's a problem here. Could you send me your /lib/modules/2.6.25.16-0.1- default/source/Makefile. And also the Makefile in the lirc source directory that configure has created. Christoph |
From: <li...@ba...> - 2008-09-22 20:19:30
|
Hi! Christoph Bartelmus "li...@ba..." wrote: > Ruediger Dohmhardt "rue...@fr..." wrote: > [...] >> the "tarball" does not compile on Suse-11.0. > [...] >> checking for Linux kernel sources... ./configure: line 22850: test: too >> many arguments >> /lib/modules/2.6.25.16-0.1-default/source/ You will find this in your Makefile: kernelcc = ERROR: Kernel configuration is invalid. include/linux/autoconf.h or include/config/auto.conf are missing. Run 'make oldconfig && make prepare' on kernel src to fix it. There are files missing in your kernel source tree. Christoph |
From: Jenks, M. <Mar...@ns...> - 2008-09-22 21:19:16
|
This looks familiar. I got the same errors trying to compile the nvidia drivers on Suse 11.0. I tried the suggested commands and never solved it, and went with Fedora 9 instead which worked the first time. Maybe there is an issue with Suse 11 kernel-souces? > -----Original Message----- > From: Christoph Bartelmus [mailto:li...@ba...] > Sent: Monday, September 22, 2008 3:18 PM > To: lir...@li... > Subject: Re: lirc-0.8.4pre1; it does not compile on SUSE-11.0 > > Hi! > > Christoph Bartelmus "li...@ba..." wrote: > > Ruediger Dohmhardt "rue...@fr..." wrote: > > [...] > >> the "tarball" does not compile on Suse-11.0. > > [...] > >> checking for Linux kernel sources... ./configure: line > 22850: test: too > >> many arguments > >> /lib/modules/2.6.25.16-0.1-default/source/ > > You will find this in your Makefile: > kernelcc = > ERROR: Kernel configuration is invalid. > include/linux/autoconf.h or include/config/auto.conf > are missing. > Run 'make oldconfig && make prepare' on kernel src to fix it. > > There are files missing in your kernel source tree. > > Christoph > > > -------------------------------------------------------------- > ----------- > This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge > Build the coolest Linux based applications with Moblin SDK & > win great prizes > Grand prize is a trip for two to an Open Source event > anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > |
From: Ludwig N. <lud...@su...> - 2008-09-23 08:32:06
|
Christoph Bartelmus wrote: > Christoph Bartelmus "li...@ba..." wrote: > > Ruediger Dohmhardt "rue...@fr..." wrote: > > [...] > >> the "tarball" does not compile on Suse-11.0. > > [...] > >> checking for Linux kernel sources... ./configure: line 22850: test: too > >> many arguments > >> /lib/modules/2.6.25.16-0.1-default/source/ > > You will find this in your Makefile: > kernelcc = > ERROR: Kernel configuration is invalid. > include/linux/autoconf.h or include/config/auto.conf are missing. > Run 'make oldconfig && make prepare' on kernel src to fix it. > > There are files missing in your kernel source tree. The source tree is fine. It's just not configured. The actual configurations for all kernels are in separate directories [1]. For plain kernel Makefiles that's transparent. lirc's configure magic tries to be smart but fails to detect that setup though. I never bothered trying to understand or fix that magic as it's not useful for building rpm packages anyways. For the lirc kernel module rpm packages I basically drop a custom Makefile into every driver directory and call make for every kernel flavor SUSE ships (pae, smp, xen etc). Manually that would look like this: /tmp/lirc/drivers/lirc_dev $ cat Makefile EXTRA_CFLAGS := -I$(src)/../.. \ -DLIRC_MAJOR=61 \ -DIRCTL_DEV_MAJOR=61 \ -DDEV_LIRC='"lirc"' \ -I$(srctree)/drivers/media/video lirc_src = $(wildcard $(src)/*.c) obj-m := $(lirc_src:$(src)%.c=%.o) /tmp/lirc/drivers/lirc_dev $ make -C /lib/modules/`uname -r`/build M=$(pwd) modules make: Entering directory `/usr/src/linux-2.6.25.16-0.1-obj/x86_64/default' make -C /usr/src/linux-2.6.25.16-0.1 O=/usr/src/linux-2.6.25.16-0.1-obj/x86_64/default/. modules CC [M] /tmp/lirc/drivers/lirc_dev//lirc_dev.o Building modules, stage 2. MODPOST 1 modules CC /tmp/lirc/drivers/lirc_dev//lirc_dev.mod.o LD [M] /tmp/lirc/drivers/lirc_dev//lirc_dev.ko make: Leaving directory `/usr/src/linux-2.6.25.16-0.1-obj/x86_64/default' cu Ludwig [1] http://www.suse.de/~agruen/kernel-doc/ -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) |
From: <li...@ba...> - 2008-09-23 16:18:28
|
Hi! Ludwig Nussel "lud...@su..." wrote: > Christoph Bartelmus wrote: [...] >> ERROR: Kernel configuration is invalid. >> include/linux/autoconf.h or include/config/auto.conf are missing. >> Run 'make oldconfig && make prepare' on kernel src to fix it. >> >> There are files missing in your kernel source tree. > The source tree is fine. It's just not configured. But that's the main point why we need the kernel source tree: to know how the current kernel is configured. The unconfigured source is pretty useless for us. [...] > directory and call make for every kernel flavor SUSE ships (pae, > smp, xen etc). Manually that would look like this: [...] > /tmp/lirc/drivers/lirc_dev $ make -C /lib/modules/`uname -r`/build M=$(pwd) Does this mean that on SUSE you have everything necessary in /lib/modules/`uname -r`/build ? Christoph |
From: Ludwig N. <lud...@su...> - 2008-09-24 11:11:32
|
Christoph Bartelmus wrote: > [...] > > directory and call make for every kernel flavor SUSE ships (pae, > > smp, xen etc). Manually that would look like this: > [...] > > /tmp/lirc/drivers/lirc_dev $ make -C /lib/modules/`uname -r`/build M=$(pwd) > > Does this mean that on SUSE you have everything necessary in > /lib/modules/`uname -r`/build ? Theoretically yes. That weird configure check that copies the Makefile and adds extra targets to figure out the kernel compiler doesn't work though. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) |
From: <li...@ba...> - 2008-09-24 16:23:57
|
Hi! Ludwig Nussel "lud...@su..." wrote: > Christoph Bartelmus wrote: >>> directory and call make for every kernel flavor SUSE ships (pae, >>> smp, xen etc). Manually that would look like this: >> [...] >>> /tmp/lirc/drivers/lirc_dev $ make -C /lib/modules/`uname -r`/build >>> M=$(pwd) >> >> Does this mean that on SUSE you have everything necessary in >> /lib/modules/`uname -r`/build ? > Theoretically yes. That weird configure check that copies the > Makefile and adds extra targets to figure out the kernel compiler > doesn't work though. Why it doesn't work? Could you please try it with 0.8.4pre1? Christoph |
From: Ludwig N. <lud...@su...> - 2008-09-25 06:36:29
|
Christoph Bartelmus wrote: > Hi! > > Ludwig Nussel "lud...@su..." wrote: > > Christoph Bartelmus wrote: > >>> directory and call make for every kernel flavor SUSE ships (pae, > >>> smp, xen etc). Manually that would look like this: > >> [...] > >>> /tmp/lirc/drivers/lirc_dev $ make -C /lib/modules/`uname -r`/build > >>> M=$(pwd) > >> > >> Does this mean that on SUSE you have everything necessary in > >> /lib/modules/`uname -r`/build ? > > > Theoretically yes. That weird configure check that copies the > > Makefile and adds extra targets to figure out the kernel compiler > > doesn't work though. > > Why it doesn't work? No idea. I'm not a kernel Makefile wizard. The Makefile you are appending custom rules to looks like this: $ cat /lib/modules/`uname -r`/build/Makefile # Automatically generated by /usr/src/linux-2.6.25.16-0.1/scripts/mkmakefile: don't edit VERSION = 2 PATCHLEVEL = 6 lastword = $(word $(words $(1)),$(1)) makedir := $(dir $(call lastword,$(MAKEFILE_LIST))) MAKEARGS := -C /usr/src/linux-2.6.25.16-0.1 MAKEARGS += O=$(if $(patsubst /%,,$(makedir)),$(CURDIR)/)$(patsubst %/,%,$(makedir)) MAKEFLAGS += --no-print-directory .PHONY: all $(MAKECMDGOALS) all := $(filter-out all Makefile,$(MAKECMDGOALS)) all: $(MAKE) $(MAKEARGS) $(all) Makefile:; $(all) %/: all @: I wonder why you need to figure out kernelcc etc in the first place though. The kernel build system knows how to compile it's module so just providing simple Kbuild files should suffice. > Could you please try it with 0.8.4pre1? Doesn't work, just as any previous version. That's why this subthread started :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) |
From: <li...@ba...> - 2008-09-25 17:41:44
|
Hi! Ludwig Nussel "lud...@su..." wrote: > Christoph Bartelmus wrote: [...] >>>> Does this mean that on SUSE you have everything necessary in >>>> /lib/modules/`uname -r`/build ? >> >>> Theoretically yes. That weird configure check that copies the >>> Makefile and adds extra targets to figure out the kernel compiler >>> doesn't work though. >> >> Why it doesn't work? > No idea. I'm not a kernel Makefile wizard. But you could cut'n'paste the error message, right? ;) [...] > I wonder why you need to figure out kernelcc etc in the first place Good point. We don't need it. This seems to be a relict from 2.2 days... I have removed it. Could you please check if current CVS works on SUSE 11 now? [...] > Doesn't work, just as any previous version. That's why this > subthread started :-) It does not work in /lib/modules/`uname -r`/source because the kernel is not configured there, but you are telling me that in /lib/modules/`uname - r`/build everything necessary should be available. Christoph |
From: Ludwig N. <lud...@su...> - 2008-10-04 16:14:34
|
Christoph Bartelmus wrote: > Ludwig Nussel "lud...@su..." wrote: > > I wonder why you need to figure out kernelcc etc in the first place > > Good point. We don't need it. This seems to be a relict from 2.2 days... > > I have removed it. Could you please check if current CVS works on SUSE 11 > now? Works now mostly[1]. configure still complains when it tries to determine the module file suffix. Not fatal but likely the same kind of legacy check that can be removed. checking for Linux kernel sources... /tmp/LIRCMF.VBSyVZ:27: warning: overriding commands for target `lirc_tell_me_what_version_is' /tmp/LIRCMF.VBSyVZ:24: warning: ignoring old commands for target `lirc_tell_me_what_version_is' make[2]: *** No rule to make target `lirc_tell_me_what_version_is'. Stop. make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 /tmp/LIRCMF.VBSyVZ:29: warning: overriding commands for target `lirc_tell_me_what_patchlevel_is' /tmp/LIRCMF.VBSyVZ:24: warning: ignoring old commands for target `lirc_tell_me_what_patchlevel_is' make[2]: *** No rule to make target `lirc_tell_me_what_patchlevel_is'. Stop. make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 ./configure: line 23703: test: too many arguments /lib/modules/2.6.25.11-0.1-default/build/ cu Ludwig 1) lirc_gpio is known to not work on newer kernels anymore IIRC. lirc_parallel doesn't work with SMP kernels. lirc_serial and lirc_lirc not on ppc. -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ |
From: Ruediger D. <rue...@fr...> - 2008-10-04 18:24:07
Attachments:
lirc_OutputFromConfigureAndMake.txt
|
Ludwig Nussel schrieb: > Christoph Bartelmus wrote: > >> Ludwig Nussel "lud...@su..." wrote: >> >>> I wonder why you need to figure out kernelcc etc in the first place >>> >> Good point. We don't need it. This seems to be a relict from 2.2 days... >> >> I have removed it. Could you please check if current CVS works on SUSE 11 >> now? >> Yup! The code from CVS "configures", "makes" and works here on SUSE-11.0, too (for "mceusb2"). I got the code from CVS about an 1hour ago using cvs -z8 -d:pserver:ano...@li...:/cvsroot/lirc co lirc The result of "./configure --with-driver=mceusb2" and "make" is attached. Thanks and CU Ruediger D. |
From: Ruediger D. <rue...@fr...> - 2008-09-22 21:24:39
Attachments:
lirc.txt
|
Christoph Bartelmus schrieb: > Hi! > > Christoph Bartelmus "li...@ba..." wrote: > >> Ruediger Dohmhardt "rue...@fr..." wrote: >> [...] >> >>> the "tarball" does not compile on Suse-11.0. >>> >> [...] >> >>> checking for Linux kernel sources... ./configure: line 22850: test: too >>> many arguments >>> /lib/modules/2.6.25.16-0.1-default/source/ >>> > > You will find this in your Makefile: > kernelcc = > ERROR: Kernel configuration is invalid. > include/linux/autoconf.h or include/config/auto.conf are missing. > Run 'make oldconfig && make prepare' on kernel src to fix it. > > There are files missing in your kernel source tree. > Yes, you are right. For the original Suse-Kernel 2.6.25.16-0.1-default, there is somehow a problem. I haven't been able to fix it. But, based on Suse-11.0, I build my own kernel 2.6.26.3. uname -a ->Linux linux-qorb 2.6.26.3 #6 SMP PREEMPT Mon Sep 8 16:29:16 CEST 2008 x86_64 x86_64 x86_64 GNU/Linux Here it compiles and after "make install" I got the two modules /lib/modules/2.6.26.3/misc/lirc_mceusb2.ko /lib/modules/2.6.26.3/misc/lirc_dev.ko as expected. During the next days I will test it and tell if any problems arise. However, I have the two error messages during the compilation process as shown in the attachment "lirc.txt". And now I believe to remember, I got always those 2 error messages over the last 2,3 or 4 years. But since it always compiled and I got my working modules, I never did anything. Anyway, thanks Ruediger |