Re: [Bug-xorriso] [PATCH] mmc: fix static link with libcdio

[Thomas Schmitt]

Hi,

some update on the consequences of this thread on xorriso's side:

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

This warning in
  
http://autobuild.buildroot.net/results/a5d/a5d0f8bec0d39e48f6dfe4ecc07fe0ca3c6bd70a/build-end.log
is harmless:

  libisofs/system_area.c:2478:48: warning: 'already_in_gpt' may be used 
uninitialized in this function [-Wmaybe-uninitialized]

Code inspection reveils that  already_in_gpt  can be unintialized only
if variable  do_gpt  is 0. The only interpretation of  already_in_gpt  is
this statement:

        if (do_gpt && !already_in_gpt) {

So  already_in_gpt  matters only if  do_gpt  is not 0. In this case the
variable  already_in_gpt  is defined.

Nevertheless i will give it an initialisation.
  
https://dev.lovelyhq.com/libburnia/libisofs/commit/fb8697081badc017f78586e84690a3b2d91c0232

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

Against the compilation error with -static and --enable-libcdio, i have
installed a preliminary ban in ./configure of GNU xorriso.

If it gets triggered, then ./configure --enable-libcdio will report

  WARNING : found option -static in CFLAGS or LDFLAGS
  WARNING : libcdio API conflicts with inner symbols of xorriso
  WARNING : use of libcdio as system adapter disabled

and fall back to the appropriate one out of the built-in system adapter set.

Committed as:
  
https://dev.lovelyhq.com/libburnia/libisoburn/commit/22d552ad60d56a8afef639ef200bffd29d4e1b5e

This is not the final reaction on this issue. I still have to find out
where the precedence of statically linked symbols over dynamically linked
symbols is specified as a standard.

The success of linking xorriso with libcdio currently depends on this
precedence of libburn's private symbols over libcdio's API symbols.
Obviously the same is done on FreeBSD and Solaris, where i tested the
libcdio system adaper, too.


Have a nice day :)

Thomas