[csw-maintainers] opening both 32bit and 64bit shared libs

[Roger Håkansson]

I'm just jumping right in the middle of this thread.

Any reason why all amanda binaries are sparcv8+ and not just sparcv8?

>
> I see what you're saying but the behavior I'm seeing is that it's only
> attempting to open the 64bit lib and never the 32bit one, see below.

Incorrect, which you can see when you run LD_DEBUG and grep for NEEDED.

Also you missed something in your grep...

 > <testing9s:~>   grep open /tmp/amtruss.out |grep -v NOENT | grep gthread
 > open("/opt/csw/lib/sparcv9/libgthread-2.0.so.0", O_RDONLY) = 5
 > open("/opt/csw/lib/sparcv8/libgthread-2.0.so.0", O_RDONLY) = 5

Note "sparcv8", not "sparcv9"

The reason why it tries the v8 only once is that it becomes marked 
needed and is never considered again while the v9 is scrapped each time 
and have to be reconsidered.


> I've been in contact with the Amanda developers and they're not sure
> what's going on or how to proceed. From how things appear the problem is
> outside of the amanda libs and is glib2 related.
>
> I've definitely reached a point where I don't know how to proceed so any
> guidance will be greatly appreciated.
>

I think that you have been sidetracked by all this 32/64-stuff.

You have a 32-bit binary and it is only using 32-bit libraries, period!

The reason for the coredump have nothing to do with sparcv9, but as you 
mentioned in your initial mail, the assertion on lib 48 in glib_init.
g_assert = print error and dump core

This can also be seen if you use dbx on the core file that is produced.


t at 1 (l at 1) program terminated by signal ABRT (Abort)
0xffffffffffffffff:     <bad address 0xffffffffffffffff>
Current function is glib_init
    48       g_assert(!g_thread_supported());
(dbx) where 

current thread: t at 1
   [1] 0xff3dc6f8(0xffbfe930, 0xa3, 0x1, 0x6, 0x2, 0x6), at 0xff3dc6f8
   [2] 0xff3d8ea8(0x1, 0x6, 0x0, 0xfec3c000, 0x2, 0x0), at 0xff3d8ea8
   [3] 0xff3dc658(0x1, 0x6, 0x0, 0xfec3c000, 0x2, 0x13), at 0xff3dc658
   [4] raise(0x6, 0x0, 0xffbfeab8, 0xfec3c000, 0xd3ef4, 0xe400), at 
0xfebd0b28
   [5] abort(0x0, 0x1, 0xe45c, 0xfe825bc8, 0xd3ef4, 0xe400), at 0xfebb6e70
   [6] g_assertion_message(0xe5c0, 0xe400, 0xfe83154c, 0xfffea530, 
0x15800, 0xffbfebd4), at 0xfe77902c
   [7] g_assertion_message_expr(0x256fb0, 0xfe977d60, 0x30, 0xfe97e5ef, 
0xacb70, 0x15800), at 0xfe7790a0
=>[8] glib_init(), line 48 in "glib-util.c"
   [9] device_api_init(), line 59 in "device.c"
   [10] boot_Amanda__Device(my_perl = 0x21370, cv = 0x25b2b8), line 4007 
in "Device.c"


For some reason which the amanda developers have to explain, they want 
to initialize libcurl before glib's threading is initialized, but I 
can't see how that code could really work.

----------------------------------------
     /* set up libcurl (this must happen before threading
      * is initialized) */
#ifdef HAVE_LIBCURL
# ifdef G_THREADS_ENABLED
     g_assert(!g_thread_supported());
# endif
     g_assert(curl_global_init(CURL_GLOBAL_ALL) == 0);
#endif

     /* And set up glib's threads */
#if defined(G_THREADS_ENABLED) && !defined(G_THREADS_IMPL_NONE)
     if (g_thread_supported()) {
         return;
     }
     g_thread_init(NULL);
#endif

----------------------------------------

Either you have to compile amanda without threading or without libcurl.

But if they really mean what they write in the comment (that libcurl 
should be initialized before threading, and not that libcurl cannot work 
together with threading), the code maybe should be:
----------------------------------------
#ifdef HAVE_LIBCURL
# ifdef G_THREADS_ENABLED
     if(g_thread_get_initialized ())
        g_assert(!g_thread_supported());
# endif
     g_assert(curl_global_init(CURL_GLOBAL_ALL) == 0);
#endif
----------------------------------------