Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Son, 2009-01-04 at 11:23 +0100, Leon Woestenberg wrote: [...] On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt let...@linux-sh.org wrote: [...] I'm ignoring the cross-compile perl issue - haven't tried it for years. 5. Tool *version* dependency is hard to get right. When cross-building 30 software packages all requiring native perl, we probably need to build a few versions of perl (native), one for each set of packages. perl is IMHO special (and quite different to others - including especially autotools): perl5 is used widely enough so that one somewhat recent version should cover all of 30 software packages. The hard part are the CPAN modules and their versions which are really a PITA. As long as you don't use modules from CPAN, perl5 should be specific enough. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Son, 2009-01-04 at 22:50 -0600, Rob Landley wrote: On Sunday 04 January 2009 18:15:30 Bernd Petrovitsch wrote: [...] ACK. A bash can IMHO be expected. Even going for `dash` is IMHO somewhat too extreme. I have yet to encounter a system that uses dash _without_ bash. (All ubuntu Hmm, should be doable with a chroot environment quite cheap and simple. variants, even jeos, install bash by default. They moved the /bin/sh symlink Yes, I know (small) embedded systems that have a bash (and not only one of busybox shells). It eases writing somewhat fast shell scripts without the need for lots of fork()s+exec()s too . Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Mon, 2009-01-05 at 02:23 +, Jamie Lokier wrote: Bernd Petrovitsch wrote: (I have 850 Linux boxes on my network with a bourne shell which doesn't do $((...)). I won't be building kernels on them though :-) Believe it or not, but there are folks out there who build the firmware on ARM 200 MHz NFS-mounted systems natively (and not simply cross-compile it on a 2GHz PC .). Really? My 850 Linux boxes are 166MHz ARMs and occasionally NFS-mounted. Their /bin/sh does not do $((...)), and Bash is not there at all. I assume that the NFS-mounted root filesystem is a real distribution. And on the local flash is a usual busybox based firmware. If I were installing GCC natively on them, I'd install GNU Make and a proper shell while I were at it. But I don't know if Bash works ACK. properly without fork()* - or even if GCC does :-) Perl might be hard, as shared libraries aren't supported by the toolchain which targets my ARMs* and Perl likes its loadable modules. The simplest way to go is probably to use CentOS or Debian or another ready binary distribution on ARM (or MIPS or PPC or whatever core the embedded system has) possibly on a custom build kernel (if necessary). [...] (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add proper shared libs. Feel free to fund this :-) The above mentioned ARMs have a MMU. Without MMU, it would be truly insane IMHO. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Son, 2009-01-04 at 22:13 +, Jamie Lokier wrote: Rob Landley wrote: In a private email, Bernd Petrovitsch suggested set -- $i and then using NAME=$1; PERIOD=$2. (I keep getting private email responses to these sort of threads, and then getting dismissed as the only one who cares about the issue. Less so this time around, but still...) This apparently works all the way back to the bourne shell. If you're going all the way back to the bourne shell, don't use set Going back to a Bourne shell was neither the intention nor makes it sense IMHO. I mentioned it to point out that the `set -- ' (or `set x `) is nothing new or even a bash-ism. -- $i; use set x $i instead, and don't expect to do any arithmetic in the shell; use expr or awk for arithmetic. (Not relevant to kernel scripts, imho, since you can always assume something a bit more modern and not too stripped down). ACK. A bash can IMHO be expected. Even going for `dash` is IMHO somewhat too extreme. (I have 850 Linux boxes on my network with a bourne shell which doesn't do $((...)). I won't be building kernels on them though :-) Believe it or not, but there are folks out there who build the firmware on ARM 200 MHz NFS-mounted systems natively (and not simply cross-compile it on a 2GHz PC .). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
On Tue, 2008-08-26 at 18:54 -0400, Parag Warudkar wrote: On Tue, Aug 26, 2008 at 5:04 PM, Linus Torvalds [EMAIL PROTECTED] wrote: And embedded people (the ones that might care about 1% code size) are the ones that would also want smaller stacks even more! This is something I never understood - embedded devices are not going to run more than a few processes and 4K*(Few Processes) IMHO is not worth a saving now a days even in embedded world given falling memory prices. Or do I misunderstand? Falling prices are no reason to increase the amount of available RAM (or other hardware). Especially if you (intend to) build 1E5 devices - where every Euro counts. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
On Tue, 2008-08-26 at 22:16 -0400, Parag Warudkar wrote: [...] Well, sure - but the industry as a whole seems to have gone the other The industry as a whole doesn't exist on that low level. You can't compare the laptop and/or desktop computer market (where one may buy today hardware that runs in 3 years with the next generation/release of the OS and applications) with the e.g. WLAN router market where - from the commercial point of view - every Euro counts (and where the requirements for the lifetime of the device are long frozen before the thing gets in a shop). way - do more with more at the similar or lower price points! By that definition of less is better we should try and make the kernel memory pageable (or has someone already done that?) - Windows does it, That doesn't help as in really small devices (like WLAN routers, cable modems, etc.) you run without any means of paging/swapping. And even binaries/read-only files are not necessarily executable in place (but must be loaded into RAM). So you can't flush these pages. And pageable kernel memory doesn't come for free - even if one only counts the increased code and it's complexity. by default ;) Which is more a sign that it is probably a very bad idea. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
On Tue, 2008-08-26 at 20:58 -0400, Parag Warudkar wrote: [...] The savings part -financial ones- are not always realizable with the way memory is priced/sized/fitted. Savings in few Mb of Kernel stack are not necessarily going to allow getting rid of a single memory chip of 64M or so. No, but you can put an additional service(s) on it and sales people have one (or two or ) line more for their sales brochures. Either that or embedded manufacturing/configurations are different than the desktop world. They are different. Think of running the complete system acting as a bridge, router and/or firewall (Kernel early 2.4 though) from 4MB flash in 32MB RAM and - listing the outside visible services - having a command-line interface, web-GUI (implying a http server) and and a (net-)SNMP agent on it. Running a glibc without thread support is win there (implying that there is no thread support available on that device). (If my device has 2 memory slots and my user space requires 100Mb including kernel memory - I anyways have to put in 64Mx2 there to take advantage of mass manufactured, general purpose memory - so no big deal if I saved 1.2Mb in Kernel stack or not. And savings of 64Mb Kernel memory are not feasible anyways to allow user space to work with 64Mb.) As soon as product management realizes that there is space left on the device, they get new ideas and/or customer requirements to run more services on that device. On the other hand reducing user space memory usage on those devices (not counting savings from kernel stack size) is a way more attractive option. There is no question if save space here or there. You save it - sooner or later - on all fronts. Period. And although you said in your later reply that Linux x86 with 4K stacks should be more than usable - my experiences running a untainted desktop/file server with 4K stack have been always disastrous XFS or not. It _might_ work for some well defined workloads but you would not want to risk 4K stacks otherwise. The embedded world of really small devices usually doesn't run XFS (or ext? or reiser* of jfs or NFS or ...) or stacks block devices on files or . I understand the having 4K stack option as a non-default for very specific workloads is a good idea but apart from that I think no one else seems to bother with reducing stack sizes (by no one I mean other OSes.) They probably gave the idea pretty soon because you need to rework/improve large parts of the kernel + drivers (and that has two major problems - it consumes a lot of man power for no new features and everything must be completely tested again[0] and it adds new risks). And that is practically impossible if one sells stable driver APIs for 3rd party (commercial) drivers because these must be changed too. Bernd [0]: Let alone if you (or your customers) need certificates from some governmental agencys. -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
On Wed, 2008-08-27 at 16:48 +0100, Jamie Lokier wrote: Bernd Petrovitsch wrote: If you develop an embedded system (which is partly system integration of existing apps) to be installed in the field, you don't have that many conceivable work loads compared to a desktop/server system. And you have a fixed list of drivers and applications. Hah! Not in my line of embedded device. 32MB no-MMU ARM boards which people run new things and attach new devices to rather often - without making new hardware. Volume's too low per individual application to get new hardware designed and made. Yes, you may have several products on the same hardware with somewhat differing requirements (or not). But that is much less than a general purpose system IMHO. I'm seriously thinking of forwarding porting the 4 year old firmware from 2.4.26 to 2.6.current, just to get new drivers and capabilities. That sounds reasonable (and I never meant maintaining the old system infinitely. Actually once the thing is shipped it usually enters deep maintenance mode and the next is more a fork from the old). Backporting is tedious, so's feeling wretchedly far from the mainline world. ACK. But that also depends on amount local changes (and sorry, but not all locally necessary patches would be accepted in mainline in any way). A usual approach is to run stress tests on several (or all) subsystems/services/... in parallel and if the device survives it functioning correctly, it is at least good enough. Per application. Some little devices run hundreds of different applications and customers expect to customise, script themselves, and attach different devices (over USB). The next customer in the chain expects the bits you supplied to work in a variety of unexpected situations, even when you advise that it probably won't do that. Basically their problem. Yes, they actually think they get a Linux system where they can do everything and it simply works. Oh, that's obviously not a usual WLAN-router style of product (where you are not expected to actually login on a console or per ssh). Much like desktop/server Linux, but on a small device where silly little things like 'create a process' are a stress for the dear little thing. (My biggest lesson: insist on an MMU next time!) ACK. We avoid MMU-less hardware too - especially since there is enough hardware with a MMU around. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
On Mit, 2008-08-27 at 18:51 +0100, Jamie Lokier wrote: Bernd Petrovitsch wrote: [...] It is, but the idea that small embedded systems go through a 'all components are known, drivers are known, test and if it passes it's shippable' does not always apply. Not always but often enough. And yes, there is ARM-based embedded hardware with 1GB Flash-RAM and 128MB RAM. I'm seriously thinking of forwarding porting the 4 year old firmware from 2.4.26 to 2.6.current, just to get new drivers and capabilities. That sounds reasonable (and I never meant maintaining the old system infinitely. Sounds reasonable, but it's vetoed for anticipated time and cost, That is to be expected;-) [] ACK. We avoid MMU-less hardware too - especially since there is enough hardware with a MMU around. I can't emphasise enough how much difference MMU makes to Linux userspace. It's practically: MMU = standard Linux (with less RAM), have everything. No-MMU = lots of familiar 'Linux' things not available or break. ACK. And tell that a customer that everything is more effort and more risk and not just simply cross-compile it as it runs on my desktop too. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: prevalence of C++ in embedded linux?
On Wed, 2008-07-30 at 14:07 +0100, Jamie Lokier wrote: Bernd Petrovitsch wrote: If GOLD is as old and flexible (and portable?) as binutils, The author says it will only work with ELF, and he does not intend to add support for all the other things binutils does. Well, supporting 80% of the deployed systems requires probably only 20% of the code;-) But then it won't really replace binutils. And if, some quirky hardware/systems have a problem . gcc and/or other huge software maintained to death, it is probably similar complex and odd. If people take a 10 year old tool and rewrite it from scratch, I would assume that design is better. Only true if the cruft is no longer relevant. If the cruft is intrinsic to the problem, e.g. supporting umpteen quirky architectures implies umpteen quirks of cruft, then it'll be in the new design. Yes, but one can make a better design in always knowing/planning to have hooks here and there and everywhere. Btw, gcc and binutils are more like 30 years old :-) That doesn't make it better;-) I was too lazy to search for more exact numbers. And I can't see any direct dependence on the used programming language(s) if one compares running code and what is left of design after years of design extensions, changes, enhancements, etc. to a new design from scratch from the lessons learned (hopefully) from the former one. Some programming languages allow you to express a problem concisely and clearly, and some don't. That clarity then affects whether an And if C is too low-level, one abstracts with functions etc. I call that design - independent if the design existed before the source or if the design evolved over years with the software And yes, at first it is enough to add a parameter and/or function here and there without breaking implicit or explicit assumptions. But at one point from a larger view, the design problems will be obvious and one can either solve them (investing time/money for effectively no real gain in features and/or functionality, just only cleanups or refactoring of parts or whatever one wants to call it) or lives on with patching/maintaining the software to death. evolving design becomes loaded with implementation cruft or not - and you can't always tell the difference. Yes. And over the years and decades, the implementation evolves with the problems - new and existing ones. If the design doesn't involve - which IMHO implies refactoring of existing, tested and working code(!) possible breaking it - you have at some point such a mess that each trivial enhancement takes age (and breaks again somewhere else something). Most languages are well-matched to different problem domains. Maybe. IMHO these differences are almost nothing compared to the below point: Binutils and bfd look very crufty, but I think it's hard to tell how much of that is due to the implementation language and implementation, or the design and requirements, and how much would exist in any implementation on any language. IMHO it's (mostly) independent of the implementation language: If changes in design are not completed (including removal of old deprecated stuff or at least push it in peripheral places where nobody cares;-) in the implementation (for whatever reason - no one does it, no one wants to pay it, one wants to support every API indefinitely, ), it will lead more sooner than later to unmaintanable crufty software. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives
On Fre, 2008-06-13 at 20:51 +0200, Robert Schwebel wrote: On Fri, Jun 13, 2008 at 08:30:52AM +0200, Alexander Neundorf wrote: Battle of Wesnoth is currently converted to both Scons and CMake, and in the end they will decide about the winner. (since Eric is good at arguing I guess it will be scons). The thing is that 'configure make make install' plus the usuall --enable-foo / --disable-foo / --with-bla=blub semantics is simply *the* standard way of configuring stuff for unix systems. You don't need fancy tools, you get cross compiling almost for free and unix people simply know how to use it. As long as people avoid AC_TRY_RUN() and similar and allow the configurator to tell `configure.sh` facts for the unavoidable cases about the target (and there were some apps - and I forgot the names - out there where this wasn't easily possible with editing the generated configure.sh. Yes, that's not fault of autotools as such but autotools make it IMHO far too easy to write that sort without generating lots of warnings[0]). All the cool kids out there who think they know everything better usually start with I hate autotools, then invent something which That has IMHO 2 main reasons: - For lost of apps, a Makefile and some coding discipline is more than enough to support Linux/*BSD/MacOS-X even on different hardware. And there are always cases where you need OS-specific code anyways (e.g. manipulating routes). Yes, that may need much more coding discipline than the average programmer is used to. - Converting $PROJECT to autotools is not easy. One has to learn and understand how the tools work[1] and what should be done in which way. And AFAIU (which is not much for autotools) one has to adapt the source anyways here and there (so it is not really a drop-in replacement). And if people consider using autotools, it is probably quite large and complex Add that to negative experiences with other autotools packages and I can understand the above sentence. solves 0.1% of the problems (including their very special problem) and tell the rest of the world that their shiny new tools is *s cl*. Bernd [0]: Yes, this is free software and I could send patches etc. to fix that. But that price is IMHO higher than just not using autotools for new stuff. [1]: And I didn't find a site yet with an easy understandable description for seasoned programmers with cross-compile and multi-hardware experience. -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives
On Sam, 2008-06-14 at 01:07 +0100, Jamie Lokier wrote: [...] You said about too many user-selectable options. Many large packages These are IME not a problem if they have somewhat sensible defaults. _check_ for many installed libraries. Get them wrong, and you have the same problems of untested combinations. As long as I can specify that libfoo support must be compiled in (and thus libfoo must be present) and the tools throw an error if it doesn't find it, I have no problem. Otherwise all package builders have a serious problem. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives
On Mon, 2008-06-16 at 12:17 +0100, Jamie Lokier wrote: Bernd Petrovitsch wrote: _check_ for many installed libraries. Get them wrong, and you have the same problems of untested combinations. As long as I can specify that libfoo support must be compiled in (and thus libfoo must be present) and the tools throw an error if it doesn't find it, I have no problem. Otherwise all package builders have a serious problem. They do have problems, when you want to repeatably build and deploy, if the build environment isn't very similar each time. Sometimes you have a different build environments - if only that you want to rebuild e.g. your .src.rpm on several versions of CentOS and Fedora. Typically the way you specify that libfoo support must be compiled in is --with-libfoo=/path/to/libfoo. That way lies bitrot between your build script which calls ./configure Cannot be really avoided IMHO. (since you won't by typing it manually with 20+ options like that each time you rebuild), and the changing version of an upstream package you configure. So be it. At least one sees errors/bugs immediately. To prevent it trying to compile in libs you don't want, you also need --without-libfoo. Using Kerberos as an example, which I remember when building CVS ages ago: If you don't _prevent_ it using libraries you don't want, you get different binariesn depending on whether a Kerberos library was installed on the build system at build time. You might then send a built program to another system, and find it won't run at all, or has unwanted behaviour. Do you really see package building scripts with 20 --with-libfoo= and --without-libfoo= options in them for every library? Sometimes. But For (in an ideal world 100%) repeatable builds - for a .rpm. .deb, some cross-compiled embedded device - one usually ends up with that explicit list (and IMHO it's the smaller PITA than to cope with strange bug reports because something was broken in the build weeks ago). Mainly because the dependency information is also present elsewehre (e.g. in the package). Or you really want control over the installed software. more often, not: instead, they more often have build-time installed prerequisites. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives
On Fre, 2008-06-13 at 14:17 +0100, Jamie Lokier wrote: Bernd Petrovitsch wrote: Actually the size of ints (or any other type) can be easily deduced without running a (for the target) compiled binary: - compile the binary (for the target) with an initialized variable with that value. - use cross nm (or a similar tool) to read it from there. Or the method autoconf uses - binary search, using a compile-time numeric comparison which resolves to a successful or failed compile. Good, I didn't know that. That seems more portable to me. Yes, just using the compiler is better. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives
On Fre, 2008-06-13 at 17:16 +0200, Enrico Weigelt wrote: * Bernd Petrovitsch [EMAIL PROTECTED] schrieb: Basically yes. But if you have a big number of packages (or a huge package) which you didn't write yourself, there will be tests which run executables. Figuring out what all the tests are supposed to test in a complex unknown software project is not trivial. Yes, you get used to find the relevant lines in config.log and similar with `grep` and similar tools;-) Which are different on each package. So you have to configure each package ACK. for each target manually, which leads the whole point of autoconf ad absurdum ;-o Yup. [...] pkg-config generated (and generates? - I didn't check recently) references to libraries including the full absolute path (which is the one at build time. And at run-time there is usually no /home/bernd/src/... or where some build may just run). Recent pkg-config supports sysroot. FC-6 has only 0.21. So you simply build your .pc files as usual (w/o sysroot prefix) and set the sysroot prefix via env on the pkg-config call. From a quick glance over the man page of 0.23, yes. Can you please explain ? How do the generated pkg_config files look like ? Ahh, you mean they contain e.g -L/my/build/host/target/environment/opt/foo/lib instead of just -L/opt/foo/lib ? Then you've got a broken .pc file ;-P The problem is that the build-time (cross-)linker needs to find the (cross-compiled) lib under /my/build/host/target/environment/opt/foo/lib at link time and the shared linker under /opt/foo/lib at run-time. Hmm, after digging into that old project, it seems that libtool and the .la files were the problem. Yes. And even worse the compiled lib foo had explicit dependencies (on lib bar) on /my/build/host/target/environment/opt/bar/lib/libbar.so.1.2.3.4. And that's even more broken. Yup. Maybe it was a result of my trial to make libtool work somehow .. And BTW pkg-config didn't support the concept of a DESTDIR variable (and I don't care about the name of that variable). No, why should it ?! It does not install anything. But it may use installed files. Probably you're looking for sysroot ? Yes, very probably. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
