Hi,
On Thu, 25 May 2000, Kevin Atkinson wrote:
> > Great. Note that it's all not only depending on the compiler, but also on
> > the actual linker used, so $with_gnu_ld should also be tested. E.g. just
> > today I had a report from someone using KDE on Solaris with gcc and GNU
> > ld. Currently that won't work, because on Solaris ltcf-cxx.sh thinks its
> > using the native linker. (for -export-symbols it tries to give -M bla.exp
> > to the linker).
>
> Maybe I am missing something here but can't you just let g++ handle all
> the C++ issues. If G++ does call the native linker and you need to pass
> special options too it this native linker is bound to be the same as the
> linker used for C programs. So then can't C++ libtool get the necessarily
> options to pass (like the rpath stuff) from the C part of libtool. Or am
> I missing something?
Basically it would be not that bad for the C++ part to use as default the
C options having to do with linker work. But that needs some fiddling,
e.g. on C++ the compiler needs to link libraries, not ld itself. On
some platforms this is also the case for C right now, but on others ld
is used directly.
And also right now the two language configurations are splitted, so we
have no access to ltcf-c.sh from ltcf-cxx.sh (besides from duplicating
code ;) ) Also the actual arguments depend on the compiler used, so e.g.
if the user had used native cc for C and GNU g++ for C++ we would loose
(though there is some abstraction mechanism like ${Wl})
Hmm, unless I miss something and we invest some work for infrastructure,
the easiest way IMHO is a thoughtful cut and paste from ltcf-c.sh, (which
basically is your idea, only with more hand work ;)
May be later it would really be a good idea to not only parameterize the
configuration on the language, but also on the linker (well we only have
GNU or native), to not duplicate all the linker dependent work in the
other language modules (if there are ever more than two ;)
Ciao,
Michael.
