[ slightly reordered your answers for ease of consistent answers ]
* Sean Dague wrote on Tue, Nov 16, 2004 at 05:56:11PM CET:
> On Mon, Nov 15, 2004 at 04:20:05PM +0100, Ralf Wildenhues wrote:
> > * Sean Dague wrote on Thu, Nov 11, 2004 at 09:45:40PM CET:
> > > The issue I reported a couple weeks ago is still there. We have now
> > > tracked
> > > down based on a number of versions of libtool to figure out what works and
> > > what doesn't.
> >
> > First: Your build is not VPATH clean, because you are doing a lot of
> > symlinking by hand in several Makefile.am's.
>
> Yes, we are doing this because there is a need to build test cases which use
> our real code, and the symlink solution seemed to be the most workable.
Sure, the idea seems fine to me.
> > BTW, you did not mention your system at all, neither whether you are
> > doing a VPATH build or not. All of this would have been helpful (still
> > is if the problem remains unsolved), also whether or not an installed
> > version of your package exists on your system or not.
>
> Excuse my ignorance, but I'm not sure of what a VPATH build is.
Where the build tree is different from the source tree.
(It's called that way because the necessary `make' feature has to do
with the VPATH make variable).
Example: Your source is in /tmp/openhpi/. I do:
$ mkdir /tmp/build-openhpi && cd /tmp/build-openhpi
$ ../openhpi/configure -C
$ make
Actually, to find such and other dependency bugs quickly, I replaced the
`make' with:
$ make -j2 distcheck
> > First, you should be using $(LN_S) together with AC_PROG_LN_S for symlinks
>
> Agreed, making that change now
>
> > second you should link to $(srcdir)/relpath/$@ instead
>
> Also agreed, making that change now
Watch out. You link to some built sources and some non-built sources.
When trying your code, I replaced the link-setting snippets with
something like
$(REMOTE_LIB_SOURCES):
if test ! -f $@ -a ! -L $@; then \
if test -f ../$@; then \
$(LN_S) ../$@ $@; \
else \
$(LN_S) $(srcdir)/../$@ $@; \
fi; \
fi
so that they would still work regardless where the file-to-link-to was
found. Also, note that this is safe only if $(REMOTE_LIB_SOURCES)
contains only target names in the current directory (also explained in
Autoconf docs).
> > third you should probably instead just
> > be using AC_CONFIG_LINKS and be happy that you don't have to care about
> > this yourself. All explained in Autoconf docs.
>
> I'll look into that possibility as well, though wouldn't that require
> centralizing all linking code to configure.ac, instead of letting the
> Makefile.am deal with it locally?
Yes. This is arguably a deficiency. However, first it replaces each
snippet as above to one short line, second you probably could move it
into a separate .m4 file where you define a macro which you then use in
configure.ac. I don't know if the latter is worth the effort.
> > Apart from these changes, `make distuninstallcheck' is the first part of
> > `make distcheck' to complain, and it complains about some files which
> > `make uninstall' misses to remove. This is with the HEAD branch as well
> > as branch-1-5 of libtool.
> >
> > So, can you try either the patch from
> > http://lists.gnu.org/archive/html/bug-libtool/2004-10/msg00170.html
> > and possibly branch-2-0 from CVS? Please tell us your findings.
>
> I will check it out and report my results.
Great!
> The system I am running on is Mandrake Linux 10.1 on x86 (we've seen the
> failure with FC3 as well).
>
> There is not and installed version of the libraries on my system.
Good to know.
If this thread gets more application-dependent and less
libtool-dependent, we should probably move to some openhpi-related list
(Cc: me then, please, as I don't read any of those).
Regards,
Ralf
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
