Re: [Cooker] (HELP!) (rpm) (libtool) (going mad)
Borsenkow Andrej wrote: >>Anyway, I upload the SRPM at http://atlantid.org/rpms just in case >>you're interested to see for yourself. Note that you will need to >>install libraw1394 at the same location (the one in contribs will not >>work). Those packages are safe regarding what is installed and >>uninstalled, I've tested them. >> >> > > I was about to try it but I do not see this RPM there, it was > libavc1394, right? Do you still have a problem? > > -andrej I removed them from my repository, since they are now in contribs (well not my packages : Lenny rebuilt them and solved the problem with the test tools by doing another "testtools" package). For one of the tools, we had to get it in test/.libs instead of test/, though. That's odd but it works now. Grégoire
RE: [Cooker] (HELP!) (rpm) (libtool) (going mad)
> > Anyway, I upload the SRPM at http://atlantid.org/rpms just in case > you're interested to see for yourself. Note that you will need to > install libraw1394 at the same location (the one in contribs will not > work). Those packages are safe regarding what is installed and > uninstalled, I've tested them. > I was about to try it but I do not see this RPM there, it was libavc1394, right? Do you still have a problem? -andrej
Re: [Cooker] (HELP!) (rpm) (libtool) (going mad)
Michael Brown wrote: > Did you try using: > > %prep > %setup > > %build > %configure > %make > > %install > rm -rf $RPM_BUILD_ROOT > %makeinstall > > These "generic" instructions should work for most small packages that have > configure scripts, including (I think) ones that use libtool. Certainly I > remember seeing references to libtool flash past during the %build section > and I have ended up with working packages. Thank you Michael for this help, you seem right! Lenny released libavc1394 a few days ago, but without the binary test programs, and by looking at his spec file, what you've written is exactly what he did. The spec file is generic. But I'm waiting for him to include the binaries though... =) Grégoire
Re: [Cooker] (HELP!) (rpm) (libtool) (going mad)
On Fri, 31 Aug 2001, Grégoire Colbert wrote:
> I never heard before about "libtool", so I'm quite puzzled. I used the
> following lines in my spec file :
>
> %prep
> rm -rf %{buildroot}
> rm -rf $RPM_BUILD_DIR/%name-%version
>
> %setup
>
> %build
> ./configure --prefix=%_prefix
>
> %make prefix=%{buildroot}%_prefix
>
> %install
> %make prefix=%{buildroot}%_prefix install
>
Did you try using:
%prep
%setup
%build
%configure
%make
%install
rm -rf $RPM_BUILD_ROOT
%makeinstall
These "generic" instructions should work for most small packages that have
configure scripts, including (I think) ones that use libtool. Certainly I
remember seeing references to libtool flash past during the %build section
and I have ended up with working packages.
HTH,
Michael
Re: [Cooker] (HELP!) (rpm) (libtool) (going mad)
> > # > > # 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-real-program > > (of course exact contents is system dependent). Real binary program is > hidden somewhere in build directory. > Could be in .libs. -- Geoffrey Lee <[EMAIL PROTECTED]> æé·é¢¨ http://www.wychk.org/~glee $ /usr/games/fortune Anything that can go wrong will go Segmentation fault (core dumped) $
Re: [Cooker] (HELP!) (rpm) (libtool) (going mad)
Andrej Borsenkow wrote: >>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 Thanks for your answer, Andrej, but I did not understand what I was supposed to do with what you wrote... :( Well, I tried to add a "libtool" line in my specfile but it complains about the file dvcont now, as it is not a good libtool file or something like that... Well, ermmm, I will upload the 2mdk package to /incoming, with still *broken* test programs, since the library should work without them anyway. And I will add a "TODO" in the changelog to state that I'm not good enough to fix the binaries. Only hope is that the author of the program comes with a simple solution to fix this problem (but I doubt it is related to his program since it compiles fine from tarball, what is wrong must be the $RPM_BUILD_ROOT that libtool does not use, or something like this). Anyway, I upload the SRPM at http://atlantid.org/rpms just in case you're interested to see for yourself. Note that you will need to install libraw1394 at the same location (the one in contribs will not work). Those packages are safe regarding what is installed and uninstalled, I've tested them. Grégoire
RE: [Cooker] (HELP!) (rpm) (libtool) (going mad)
> > 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-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
[Cooker] (HELP!) (rpm) (libtool) (going mad)
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.
I never heard before about "libtool", so I'm quite puzzled. I used the
following lines in my spec file :
%prep
rm -rf %{buildroot}
rm -rf $RPM_BUILD_DIR/%name-%version
%setup
%build
./configure --prefix=%_prefix
%make prefix=%{buildroot}%_prefix
%install
%make prefix=%{buildroot}%_prefix install
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.
Grégoire
