ML branch: relinking on linux?
Hi,
I currently don't have time to really look into it, so the description of
the current behaviour of libtool might seem a little wishy-washy, but I
mention it anyway, in case anybody knows right away what caused this:
Basically libtool is relinking when installing, even on linux. Situation
in question is something like:
a/a.la (a convenience lib)
b/b.la (a shared lib)
c/c.la (shared, links in "../a/a.la ../b/b.la")
All are C++ libs.
Note, that b.la is created normally (I mean without a relink_command in
the .la file), but c.la has a relink command. It had that never before I
updated our libtool to HEAD. The former was from 1. August. I believe it
has to do with the change in "hardcode_into_libs=all" behaviour, but
haven't time right now to really investigate. I only know, that
$need_relink (which is configured to "no") is set to "yes" by:
(around line #1924 ltmain.sh)
if test -n "$library_names" &&
{ test "$prefer_static_libs" = no || test -z "$old_library"; }; then
if test "$installed" = no; then
uninst_deplibs="$uninst_deplibs $lib"
need_relink=yes
fi
...
But as far as I can see _that_ sequence hasn't changed since august. Only
in the creation of the .la files (around line #4037) the output of
"relink_command=..." was guarded by a "if test $hardcode_into_libs = all".
What should be done, or was this intentional? The ChangeLog seem to
indicate some confusion regarding hardcode_into_libs.
I also noticed, that, when creating c.la, the reference to ../a/.libs/a.a
is doubled, one time between the usual --{no}-whole-archive flags, and one
time in the normal deplibs-list.
Ideas?
Ciao,
Michael.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Getting error: config/install.sh: not found
On Dec 11, 2000, "Devin L. Ganger" <[EMAIL PROTECTED]> wrote:
> make[1]: Entering directory `/usr/local/src/openjade-1.3'
> make[2]: Entering directory `/usr/local/src/openjade-1.3/lib'
> /usr/local/src/openjade-1.3/libtool --mode=install config/install.sh -c
> libosp.la /usr/local/libconfig/install.sh -c .libs/libosp.so.0.0.0
> Are there any common screwups with libtool that I could check?
Looks more like a Makefile bug. Unless there really is a file named
`lib/config/install.sh' within openjade-1.3.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
CVS Autotools
I'm happy to say that running the test suites of both Libtools and of Automake with CVS Autoconf works fine. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Fix for Arg list too long
Libtool developers:
Using the multi-language-branch as a starting point, I have a working
"libtool" script that incrementally links libraries to prevent running
into limits of the shell. Now I need to clean up the implementation and
auto-generate the proper configuration. I have defined two new shell
variables in libtool, ${incr_archive_cmds} and ${old_incr_archive_cmds},
which
are used instead of ${archive_cmds}/${old_archive_cmds} when
${max_cmd_len} is less
than the length of the expanded "${archive_cmds}/${old_archive_cmds}".
Since ${max_cmd_len} is not compiler-dependent, where should it be
defined?
The value can be determined with a short C program such as this:
#include
#ifdef HAVE_LIMITS_H
# include
#endif
#ifdef HAVE_SYS_PARAM_H
# include
#endif
int main() {
#if defined(ARG_MAX)
printf("ARG_MAX is %i\n", ARG_MAX);
#elif defined(NCARGS)
printf("NCARGS is %i\n", NCARGS);
#else
printf("neither %i\n",-1);
#endif
return (0);
}
Should I define an autoconf macro with similar C code to determine the
command length, or should I just put this in configure.in?
In my current implementation, the old method of linking is used unless
${incr_archive_cmds} is defined AND the command is too long for the
shell.
I was considering setting ${max_cmd_len} to -1 on systems with no limit,
but it seems to be redundant if ${incr_archive_cmds} is not defined,
agree?
I would like a bit of guidance since I seem to be hacking at the core
here.
RMS suggested that it may be better to have libtool read commands from
a file, could one of the maintainers comment on that?
Thanks,
Robert
--
Robert Boehne Software Engineer
Ricardo Software Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email: [EMAIL PROTECTED]
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Fix for Arg list too long
On Dec 12, 2000, Robert Boehne <[EMAIL PROTECTED]> wrote:
> Using the multi-language-branch as a starting point, I have a working
> "libtool" script that incrementally links libraries to prevent running
> into limits of the shell.
Cool!
> I have defined two new shell variables in libtool,
> ${incr_archive_cmds} and ${old_incr_archive_cmds}, which are used
> instead of ${archive_cmds}/${old_archive_cmds} when ${max_cmd_len}
> is less than the length of the expanded
> "${archive_cmds}/${old_archive_cmds}".
I can see the point of old_incr_archive_cmds, given that
old_archive_cmds can be pretty much anything, and you can't count on
being able to incrementally add object files to it, but the good thing
is that old_archive_cmds is only overridden on Cygwin and Mingw.
However, incr_archive_cmds doesn't seem very useful to me. It would
seem to me that it would be easier to arrange for libtool to know how
to use reload_flag to link multiple object files into a single one,
and iterate until the command line is short enough.
> Since ${max_cmd_len} is not compiler-dependent, where should it be
> defined?
Good question. I wish I knew the answer :-)
> The value can be determined with a short C program such as this:
You can't depend on being able to run a C program. Think of
cross-compilation.
But I like the idea of using preprocessor symbols. How about
preprocessing a program with the same #includes you use, but ending
with:
#if defined ARG_MAX
LIBTOOL linelen ARG_MAX
#else
# if defined NCARGS
LIBTOOL linelen NCARGS
# endif
#endif
Then you grep the preprocessed file for '^LIBTOOL linelen *[0-9]* *' and
extract the constant with sed. If there's no such constant, we might
play with binary searching the length by running, say, `ls'. Or just
go with a fixed, reasonable number, that can then be increased on a
per-platform basis.
> In my current implementation, the old method of linking is used unless
> ${incr_archive_cmds} is defined AND the command is too long for the
> shell.
What if the command line is too long and incr_archive_cmds isn't
defined?
> I would like a bit of guidance since I seem to be hacking at the core
> here.
Indeed, you are. Sorry for not being more responsible, I've been far
too busy for the past few weeks :-(
> RMS suggested that it may be better to have libtool read commands from
> a file, could one of the maintainers comment on that?
This is definitely a good idea, but it can only work after what you're
doing is implemented. One issue is that of preventing libtool from
issuing command lines that are too long; the other is that of letting
our users link as many object files as they want with libtool, despite
command-line length limits that might arise in the invocation of
libtool itself. You've been working on the former, but, in many
cases, people with long lists of object files to link into a library
will need the latter too.
I suggest doing one thing at a time.
Thank you *so* much for taking this over this task :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: ML branch: relinking on linux?
Michael Matz wrote:
>
> Hi,
>
> I currently don't have time to really look into it, so the description of
> the current behaviour of libtool might seem a little wishy-washy, but I
> mention it anyway, in case anybody knows right away what caused this:
>
> Basically libtool is relinking when installing, even on linux. Situation
> in question is something like:
>
> a/a.la (a convenience lib)
> b/b.la (a shared lib)
> c/c.la (shared, links in "../a/a.la ../b/b.la")
>
> All are C++ libs.
I'm having some problems with MLB libtool and KDE2 as well.
> Note, that b.la is created normally (I mean without a relink_command in
> the .la file), but c.la has a relink command. It had that never before I
> updated our libtool to HEAD. The former was from 1. August. I believe it
> has to do with the change in "hardcode_into_libs=all" behaviour, but
> haven't time right now to really investigate.
The change you mention (1.232->1.233 on head or 1.200.2.34->1.200.2.35
on MLB) was introduced after I was having trouble with NetBSD. NetBSD
has the following set (for ELF)
hardcode_into_libs=yes
shlibpath_overrides_runpath=yes
hardcode_direct=no
hardcode_minus_L=no
hardcode_shlibpath_var=unsupported
libtool doesn't seem to think that such a platform can do ILD without
relinking because of hardcode_into_libs=yes. I never really understood
why this is the case.
I've just done some testing to confirm what I thought - that this
shouldn't (necessarily) be the case. Here's how I think it could work...
All libraries are linked with the right options to hardcode the INSTALL
directories. For operations that need the uninstalled libraries then
LD_LIBRARY_PATH (or whatever shlibpath_var is) can be used to override
the install directories.
> ...I only know, that
> $need_relink (which is configured to "no") is set to "yes" by:
>
> (around line #1924 ltmain.sh)
> if test -n "$library_names" &&
>{ test "$prefer_static_libs" = no || test -z "$old_library"; }; then
> if test "$installed" = no; then
> uninst_deplibs="$uninst_deplibs $lib"
> need_relink=yes
> fi
>...
I'd agree that this isn't the problem...
> But as far as I can see _that_ sequence hasn't changed since august. Only
> in the creation of the .la files (around line #4037) the output of
> "relink_command=..." was guarded by a "if test $hardcode_into_libs = all".
and that this is...
> What should be done, or was this intentional? The ChangeLog seem to
> indicate some confusion regarding hardcode_into_libs.
I think the orginal code was on the right track, but just missed
something for NetBSD case...
Nick
--
aka [EMAIL PROTECTED], [EMAIL PROTECTED]
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Fix for Arg list too long
Alexandre Oliva wrote:
>
> On Dec 12, 2000, Robert Boehne <[EMAIL PROTECTED]> wrote:
>
> > Using the multi-language-branch as a starting point, I have a working
> > "libtool" script that incrementally links libraries to prevent running
> > into limits of the shell.
>
> Cool!
>
> > I have defined two new shell variables in libtool,
> > ${incr_archive_cmds} and ${old_incr_archive_cmds}, which are used
> > instead of ${archive_cmds}/${old_archive_cmds} when ${max_cmd_len}
> > is less than the length of the expanded
> > "${archive_cmds}/${old_archive_cmds}".
>
> I can see the point of old_incr_archive_cmds, given that
> old_archive_cmds can be pretty much anything, and you can't count on
> being able to incrementally add object files to it, but the good thing
> is that old_archive_cmds is only overridden on Cygwin and Mingw.
>
> However, incr_archive_cmds doesn't seem very useful to me. It would
> seem to me that it would be easier to arrange for libtool to know how
> to use reload_flag to link multiple object files into a single one,
> and iterate until the command line is short enough.
>
Right now, $incr_archive_cmds will first create an archive file one .o
at a time,
then link a shared object with the archive file in place of $libobjs.
This works, _but_ it is an order of magnitude slower than the direct
method
(which of couse, doesn't actually work). Many compilers have a command
line
switch for giving a list of object files in a text file, SGI, HP and
Tru64
all have this with their native compilers. I also just can't shake the
notion
that some platforms won't let you create shared objects from archives.
(of couse I could be wrong)
> But I like the idea of using preprocessor symbols. How about
> preprocessing a program with the same #includes you use, but ending
> with:
>
> #if defined ARG_MAX
> LIBTOOL linelen ARG_MAX
> #else
> # if defined NCARGS
> LIBTOOL linelen NCARGS
> # endif
> #endif
>
> Then you grep the preprocessed file for '^LIBTOOL linelen *[0-9]* *' and
> extract the constant with sed. If there's no such constant, we might
> play with binary searching the length by running, say, `ls'. Or just
> go with a fixed, reasonable number, that can then be increased on a
> per-platform basis.
Ah, yes, I hadn't thought about that, I'll incorporate your suggestion.
Sill I wonder what file to put it in, ltconfig.in seems to be the best
option.
> > In my current implementation, the old method of linking is used unless
> > ${incr_archive_cmds} is defined AND the command is too long for the
> > shell.
>
> What if the command line is too long and incr_archive_cmds isn't
> defined?
In this case there is some work to do, someone needs to add the
definition
of incr_archive_cmds to the ltcf-*.sh files. I can test quite a few
platforms
here (~7) , the rest will be left as an exercise for the reader. ;)
Also, in reading the GNU Coding Standards, the list of unix commands
that
are allowable does not include "wc". I can't help but use it, or
somthing
else not in the list. Will this be a problem? Should we ammend the
list?
Cheers!
Robert
--
Robert Boehne Software Engineer
Ricardo Software Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email: [EMAIL PROTECTED]
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: CVS Autotools
Hi,
Akim Demaille <[EMAIL PROTECTED]> writes:
> I'm happy to say that running the test suites of both Libtools and of
> Automake with CVS Autoconf works fine.
The following simple configure.in seems to be causing problems, with
the latest CVS libtool from the multi-language-branch, and CVS
autoconf.
AC_INIT
AC_PROG_LIBTOOL
AC_PROG_CXX
AC_OUTPUT
It produces:
configure.in:5: error: AC_LANG_ASSERT: current language is not C++: C
../../aclang.m4:909: AC_PROG_CXXCPP is expanded from...
configure.in:5: AC_PROG_CXXCPP is required by...
./aclocal.m4:786: _AC_LIBTOOL_CXX is expanded from...
configure.in:5: _AC_LIBTOOL_CXX is required by...
./aclocal.m4:759: AC_LIBTOOL_CXX is expanded from...
configure.in:5: the top level
AC_LIBTOOL_CXX has an AC_REQUIRE({AC_PROG_CXXCPP]) in it.
- Hari
--
Raja R Harinath -- [EMAIL PROTECTED]
"When all else fails, read the instructions." -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing." -- Roy L Ash
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Fix for Arg list too long
On Dec 12, 2000, Robert Boehne <[EMAIL PROTECTED]> wrote:
> Right now, $incr_archive_cmds will first create an archive file one .o
> at a time,
> then link a shared object with the archive file in place of $libobjs.
> This works
Not portably, I'm afraid. Besides broken systems in which static
libraries just can't be linked into shared libraries, there's also the
issue of forcing the shared library to import *all* symbols from the
object files.
That's why I had suggested the reload_flag approach: instead of
creating archives, you'd be creating new object files out of multiple
ones.
> Ah, yes, I hadn't thought about that, I'll incorporate your suggestion.
> Sill I wonder what file to put it in, ltconfig.in seems to be the best
> option.
libtool.m4 is probably a better idea. Of course, in the
multi-language branch, you'd have to figure out some way to get this
value to ltconfig, but ltconfig no longer exists in mainline, anyway.
And the good thing about using libtool.m4 is that all autoconf macros
will be available.
> Also, in reading the GNU Coding Standards, the list of unix commands
> that are allowable does not include "wc". I can't help but use it,
> or somthing else not in the list. Will this be a problem? Should
> we ammend the list?
Nope. If it's not there, it's not portable. You can test whether
it's available, and, if it's not, fallback to the expr solution. But
even this may fail, so, in desperation mode, you may have to fallback
to something like:
onedotperchar=`echo $cmd | sed 's,.,. ,g'
length=`set $onedotperchar; echo $#`
Or use `awk':
length=`echo cmd | awk '{print length($0);}'`
(I'm not 100% sure length() is in the portable subset of awk, though)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
