Toolchain compilation

Go To Last Post
57 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

I'm going through and compiling the AVR32-linux toolchain on my linux box here at home. There have been a few things not mentioned on the avr32linux website which prevented compilation straight off the bat but most of them I've worked out. This latest one has me stumped though. During compilation of the uClibc, the libc/string/avr32/memset.s file spits out the error that insert.b and insert.h aren't valid ASM instructions. Well, indeed they are not but there they are. The lines from the .patch available from the avr32linux website that insert this erroneous code are

+.Llarge_memset:
+	mov	r8, r11
+	mov	r11, 3
+	insert.b r8:l, r8
+	tst	s, r11
+	insert.h r8:t, r8
+	breq	2f
+

Can anyone tell me what these lines are doing here and how to get them to compile cleanly?

Cheers all,
S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

further inspection and most of the .s files in that directory contain the insert and extract instructions that kill the compilation. There is a list of broken files in the Makefile and adding the offending asm files to this list at least means compilation can complete. Nevertheless, is this just an incomplete port or is there some other reason these not-really-instructions are all through that code?

Cheers again,
S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

looks like someone created a macro in the assembler but forgot to add the definition of it....maybe it is there somewhere but not shown to the files. Have you done a search for insert.b in the directory and see if the definition exists anyway. Or maybe it has just been left out.

Just thoughts, hope they help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Crap, that code is old...insert.b and friends were removed from the instruction set quite some time ago.

Try disabling "arch-specific string optimizations" (or something along those lines). The generic optimized version is actually pretty good.

Could you please list the things you had to to get as far as you did? There are probably other people who have/will run into the same problems.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how wrote:
Crap, that code is old...insert.b and friends were removed from the instruction set quite some time ago.

Try disabling "arch-specific string optimizations" (or something along those lines). The generic optimized version is actually pretty good.

Could you please list the things you had to to get as far as you did? There are probably other people who have/will run into the same problems.


Disabling arch-specific string optimization in the string part of the C library corrects this problem. So it should be a) removed if AVR32 platform is selected or b) reimplemented using AVR32 valid assembler ;)

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Patch to make uClibc build successfully with arch-specific string ops:

http://avr32linux.org/twiki/pub/...

If we're lucky, it's actually correct too. Does anyone know a good test suite for string ops?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cd uClibc-0.9.28\test\string && make ? ;) I'm not in an operating system right now, but I'll give it a go later today.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow, right under my nose. Anyway,

~ # ./string
No errors.

Looking a bit closer, it doesn't seem like it's actually _using_ those optimized routines. I'll see if I can figure out why.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

These two patches should make uClibc use the arch-optimized routines when available:

http://avr32linux.org/twiki/pub/...
http://avr32linux.org/twiki/pub/...

I'm a bit puzzled about the second change, though, as it implies that uClibc has never really used either the arch-optimized versions or the generic optimized versions. So that patch might actually give a quite significant speedup no matter whether you turn on the arch-specific stringops or not.

Must have been changed in 0.9.28 or something, as I'm certain I've compared the various implementations against each other at some point in the past.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"testcopy" revealed another bug in memmove(). This patch fixes it:

http://avr32linux.org/twiki/pub/...

With this as well as the other patches I've posted, all the uClibc tests pass.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cheers how, thanks very much! For others with issues:

I followed the Getting Started on the avr32linux website, what I list below are just the bits that are different from what is said there.

Binutils worked fine once I downloaded the latest versions, for some reason the ones that shipped on my BSP CD was broked.

Next, the bootstrap GCC. The --disable-libmudflap option has to be specified when running ./configure along with with --disable-threads and --enable-languages=c . I have changed this on the avr32linux wiki already. Also note that you must create a folder for the GCC to be compiled in to. For example, on my system I extracted the gcc sources to ~/avr32dev/gcc-4.0.2 and then created a folder ~/avr32dev/gcc. From within this ~/avr32dev/gcc folder you must run ../gcc-4.0.2/configure [options] which then creates the makefile in the ~/avr32dev/gcc folder. A call to make from within the gcc folder will fetch the sources out of /avr32dev/gcc-4.0.2 and place the compiled binaries in /avr32dev/gcc. Simply running ./configure in the gcc-4.0.2 folder will throw up in-place compilation errors.

Preparing kernel headers: Make the changes in the root Makefile if you want but I don't think you actually need to make headers (my Makefile didn't even have that target in it). They seem to be there ready to use.

uClibc. By hacking bits out I got it to compile but now how has done the extra patches, nobody should have a problem. Thanks again how! One interesting thing is that you may need to run 'make defconfig' before 'make menuconfig' as, paradoxically, the defaults don't seem to be set by default :S. Of course, it could just be me being an idiot. Also in the menuconfig, set the include directory to the root of your linux source tree, the script automatically adds the /include. eg, if the sources are in ***/linux-2.6.11/include then just type ***/linux-2.6.11/

Bootloader compiled without an issue once I had the correct version (another example of me being stupid) as did the kernel. If you're having kernel issues, run 'make defconfig' and try compiling again to test whether its a fundamental issue or whether it's just your options not working.

Finally building the full gcc. I haven't sucessfully completed this step yet as I don't think I have correctly installed the uClibc. I will try again tonight and let everyone know my results. In the mean time, does anyone have any insight in to the installation of the uClibc? No instructions are included on the avr32linux website.

