diff --git a/ChangeLog b/ChangeLog
index 3ebb06931bd005d4da5c574fe2f8800b853c6f05..ec92ab019128c9dd1f6929e36bec28d8385c1851 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2015-01-13  Niels Möller  <nisse@lysator.liu.se>
 
+	* x86_64/fat/fat.c: For constructor hack, check
+	HAVE_GCC_ATTRIBUTE, not __GNUC__. Also support sun compilers, as
+	suggested by Nikos Mavrogiannopoulos, and attch the constructor
+	attribute directly to fat_init.
+	(fat_constructor): Deleted wrapper function.
+
 	* x86_64/fat/fat.c: New file, initialization for x86_64 fat
 	library.
 
diff --git a/x86_64/fat/fat.c b/x86_64/fat/fat.c
index 3585cf527c6d83fc56ed711cf0bf620e90ec2052..7deb45aeb60f2ebf47dcd72fced108c51969ca44 100644
--- a/x86_64/fat/fat.c
+++ b/x86_64/fat/fat.c
@@ -53,22 +53,21 @@
 
    To get everything hooked in, we use a belt-and-suspenders approach.
 
-   When compiling with gcc, we try to register a constructor function
-   which calls fat_init as soon as the library is loaded. If this is
-   unavailable or non-working, we instead arrange fat_init to be
-   called on demand.
+   We try to register fat_init as a constructor function to be called
+   at load time. If this is unavailable or non-working, we instead
+   arrange fat_init to be called lazily.
 
    For the actual indirection, there are two cases. 
 
    If ifunc support is available, function pointers are statically
    initialized to NULL, and we register resolver functions, e.g.,
-   _aes_encrypt_resolve, which calls fat_init, and then returns the
+   _aes_encrypt_resolve, which call fat_init, and then return the
    function pointer, e.g., the value of _aes_encrypt_vec.
 
    If ifunc is not available, we have to define a wrapper function to
    jump via the function pointer. (FIXME: For internal calls, we could
-   do this as a macro instead). We statically initialize each function
-   pointer to point to a special initialization function, e.g.,
+   do this as a macro). We statically initialize each function pointer
+   to point to a special initialization function, e.g.,
    _aes_encrypt_init, which calls fat_init, and then invokes the right
    function. This way, all pointers are setup correctly at the first
    call to any fat function.
@@ -80,6 +79,13 @@
 # define IFUNC(resolve)
 #endif
 
+#if HAVE_GCC_ATTRIBUTE
+# define CONSTRUCTOR __attribute__ ((constructor))
+#elif defined (__sun)
+# pragma init(fat_init)
+# define CONSTRUCTOR
+#endif
+
 void _nettle_cpuid (uint32_t input, uint32_t regs[4]);
 
 typedef void void_func (void);
@@ -111,7 +117,7 @@ static aes_crypt_internal_func *_aes_decrypt_vec = _aes_decrypt_init;
    it is idempotent, and on x86, pointer updates are atomic, so
    there's no danger if it is called simultaneously from multiple
    threads. */
-static void
+static void CONSTRUCTOR
 fat_init (void)
 {
   static volatile int initialized = 0;
@@ -151,14 +157,6 @@ fat_init (void)
   initialized = 1;
 }
 
-#if __GNUC__
-static void __attribute__ ((constructor))
-fat_constructor (void)
-{
-  fat_init ();
-}
-#endif
-
 #if HAVE_LINK_IFUNC
 
 static void_func *