>
> Arrrgh,
>
> I am experiencing a "libtool" related problem while trying to build a
> RPM (namely libavc1394). Everything *seems* to go fine, real fine
> indeed, the RPMS got built, files in right place, etc. Problem is that
> one binary "does not work". A closer look to this file shows that it
is
> not the expected binary, but a *shell script* beginning with the lines
:
>
> #! /bin/sh
>
> # dvcont - temporary wrapper script for .libs/dvcont
> # Generated by ltmain.sh - GNU libtool 1.3.5 (1.385.2.206 2000/05/27
> 11:12:27)
> #
> # The dvcont program cannot be directly executed until all the libtool
> # libraries that it depends on are installed.
> #
> # This wrapper script should never be moved out of the build
directory.
> # If it is, it will not operate correctly.
>
When you build program that depends on shared libraries you sometimes
need to hardcode library location in this program (not every system
provides ldconfig :-). Even with LD_LIBRARY_PATH this may be needed for
suid programs that often ignore it for security reasons. And even if you
install libraries in standard place yu can't install program until
libraries are really installed. So libtool creates shell wrapper that
basically does something like
LD_LIBRARY_PATH=<your-build-directory> your-real-program
(of course exact contents is system dependent). Real binary program is
hidden somewhere in build directory.
>
> Since I am slowly falling into madness, could someone give me a clue
> about what I did wrong? I rebuilt the package dozens of times, and
still
> get the same problem. It drives me crazy.
You have to install your program using
libtool --mode=install
There were reports about problems with automatic libtoolization used in
Mandrake RPMs. I presume, libtoolize program does not catch all cases
correctly. Here is how your install rule may look like:
$(LIBTOOL) --mode=install $(INSTALL_PROGRAM) $$p
$(DESTDIR)$(bindir)/`echo $$p|sed 's/$(EXEEXT)$$//'|sed
'$(transform)'|sed 's/$$/$(EXEEXT)/'`
-andrej
