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

[Thomas Schmitt]

Hi,

> http://autobuild.buildroot.net/results/a5d/a5d0f8bec0d39e48f6dfe4ecc07fe0ca3c6bd70a/build-end.log

> CFLAGS="... -static" ... LDFLAGS=" -static"

I guess this is part of the source of the problem.
But for now i cannot reproduce the clash. Probably because my libtool
does not forward option -static to gcc.

In the log, -static got through to the final linker run.


> libisofs/system_area.c:2478:48: warning: 'already_in_gpt' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
>     int i, ret, do_apm = 0, do_gpt = 0, index, already_in_gpt;

Will have to look at this, too.


> A possible alternative solution for Buildroot would be to disable libcdio
> for xorriso in static builds. Do you think that would be preferable?
> CFLAGS="... -Os ..."

Well, if it is about _lean_ Linux systems, then one should not add the
optional library libcdio to the statically linked xorriso binary.

If ever, then libcdio would offer a benefit on exotic non-Linux systems,
for which libburn does not know how to perform SCSI transactions, or during
bug hunt, if the sg-linux adapter of xorriso is suspected to be buggy
in respect to SCSI transactions.

Actually i am quite surprised by the idea to statically build xorriso.
Give me a few days to make up an opinion.
(... and i need to find out how to make a static xorriso here.)

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

I riddle why the use of libcdio by libburn ever worked.
The public symbol mmc_get_configuration is newer than the option of libburn
to use libcdio as SCSI passthrough facility.
But mmc_set_speed and mmc_read_cd of libcdio are older. They should have
caused trouble already in 2009.

I downloaded the youngest release tarball of libcdio
  https://ftp.gnu.org/gnu/libcdio/libcdio-0.94.tar.gz
and tested GNU xorriso with

   CFLAGS=" -Os -static -static" LDFLAGS=" -static" \
   ./configure --enable-libcdio && time make

on a 64 bit Intel system (Debian 8, arch "amd64").
No protests from the linker. (No libcdio.a used either.)

The new library and its headers are reported to be in use by the resulting
xorriso binary  (old was "h83" and 0.83):

  $ xorriso/xorriso -version
  ...
  libburn OS adapter:  sg-libcdio h94 with libcdio 0.94 x86_64-pc-linux-gnu
  ...

The binary is functional. E.g. it detects my optical drives.

So there must be some magic by compiler or linker which gives the local
functions precedence over the functions of linked dynamic libraries.
I wonder whether this is an official feature on which one can rely for
all architectures at least with GNU build tools.

Well, the clash of internal libburn symbols with the libcdio API is
unfortunate in any case. I will probably have to talk with Rocky Bernstein
about his reserved name spaces from which i have to stay away.


Have a nice day :)

Thomas