[lsb-discuss] LSB conference call agenda (Tuesday, September 5, 11am ET)

[Robert Schweikert]

On Tue, 2006-09-05 at 12:31 -0700, Wichmann, Mats D wrote:
> >Taking the lsbcc and lsbc++ route brings issues with compiler
> >compatibility and usability of the tool itself. Using lsbcc with any
> >compiler other than gcc is not well tested at this point and may or may
> >not work. Again ISVs can lean on compiler vendors to get command line
> >compatibility for a given compiler w.r.t. gcc. However, for 
> >this to work more details about lsbgcc and lsbg++ need to be
> documented. 
> >The man page at present says:
> >
> >" lsbcc  is  designed  to  apply  the  LSB  build rules with a minimum
> >of changes to existing build setups.  When invoked  as  the  compiler,
> >it first  modifies  the  command  line to follow the LSB build rules,
> >then passes the resulting command line on to the regular compiler."
> >
> >This does not specify how the modification takes place.
> 
> It's not terribly complicated.
> 
> Roughly speaking it's the addition of -L/opt/lsb/lib and
> -I/opt/lsb/include to the front of appropriate search paths,
> and the transformation of unescaped -lfoo entries, where
> foo is not an LSB-specified DSO, to -Bstatic -lfoo -Bdynamic.
> You "escape" a library by adding it to LSBCC_SHAREDLIBS -
> any library in that environment variable will not be
> bracketed by the "static" stuff. 

This will not work for us. We have a relatively large number of shared
libraries. As we link each library and executable the list of
dependencies changes. This means we'd have to reset the environment for
every link based on the precomputed dependencies. Setting all the
libraries all the time appears overkill.


>  The linker name is also
> set to be the LSB-specified one.
> 
> In addition, lsbcc has to do a few things by itself. When
> you link against the system's libc.so and libstdc++.so you'll
> see that these are actually not libraries, but linker scripts.
> Since the LSB versions are /not/ linker scripts, lsbcc/lsbc++
> has to do what the linker scripts would have done.
> 
> The operative line in glibc's libc.so is:
> 
> GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
> 
> so to simulate that, we add libc_nonshared to the link line.
> 
> there's also some playing with libgcc_s to imitate what
> gcc does for you silently.

I suspect other compilers handle these behind the scene favors
differently. Thus there might be a problem. On the other hand it might
be interesting to see what happens when using compiler A for object code
generation and then using lsbg++ for linking. Once the problem with the
environment variable (LSBCC_SHAREDLIBS) is solved this might be a
sufficient build time check to guarantee compliance.


> 
-- 
Robert Schweikert                   MAY THE SOURCE BE WITH YOU
(Robert.Schweikert at abaqus.com)                 LINUX
ABAQUS Inc.
Phone : 401-276-7190
FAX : 401-276-4408