Hi, thank you for your response and help. Eric, sorry that you get this mail twice, but accidentally I replied to your via PM (my normal MUA `mutt' handles mailinglists automatically so I forgot it). I'm sorry for the horrible long big attachment in my first mail. This is automatically appended. Finally I decided to continue with some web mail account instead, I hope it is better. On Sat, Sep 6, 2008 at 9:43 PM, Eric Blake <ebb9@xxxxxxx> wrote: > According to Steffen DETTMER on 9/2/2008 3:16 AM: > > If I understood correctly, passing --host in general enables > > cross compiling. > > Yes (and you should also specify --build). I've reread autoconf `Hosts and Cross-compilation' but seems I still do not really understand. We are running with --build=`config.guess` (set by some wrapper script). not that is important, but why isn't this the default? > > My question in short: > > > > How to correctly set mandatory default options like -isystem > > and -nostdlib -lmylibc? > > The same as for non-cross-compilation: > > ./configure CC='my-cross-cc -nostdlib' CFLAGS='-isystem path/to/dir' \ > LIBS='-lmylibc' > > In other words, ./configure should NOT encode these defaults (because they > are not necessarily mandatory defaults for all users), rather, the user > should be responsible for specifying them. So that means, the idea/concept is that a user shall be forced to specify all defaults? Isn't this uncomfortable? When let's say he specifies a non-gcc compiler, in practice he would need to also pass CFLAGS (and some 20 varibles for linker, options and stuff) with values which are logically redundant (i.e. there is not alternative for the /default/). Also, when CFLAGS are passed (and I understood correctly), they should be taken as specified but not modified. Now the user needs to know that when specifying --enable-debug what to add to CFLAGS (and all the others), correct? In the end, the user needs to configure everything manually and know how to do that. I think this conflicts with the idea of autoconf, so I missed something or missunderstood the things. Do you have some pointer to some background information or so? You wrote those defaults are not necessarily mandatory defaults. But whatever default can be overwritten by setting the appropriate variable in any case, correct? Having defaults that cannot work (like CC=myproprietarycompiler with -ggdb or so then just leads to a early configure fail). > > We `defined' a name for this, lets say `arm-ingenico-elf_device' > > (the value of `device' depends) and use this in configure.in case > > statements to select options. Is this wrong and how would it be > > correct? > > In general, writing platform-name-specific tests in configure.ac (the name > configure.in is obsolete) Yes, thanks also for this point. Is there any difference (except that the logical meaning of .in was changed from meaning `input file' to `autoconf input file')? Whenever a configure.in is renamed to configure.ac the sandboxes break, i.e. `make' fails because of a wrong (make) dependency, I think neither autoreconf nor autoreconf --force is able to recover from that. So I hope support for configure.in will last forever :-) > is not the autoconf way. Rather, you should > test for features that a platform either provides or lacks, independently > of the platform's name. Unfortunately, for cross-compilation, this > doesn't always work (since you can't run test binaries, and not all > features can be tested solely at link time), but even then, you are better > off using only names provided in config.guess (patches to add host > triplets to config.guess should be sent to the list mentioned in that file). I think, for gcc and/or GNU/Linux usually platform independent testing works well, but for others I think it often is hard. Also, sometimes headers have functions that cannot be used and sometimes you can even link it. I understand that this is a problem of the used compiler suite / tool chain but not of autoconf. Often, the result then even needs to be post-processed, like making some objcopy or putting some special headers around some boot image, but I didn't found out how to use this correctly (we use some_SCRIPT or so to poll some automake depdenency and autoconf is thinking that some temporary ELF or so binary would be the executable). Is there some howto about such questions or are they considered out of scope? > > How to check compilers/environments with mandatory parameters? > > I still think that the easiest way is writing your cross-compiler in such > a way that you don't need those parameters to be mandatory. In other > words, write a wrapper script that does all the work: > > #!/bin/sh > exec real-cross-cc -isystem path/to/dir "$@" > > and install it on PATH ahead of the cross-compiler. > > > Another way could be to have arm-ingenico-elf_device-gcc etc > > being a wrapper passing -isystem etc, but I think this is > > ugly. > > How is that ugly? It actually sounds the cleanest to me, > because you can then use the wrapper as your cross-compiler > without having to worry about all the details of how to make it > work. This would be easy if the script would be constant, but we would need to generate it, because the system headers directory is a subdirectory of the sandbox but not installed into system, because we have several versions and the exact version depends on the project / sources. The same for libraries. We link statically but need to have the right version. So when using PATH we would need to adjust it in Makefile to cover some subdirectory or using full pathes to CC (maybe something like CC=/home/steffen/project1/platform/bin). On linux, this would mean how to set up a project that includes its own system-independed glibc (or whatever libc) instead of using the one that the systems gcc would use. A big problem is that because the user shall be able to checkout to an arbitrary directory on linux or cygwin or mingw (which does not work, but in theory) and it should work. The wrapper scripts depend on --build and toplevel source and build directory and those scripts are needed for CC=, but CC should be set before configure is run but the scripts are created by configure. Not sure what problems arise from that (we have several configures in subdirectories and a toplevel configure with AC_CONFIG_SUBDIRS, so the first configure would get an CC that does not exists yet?) So how to configure using optionally with part of a toolchain (e.g. libc-wannabe) in a subdirectory? > > This message may contain confidential and/or privileged information. > > It is considered poor netiquette to post email to a publicly archived > mailing list which contains an unenforceable disclaimer. Some people > refuse to reply to such mail on principle. Yes, I understand, agree and I am sorry for that. I hope it is better now. oki, Steffen _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