Please correct anything in this process that is wrong, I'm no expert and I'm sure some of the stuff I've done just to get it to work could be done better some other way.

Cheers all,
S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, some problems fixed. uClibc had installed itself to /usr/avr32-linux-uclibc but the gcc was looking for it in /usr/avr32-linux. All fixed now. Next problem:


checking for main in -lm... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make: *** [configure-target-libstdc++-v3] error 1

Any ideas? As seems obvious, this problem goes away and everything compiles cleanly so long as I leave c++ off the list of supported languages. Incidentally, the AVR32 patches for the GCC appear to apply cleanly to 4.0.3 as well as 4.0.2, though the problem persists.

Thanking all in advance,
S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had to patch my C++ repository to get it to work well with uClibc.

diff -upr gcc-4.0.2/gcc/cp/cp-gimplify.c gcc-4.0.2-targetcompiler/gcc/cp/cp-gimplify.c
--- gcc-4.0.2/gcc/cp/cp-gimplify.c	2004-12-22 19:00:38.000000000 +0100
+++ gcc-4.0.2-targetcompiler/gcc/cp/cp-gimplify.c	2006-07-26 15:29:06.000000000 +0200
@@ -283,7 +283,10 @@ cp_genericize_r (tree *stmt_p, int *walk
   tree stmt = *stmt_p;
   struct pointer_set_t *p_set = (struct pointer_set_t*) data;
 
-  if (is_invisiref_parm (stmt))
+  if (is_invisiref_parm (stmt)
+      /* Don't dereference parms in a thunk, pass the references through. */
+      && !(DECL_THUNK_P (current_function_decl)
+           && TREE_CODE (stmt) == PARM_DECL))
     {
       *stmt_p = convert_from_reference (stmt);
       *walk_subtrees = 0;
diff -upr gcc-4.0.2/gcc/cp/method.c gcc-4.0.2-targetcompiler/gcc/cp/method.c
--- gcc-4.0.2/gcc/cp/method.c	2005-07-12 13:27:32.000000000 +0200
+++ gcc-4.0.2-targetcompiler/gcc/cp/method.c	2006-07-26 15:29:08.000000000 +0200
@@ -491,7 +491,8 @@ use_thunk (tree thunk_fndecl, bool emit_
 		t = build3 (COND_EXPR, TREE_TYPE (t), cond, t,
 			    cp_convert (TREE_TYPE (t), integer_zero_node));
 	    }
-	  t = force_target_expr (TREE_TYPE (t), t);
+	  if (IS_AGGR_TYPE (TREE_TYPE (t)))
+		  t = build_cplus_new (TREE_TYPE (t), t);
 	  finish_return_stmt (t);
 	}
 
diff -upr gcc-4.0.2/gcc/tree.h gcc-4.0.2-targetcompiler/gcc/tree.h
--- gcc-4.0.2/gcc/tree.h	2005-08-23 09:39:41.000000000 +0200
+++ gcc-4.0.2-targetcompiler/gcc/tree.h	2006-07-26 15:39:56.000000000 +0200
@@ -1001,7 +1001,7 @@ extern void tree_operand_check_failed (i
 
 /* In a CALL_EXPR, means that the call is the jump from a thunk to the
    thunked-to function.  */
-#define CALL_FROM_THUNK_P(NODE) ((NODE)->common.protected_flag)
+#define CALL_FROM_THUNK_P(NODE) (CALL_EXPR_CHECK (NODE)->common.protected_flag)
 
 /* In a type, nonzero means that all objects of the type are guaranteed by the
    language or front-end to be properly aligned, so we can indicate that a MEM
diff -upr gcc-4.0.2/libstdc++-v3/config/locale/generic/c_locale.h gcc-4.0.2-targetcompiler/libstdc++-v3/config/locale/generic/c_locale.h
--- gcc-4.0.2/libstdc++-v3/config/locale/generic/c_locale.h	2005-01-30 15:09:58.000000000 +0100
+++ gcc-4.0.2-targetcompiler/libstdc++-v3/config/locale/generic/c_locale.h	2006-07-26 14:55:30.000000000 +0200
@@ -41,12 +41,18 @@
 #include 
 #include    // get std::strlen
 #include     // get std::snprintf or std::sprintf
+#include 
+#include 
 
 #define _GLIBCXX_NUM_CATEGORIES 0
 
 namespace std
 {
-  typedef int*			__c_locale;
+#ifdef __UCLIBC__
+   typedef __ctype_touplow_t*	__c_locale;
+#else
+   typedef int*			__c_locale;
+#endif
 
   // Convert numeric value of type _Tv to string and return length of
   // string.  If snprintf is available use it, otherwise fall back to
diff -upr gcc-4.0.2/libstdc++-v3/config/os/gnu-linux/ctype_base.h gcc-4.0.2-targetcompiler/libstdc++-v3/config/os/gnu-linux/ctype_base.h
--- gcc-4.0.2/libstdc++-v3/config/os/gnu-linux/ctype_base.h	2004-11-23 10:18:38.000000000 +0100
+++ gcc-4.0.2-targetcompiler/libstdc++-v3/config/os/gnu-linux/ctype_base.h	2006-07-26 14:56:20.000000000 +0200
@@ -31,6 +31,8 @@
 //
 // ISO C++ 14882: 22.1  Locales
 //
+#include 
+#include 
   
 /** @file ctype_base.h
  *  This is an internal header file, included by other library headers.
@@ -43,7 +45,11 @@
   struct ctype_base
   {
     // Non-standard typedefs.
-    typedef const int* 		__to_type;
+#ifdef __UCLIBC__
+    typedef const __ctype_touplow_t*	__to_type;
+#else
+    typedef const int*			__to_type;
+#endif
 
     // NB: Offsets into ctype::_M_table force a particular size
     // on the mask type. Because of this, we don't use an enum.

PS! This is fixed upstream in version 4.1 and "4.2", my fix above is a dirty quick fix.

PPS! Argh, seems like the code-tag is broken, I can email you the patch, just send me a PM with your address.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cheers hce, but no luck. Rather than try and debug the 100,000 line libstdc++ configuration script which was throwing up the error, for now, I just appended libstdc++-v3 to the avr32 $noconfigdirs in the top level configure.in. The same problem then popped up in the libgfortran compilation but since I didn't really need fortran anyway, I just configured the gcc not to compile it. The upshot is that the gcc has finally compiled but without libstdc++. If anyone wants an eye-over the libstdc++ or libgfortran config.log files, give us a pm.

Thanks all,
S.

ps. Is there anywhere where we should be posting bug reports like the above? Should we just do it in the main gcc bugtracker (probably not since 4.0.2 is an old version anyway) or is there somewhere special?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We do not have any bugzilla for GCC, binutils, uClibc etc.

I am able to compile and use the C++ stuff, so I wonder why you are not able to compile it. Included is my configure line:

../configure   --target=avr32-linux --build=i686-pc-linux-gnu --prefix=/usr --with-sysroot=/tftpboot/ap7000 --enable-uclibc --enable-languages=c,c++

The /tftpboot/ap7000 directory is a link to the nfs root for my ap7000 device, similar to /usr/avr32-linux.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wow... I just saw a 3.2x performance improvement on memcpy using those new patches. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, sorry for the delay all. The problem was a dumb one of course. It looks like at some stage I forgot to specify the correct target during the configure. Somewhere, some file was telling some part of the GCC it was being compiled for x86. This file was not cleaned by a make *clean, I assume because it is an x86-only bit and therefore wasn't touched by anything, not even clean, once all was configured for avr32. So, a full deletion of everything gcc-sourcy, reinflate, repatch, reconfigure, now all good. Thanks very much to everyone for their help on this and happy programming!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

I have just installed vmplayer and are running a Fedora image. It is a clean image, with no extra features. I'm having trouble with the toolchain compilation. After downloading and pathcing the binutils, I run the following commands:

./configure --target=avr32-linux

No trouble here. Then I run make. The following error appears:

checking whether strstr must be declared... no
checking whether malloc must be declared... no
checking whether realloc must be declared... no
checking whether free must be declared... no
checking whether getenv must be declared... no
configure: error: *** unknown target vector bfd_elf32_avr32_vec
make: *** [configure-bfd] Error 1

Are there any libraries that I am missing? I have even tried to install all the rpm's first from the BSP that came with the AVR32, but that did not help. Anyone?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you do all the other steps (autoconf, automake etc.) explained on avr32linux.org after applying the patch?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, no. I have not tried that because the same page also tells me the following:

"If you download the pre-patched source, this has already been done for you."

Do I need to run autoconf etc even if I download the pre-patched source? If so, avr32linux should update this information. Or, I should read __even more__ carefully. ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Finnern wrote:
Well, no. I have not tried that because the same page also tells me the following:

"If you download the pre-patched source, this has already been done for you."

Do I need to run autoconf etc even if I download the pre-patched source? If so, avr32linux should update this information. Or, I should read __even more__ carefully. ;-)

No, you don't. I just (wrongly, apparently) assumed that you had the non-pre-patched version as you mentioned patching it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hm, tried what you just recommended, itv. I followed the tutorial on avr32liux for pathcing / compiling binutils. The following error occured when running make:

Configuring in binutils
configure: warning: target_alias=avr32-linux: invalid host type
creating cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
configure: error: can only configure for one host and one target at a time
make: *** [configure-binutils] Error 1

BTW: I was wrong :oops: I did not really download the pre-pathed source. I will try that now, to see what happens. Anyways, something went wrong following the tutorial!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, that's it! Use the pre-pathced source and you will have no trouble compiling! Thanks for the tip itv :-D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Finnern wrote:
Hm, tried what you just recommended, itv. I followed the tutorial on avr32liux for pathcing / compiling binutils. The following error occured when running make:

Configuring in binutils
configure: warning: target_alias=avr32-linux: invalid host type
creating cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
configure: error: can only configure for one host and one target at a time
make: *** [configure-binutils] Error 1

Seems like you _sometimes_ need to run the whole auto* sequence in the binutils subdirectory as well because the autoconf developers apparently thought that staying compatible with themselves is a bad idea.

Or just get the tarball. The reason the tarball is there in the first place is that as soon as you start messing with autoconf, you usually find yourself in a lot of trouble...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how wrote:
the autoconf developers apparently thought that staying compatible with themselves is a bad idea.

:lol: lol :lol:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm still having trouble with the compilation of the toolchain. I have read this thread and especially noted squidgit's comments. I have followed the tutorial on avrlinux.org, but I still get errors while compiling.

The issue now is the uClibc library. I have compiled the kernel (as well as binutils and gcc), but not tweaked on any options in the menuconfig. When running menuconfig for uClibc I added the correct folder for the kernel headers, but nothing else. Firstly I pathed all the files for the uClibc. Is there a special order I should do this? I mean, there are five different pathes...

The following error appears when running make in uClibc:

In file included from ../../ldso/include/ldso.h:26,
                 from ldso.c:33:
../../ldso/include/dl-syscall.h:131: error: expected declaration specifiers or '...' before '__syscall_mmap2'
../../ldso/include/dl-syscall.h:131: error: expected declaration specifiers or '...' before 'addr'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'len'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'prot'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'flags'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'fd'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'offset'
../../ldso/include/dl-syscall.h:132: warning: type defaults to 'int' in declaration of '_syscall6'
../../ldso/include/dl-syscall.h: In function '_dl_mmap':
../../ldso/include/dl-syscall.h:141: warning: implicit declaration of function '__syscall_mmap2'
../../ldso/include/dl-syscall.h:142: warning: return makes pointer from integer without a cast

Anyone familiar with this error?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Finnern wrote:
Firstly I pathed all the files for the uClibc. Is there a special order I should do this? I mean, there are five different pathes...

You probably should apply the avr32 support patch first followed by the string op patches. I've never had an issue applying the string ops patches in alphabetical order which is just how I happen to have done it in the past. One of the great things about patch is that it should complain somewhat if things aren't how it expects them. Were there any 'already applied or reversed patch' messages?

Finnern wrote:
Anyone familiar with this error?

It looks like you're having issues with the __syscall6 macro which is used for the prototype of __syscall_mmap2. This is not defined for all architectures (eg i386 only defines syscall[0-5]) though it should be defined for the AVR32. Given that it's not, it seems like a patching problem after all. Try removing the source tree, re-extracting it and repatching making sure everything goes on cleanly. If you aren't using uClibc-0.9.28 (the one that comes on the BSP), try using that version as there may be something which has just thown the patch utility off.

Good luck!
S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm compiling the toolchain under cygwin.
Following the GettingStarted on avr32linux.
Everything went (allmost) fine until I started compiling kernel.

Here is what I get executing

make ARCH=avr32 CROSS_COMPILE=avr32-linux- KBUILD_HAVE_NLS=no

I set KBUILD_HAVE_NLS to avoid a cygwin-specific(I guess) problem. AFAIK It disables libintl & gettext inside the menuconf/gconf etc.

  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/mod/mk_elfconfig
  MKELF   scripts/mod/elfconfig.h
  HOSTCC  scripts/mod/file2alias.o
In file included from scripts/mod/file2alias.c:13:
scripts/mod/modpost.h:21:1: warning: "ELF_ST_BIND" redefined
In file included from /usr/include/elf.h:20,
                 from scripts/mod/modpost.h:10,
                 from scripts/mod/file2alias.c:13:
/usr/include/sys/elf_generic.h:87:1: warning: this is the location of the previous definition
In file included from scripts/mod/file2alias.c:13:
scripts/mod/modpost.h:22:1: warning: "ELF_ST_TYPE" redefined
In file included from /usr/include/elf.h:20,
                 from scripts/mod/modpost.h:10,
                 from scripts/mod/file2alias.c:13:
/usr/include/sys/elf_generic.h:88:1: warning: this is the location of the previous definition
In file included from scripts/mod/file2alias.c:13:
scripts/mod/modpost.h:26:1: warning: "ELF_R_SYM" redefined
In file included from /usr/include/elf.h:20,
                 from scripts/mod/modpost.h:10,
                 from scripts/mod/file2alias.c:13:
/usr/include/sys/elf_generic.h:84:1: warning: this is the location of the previous definition
In file included from scripts/mod/file2alias.c:13:
scripts/mod/modpost.h:27:1: warning: "ELF_R_TYPE" redefined
In file included from /usr/include/elf.h:20,
                 from scripts/mod/modpost.h:10,
                 from scripts/mod/file2alias.c:13:
/usr/include/sys/elf_generic.h:85:1: warning: this is the location of the previous definition
In file included from scripts/mod/file2alias.c:13:
scripts/mod/modpost.h:119: error: parse error before "Elf32_Section"
scripts/mod/modpost.h:119: warning: no semicolon at end of struct or union
scripts/mod/modpost.h:120: warning: type defaults to `int' in declaration of `export_unused_sec'
scripts/mod/modpost.h:120: warning: data definition has no type or storage class
scripts/mod/modpost.h:121: error: parse error before "export_gpl_sec"
scripts/mod/modpost.h:121: warning: type defaults to `int' in declaration of `export_gpl_sec'
scripts/mod/modpost.h:121: warning: data definition has no type or storage class
scripts/mod/modpost.h:122: error: parse error before "export_unused_gpl_sec"
scripts/mod/modpost.h:122: warning: type defaults to `int' in declaration of `export_unused_gpl_sec'
scripts/mod/modpost.h:122: warning: data definition has no type or storage class
scripts/mod/modpost.h:123: error: parse error before "export_gpl_future_sec"
scripts/mod/modpost.h:123: warning: type defaults to `int' in declaration of `export_gpl_future_sec'
scripts/mod/modpost.h:123: warning: data definition has no type or storage class
scripts/mod/modpost.h:127: error: parse error before '}' token
In file included from scripts/mod/../../include/linux/input.h:19,
                 from scripts/mod/file2alias.c:40:
/usr/include/asm/types.h:21: error: conflicting types for '__u32'
scripts/mod/file2alias.c:32: error: previous declaration of '__u32' was here
scripts/mod/file2alias.c: In function `do_ieee1394_entry':
scripts/mod/file2alias.c:192: warning: unsigned int format, __u32 arg (arg 3)
scripts/mod/file2alias.c:194: warning: unsigned int format, __u32 arg (arg 3)
scripts/mod/file2alias.c:196: warning: unsigned int format, __u32 arg (arg 3)
scripts/mod/file2alias.c:198: warning: unsigned int format, __u32 arg (arg 3)
scripts/mod/file2alias.c: In function `do_pci_entry':
scripts/mod/file2alias.c:220: warning: unsigned int format, __u32 arg (arg 3)
scripts/mod/file2alias.c:221: warning: unsigned int format, __u32 arg (arg 3)
scripts/mod/file2alias.c:222: warning: unsigned int format, __u32 arg (arg 3)
scripts/mod/file2alias.c:223: warning: unsigned int format, __u32 arg (arg 3)
scripts/mod/file2alias.c: In function `do_pcmcia_entry':
scripts/mod/file2alias.c:345: warning: unsigned int format, long unsigned int arg (arg 3)
scripts/mod/file2alias.c:346: warning: unsigned int format, long unsigned int arg (arg 3)
scripts/mod/file2alias.c:347: warning: unsigned int format, long unsigned int arg (arg 3)
scripts/mod/file2alias.c:348: warning: unsigned int format, long unsigned int arg (arg 3)
scripts/mod/file2alias.c: In function `handle_moddevtable':
scripts/mod/file2alias.c:500: error: dereferencing pointer to incomplete type
scripts/mod/file2alias.c:503: error: dereferencing pointer to incomplete type
scripts/mod/file2alias.c:504: error: dereferencing pointer to incomplete type
make[2]: *** [scripts/mod/file2alias.o] Error 1
make[1]: *** [scripts/mod] Error 2
make: *** [scripts] Error 2

I think these errors appear because compiler uses /usr/include/elf.h
instead of
{my-kernel-source-location}/include/elf.h
and so on.
But how do I fix that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

p@k0 wrote:
I think these errors appear because compiler uses /usr/include/elf.h
instead of
{my-kernel-source-location}/include/elf.h
and so on.

Hmm...no, it's supposed to use the host system's version of elf.h because you're compiling host tools at this stage. I don't know why cygwin's version apparently is no good.

Quote:
But how do I fix that?

Try copying the kernel's version of elf.h into /usr/local/include (or somewhere else) and run make with HOST_EXTRACFLAGS=-I/usr/local/include

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Try copying the kernel's version of elf.h into /usr/local/include (or somewhere else) and run make with HOST_EXTRACFLAGS=-I/usr/local/include

Didn't help.
First problem is unknown identifier Elf32_Section in linux-2.6.18-rc4/scripts/mod/modpost.h on line 20.
I searched through my cygwin installation and all the files under linux-2.6.18-rc4/ - this identifier is mentioned only once.
After some googleing I decided to add

typedef unsigned short int Elf32_Section;

at line 16 of modpost.h
This problem disappeared, but I don't think this was the best solution.
Then I run into error caused by

typedef uint32_t	__u32;
typedef uint16_t	__u16;
typedef unsigned char	__u8;

in the linux-2.6.18-rc4/scripts/mod/file2alias.c.
Those typedefs are followed by the

#include "../../include/linux/mod_devicetable.h"
#include "../../include/linux/input.h"

And one of these files include "asm/types.h" somewhere deep inside its inclusion tree.
replacing the typedefs with

#include 

allows me to get no errors on this stage.
But was that the _right_ way?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

squidgit wrote:
Well, some problems fixed. uClibc had installed itself to /usr/avr32-linux-uclibc but the gcc was looking for it in /usr/avr32-linux. All fixed now. Next problem:


checking for main in -lm... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make: *** [configure-target-libstdc++-v3] error 1

Any ideas? As seems obvious, this problem goes away and everything compiles cleanly so long as I leave c++ off the list of supported languages.


Here is the explanation why does that error happen:
http://www.mail-archive.com/gcc-...

Under cygwin I got the same error, the reason was that ld-uClibc-0.9.28.so is not installed when you
"make install" uClibc as described in GettingStarted.
(it's seems strange to me, but a symlink named ld-uClibc.so.0 pointing to that file is created anyway).
I copied ld-uClibc-0.9.28.so in /usr/local/avr32-linux/lib/. Now libstdc++ configures without any problems.
I also executed

make install_runtime PREFIX=/usr/local/avr32-linux/  DEVEL_PREFIX= RUNTIME_PREFIX=

maybe this is also necessary. (GettingStarted says install_runtime to /mnt/target/, if you haven't noticed the difference).

Now I get:

/cygdrive/e/avr32build/build-avr32-linux-gcc/avr32-linux/libstdc++-v3/include/avr32-linux/bits/ctype_noninline.h: In constructor 'std::ctype::ctype(int*, const short unsigned int*, bool, size_t)':
/cygdrive/e/avr32build/build-avr32-linux-gcc/avr32-linux/libstdc++-v3/include/avr32-linux/bits/ctype_noninline.h:85: error: cannot convert 'const __ctype_touplow_t*' to 'const int*' in assignment
/cygdrive/e/avr32build/build-avr32-linux-gcc/avr32-linux/libstdc++-v3/include/avr32-linux/bits/ctype_noninline.h:86: error: cannot convert 'const __ctype_touplow_t*' to 'const int*' in assignment
/cygdrive/e/avr32build/build-avr32-linux-gcc/avr32-linux/libstdc++-v3/include/avr32-linux/bits/ctype_noninline.h: In constructor 'std::ctype::ctype(const short unsigned int*, bool, size_t)':
/cygdrive/e/avr32build/build-avr32-linux-gcc/avr32-linux/libstdc++-v3/include/avr32-linux/bits/ctype_noninline.h:120: error: cannot convert 'const __ctype_touplow_t*' to 'const int*' in assignment
/cygdrive/e/avr32build/build-avr32-linux-gcc/avr32-linux/libstdc++-v3/include/avr32-linux/bits/ctype_noninline.h:121: error: cannot convert 'const __ctype_touplow_t*' to 'const int*' in assignment

2hce You quickfix seems to solve this problem.
But you also mentioned gcc-4.2.
Is it possible to use gcc-4.2 with avr32?
Or maybe when will it be possible?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

p@k0 wrote:
2hce You quickfix seems to solve this problem.
But you also mentioned gcc-4.2.
Is it possible to use gcc-4.2 with avr32?
Or maybe when will it be possible?

Sorry, the only available compiler is 4.0.2 (and the old 4.0.1).

It would be nice upgrading to 4.1.x, or 4.2 which is the current HEAD from SVN I think.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hate that avr32.
After allmost a week of playing with sources/patches and configure-s I finally got avr32-linux-g++.
Here's what I get running it:

foo bar@pako /cygdrive/e/avr32build/soft
$ avr32-linux-g++ hellworld.cc
/usr/local/lib/gcc/avr32-linux/4.0.2/../../../../avr32-linux/lib/libstdc++.so: undefined reference to `std::locale::facet::_S_clone_c_locale(int*&)'
/usr/local/lib/gcc/avr32-linux/4.0.2/../../../../avr32-linux/lib/libstdc++.so: undefined reference to `std::locale::facet::_S_destroy_c_locale(int*&)'
/usr/local/lib/gcc/avr32-linux/4.0.2/../../../../avr32-linux/lib/libstdc++.so: undefined reference to `std::codecvt::codecvt(short*, unsigned long)'
/usr/local/lib/gcc/avr32-linux/4.0.2/../../../../avr32-linux/lib/libstdc++.so: undefined reference to `std::codecvt::codecvt(short*, unsigned long)'
collect2: ld returned 1 exit status

Any ideas?
rebuilding g++ from scratch didn't help.
Maybe I shall try recompiling binutils? :))

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
collect2: ld returned 1 exit status

Which tells you that it is the linker (binutils) which are having trouble finding the C++ library. Perhaps there is something wrong with the installation of your libstdc++?

Could you see if you got it in /usr/avr32-linux/lib/libstdc++.so?

: hcegtvedt@hcegtvedt ~ > grep 'std::codecvt

Seems like I have the symbols in my libstdc++.

What are you trying to compile? If it is a simple program/library, I can give it a go :)

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My libstdc++ libs would also match that query.
Please try compiling the following on your system:

#include 
#include 
#include 
using namespace std;

int main()
{
	vector v;
	v.push_back("Hello");
	cout << "hello world\n";
	return 0;
}

I'm going to recompile gcc with --disable-clocale, but am confused with the lines from gcc-4.0.2/libstdc++-v3/confiugre:

   # Check whether --enable-clocale or --disable-clocale was given.
if test "${enable_clocale+set}" = set; then
  enableval="$enable_clocale"

      case "$enableval" in
       generic|gnu|ieee_1003.1-2001|yes|no|auto) ;;
       *) { { echo "$as_me:$LINENO: error: Unknown argument to enable/disable clocale" >&5
echo "$as_me: error: Unknown argument to enable/disable clocale" >&2;}
   { (exit 1); exit 1; }; } ;;
                          esac

else
  enable_clocale=auto
fi;


  # If they didn't use this option switch, or if they specified --enable
  # with no specific model, we'll have to look for one.  If they
  # specified --disable (???), do likewise.
  if test $enable_clocale = no || test $enable_clocale = yes; then
     enable_clocale=auto
  fi

  # Either a known package, or "auto"
  enable_clocale_flag=$enable_clocale

Seems like --disable-clocale will have no effect, because "no" is replaced with "auto" (and auto is the default value when neither disable nor enable is given).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
: hcegtvedt@hcegtvedt ~/tmp > cat cpptest.cpp
#include 
#include 
#include 
using namespace std;

int main()
{
        vector v;
        v.push_back("Hello");
        cout << "hello world\n";
        return 0;
}
: hcegtvedt@hcegtvedt ~/tmp > avr32-linux-g++ -Wall -o cpptest cpptest.cpp
: hcegtvedt@hcegtvedt ~/tmp >

And then running on target:

~ # /cpptest
hello world
~ #

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hooray! At least it works.
Now I can compile things with avr32-linux-g++.
"Undefined reference" problem seems to be dependent on uClibc configuration.
(After disabling locale & wide character support it started to link w/o errors).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm back on the new toolchain, with the same problems as last time. Everything went fine until "make" on the uClibc:

In file included from ../../ldso/include/ldso.h:26,
                 from ldso.c:33:
../../ldso/include/dl-syscall.h:131: error: expected declaration specifiers or '...' before '__syscall_mmap2'
../../ldso/include/dl-syscall.h:131: error: expected declaration specifiers or '...' before 'addr'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'len'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'prot'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'flags'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'fd'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'offset'
../../ldso/include/dl-syscall.h:132: warning: type defaults to 'int' in declaration of '_syscall6'
../../ldso/include/dl-syscall.h: In function '_dl_mmap':
../../ldso/include/dl-syscall.h:141: warning: implicit declaration of function '__syscall_mmap2'
../../ldso/include/dl-syscall.h:142: warning: return makes pointer from integer without a cast

squidgit wrote:
Were there any 'already applied or reversed patch' messages?

There where no information as the one you are sugesting, squidgit. I have also tried to re-extract, re-patch and and re-make the uClibc. The same error appears! I'm also using the tarball found on the BSP that I recieved from Atmel. One thing though, the file called "uClicb-dot-config", what am I supposed to do with that file? Could this be my problem? :?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
In file included from ../../ldso/include/ldso.h:26,
                 from ldso.c:33:
../../ldso/include/dl-syscall.h:131: error: expected declaration specifiers or '...' before '__syscall_mmap2'
../../ldso/include/dl-syscall.h:131: error: expected declaration specifiers or '...' before 'addr'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'len'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'prot'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'flags'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'fd'
../../ldso/include/dl-syscall.h:132: error: expected declaration specifiers or '...' before 'offset'
../../ldso/include/dl-syscall.h:132: warning: type defaults to 'int' in declaration of '_syscall6'
../../ldso/include/dl-syscall.h: In function '_dl_mmap':
../../ldso/include/dl-syscall.h:141: warning: implicit declaration of function '__syscall_mmap2'
../../ldso/include/dl-syscall.h:142: warning: return makes pointer from integer without a cast

These problems may be caused by wrong kernel headers. What linux kernel do you use? Did you
"make headers_install"?
Did you set the correct path to those headers, when configuring uClibc?
If you don't know what to do, you can perform all mentioned operations again :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Instead of "make headers_install" it'll be "make prepare" if you're using the linux 2.6.16 included on the Atmel BSP, though that doesn't change the fact it has to be done :).

The uclibc-dot-config file could potentially be an issue, certainly worth a try. The idea here is that inside the uClibc folder there should be a .config file telling the makefiles what to make. This is the output file from "make menuconfig" or any other config targets. The uClibc-dot-config file provided on the BSP is a set of defaults for the avr32. AFAIK it should be renamed .config in your uClibc source directory before you run the uClibc "make menuconfig". That way it acts as a set of base settings for you to change through the menus. You shouldn't have to change anything in the menus except the location of the kernel headers made with "make headers_install" or "make prepare".

As mentioned elsewhere though, remember that the headers_install target actually creates a completely seperate directory which contains the correct headers, while the prepare target merely sets up the include directory of your standard linux source tree. If you're using "make prepare" just point the uClibc config utility at your root linux source directory.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes! Got by the last problem I had with the kernel and uClibc. My next problem is that I cannot make the c++ library. The follwing error appears on make:

gcc -c   -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition    -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.0.2-avr32/gcc -I../../gcc-4.0.2-avr32/gcc/. -I../../gcc-4.0.2-avr32/gcc/../include -I../../gcc-4.0.2-avr32/gcc/../libcpp/include     -DSTANDARD_STARTFILE_PREFIX=\"../../../\" -DSTANDARD_EXEC_PREFIX=\"/usr/local/lib/gcc/\" -DSTANDARD_LIBEXEC_PREFIX=\"/usr/local/libexec/gcc/\" -DDEFAULT_TARGET_VERSION=\"4.0.2\" -DDEFAULT_TARGET_MACHINE=\"avr32-linux\" -DSTANDARD_BINDIR_PREFIX=\"/usr/local/bin/\" -DTOOLDIR_BASE_PREFIX=\"../../../../\"  `test "X${SHLIB_LINK}" = "X" || test "yes" != "yes" || echo "-DENABLE_SHARED_LIBGCC"` `test "X${SHLIB_MULTILIB}" = "X" || echo "-DNO_SHARED_LIBGCC_MULTILIB"` \
        -I. -I. -I../../gcc-4.0.2-avr32/gcc -I../../gcc-4.0.2-avr32/gcc/. -I../../gcc-4.0.2-avr32/gcc/../include -I../../gcc-4.0.2-avr32/gcc/../libcpp/include  ../../gcc-4.0.2-avr32/gcc/cp/g++spec.c)
gcc   -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition    -DHAVE_CONFIG_H  -o g++ \
  gcc.o g++spec.o intl.o prefix.o version.o   ../libcpp/libcpp.a   ../libiberty/libiberty.a
rm -f g++-cross
cp g++ g++-cross
cp doc/gcc.1 doc/g++.1
cp: cannot stat `doc/gcc.1': No such file or directory
make[1]: *** [doc/g++.1] Error 1
make[1]: Leaving directory `/home/.. ../gcc/build-gcc-4.0.2-avr32/gcc'
make: *** [all-gcc] Error 2

I ran configure just as they say at avr32linux.org

../gcc-4.0.2-avr32/configure --target=avr32-linux --enable-languages=c,c++

I tried the patch that you provided (inline) in the forum hce, but I was unable to use the patch:

Reversed (or previously applied) patch detected!

I'll try to re-extract, re-patch, re-make ect the whole toolchain once more. Hopefully this will help, since I now know which of the patches to use for the different libraries. The problem with the kernel / uclibc was that I used some old patches as well as the new onces. It is a bit confusing having patches both on the BSP and on avr32linux.org.

Any other tips will be recieved with gratitude! :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you search for "doc/gcc.1" file?

To build avr32-linux-g++ and friends I use:

cd build-avr32-linux-gcc
../gcc-4.0.2/configure --target=avr32-linux --enable-languages=c,c++ --enable-uclibc && make && make install

Note these are 2 commands, "install" is an argument to make, moved to the new line by forum scripts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Code tags are great butchers, eh!

Should --enable-uclibc be --with-uclibc? I've used both and they both seem to work as far as I can easily test. It's supposed to be --with-[PACKAGE] and --enable-[FEATURE] but it seems to me that uClibc isn't really either!

When hce's patch has been discussed, examples have been posted using both of these syntax. If anyone out there is a bit more in the know, which one is correct?

S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, this is my configure:

cd build_gcc
../gcc-4.0.2-targetcompiler/configure --target=avr32-linux --enable-langauges=c,c++ --with-uclibc

(I've also tried with enable-uclibc)
And this is my last lines from the make output

gcc   -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition    -DHAVE_CONFIG_H  -o cc1plus \
      cp/cp-lang.o stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o attribs.o c-common.o c-format.o c-pragma.o c-semantics.o c-lex.o c-dump.o  c-pretty-print.o c-opts.o c-pch.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-gimplify.o tree-inline.o main.o  libbackend.a ../libcpp/libcpp.a ../libcpp/libcpp.a   ../libiberty/libiberty.a
cp/except.o: In function `nothrow_libfn_p':
../../gcc-4.0.2-targetcompiler/gcc/cp/except.c:872: undefined reference to `libc_name_p'
collect2: ld returned 1 exit status
make[1]: *** [cc1plus] Error 1
make[1]: Leaving directory `/home/.. ../avr32/gcc/build-gcc/gcc'
make: *** [all-gcc] Error 2{

I am sure that I have patched and compiled the rest correct, did not get any errors.

This is my make script for the uclibc, is it OK?

make install PREFIX=/usr/local/avr32-linux/

On more thing though, there are a lot of warnings when running make, but no errors (until at the end).
Warnings such as:

In file included from ./tm_p.h:4,
                 from ../../gcc-4.0.2-targetcompiler/gcc/cp/lex.c:38:
../../gcc-4.0.2-targetcompiler/gcc/config/avr32/avr32-protos.h:182: warning: ISO C forbids forward references to ‘enum’ types
../../gcc-4.0.2-targetcompiler/gcc/config/avr32/avr32-protos.h:182: warning: ‘enum rtx_code’ declared inside parameter list
../../gcc-4.0.2-targetcompiler/gcc/config/avr32/avr32-protos.h:182: warning: its scope is only this definition or declaration, which is probably not what you want

What is wrong, and how important are these warnings?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Warnings are normal, I saw plenty of them during build.
Searching through gcc sources I found a note that
gperf 2.7.2 is required to do something.
What is the output when you run

gperf --version
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did not seem to have that installed on the Fedora VM-image. But it is installed now, and the output is now GNU gperf 2.7.2 from gperf --version

I was afraid that the image I use did not have all the required packages installed. Hopefully that was the last one. I'll give it a shot! Thanks! :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh well, back on the "error-horse". Still trying to compile the toolchain, and still getting errors on trying to make the final gcc compiler.

Configure:

../gcc-4.0.2-targetcompiler/configure --target=avr32-linux --enable-languages=c,c++ --enable-uclibc

Running make, and the following error:

/tmp/ccZQBAJz.s: Assembler messages:
/tmp/ccZQBAJz.s:84026: Error: can't resolve `.gnu.linkonce.t._ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE3putES3_RSt8ios_basecm' {.gnu.linkonce.t._ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE3putES3_RSt8ios_basecm section} - `L0 ' {.eh_frame section}
make[3]: *** [locale-inst.lo] Error 1
make[3]: Leaving directory `/home/.. ../gcc_avr32/build-gcc/avr32-linux/libstdc++-v3/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/.. ../gcc_avr32/build-gcc/avr32-linux/libstdc++-v3'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/.. ../gcc_avr32/build-gcc/avr32-linux/libstdc++-v3'
make: *** [all-target-libstdc++-v3] Error 2

Any packages I might have missed?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you start over after installing gpref?
I mean removing gcc-4.0.2-targetcompiler,
or even redoing unpack/patch steps for the gcc source?
It's only a guess. The error is really strange for me.

"Assembler message" - don't know what's that :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

p@k0 wrote:
"Assembler message" - don't know what's that :)

It means that the following messages come from the assembler ;-)

Seems like gcc is trying to take the difference between two symbols in different sections. There's no way the assembler can possibly resolve that, as it doesn't know what addresses those sections will end up at (only the linker knows that.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hepp, p@k0, I did the whole thing all over again, after installing gpref. From scratch! But I still get that error message. Strange...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

YES! :-D Finally I got the toolchain to compile and install. I must have misunderstodd the avr32linux tutorial, because when I changed the folder for the compiled kernel in the uclibc menuconfig from the folder where the kernel is compiled to /usr/local/avr32_linux, the final gcc compiler did not leave any errors!

Thanks a lot to everybody helping me out! :-D

Pages