Re: [opensuse-packaging] Need help with libname.
[Please, no extra copy via private mail as I do read the list] On Fri, 04 Feb 2011 23:22:45 +0200, Dave Plater <davejplater@gmail.com> wrote:
Am I correct in saying that a full stop "." isn't allowed to be in the library name and needs to be replaced with an underscore "_" ?
Yes, that' what the shared library policy tells you.
Meanwhile you wouldn't have an idea why libtool is naming the devel .so link incorrectly. You can see it taking place in the makeinstall section of the log?
You tell me what project we're talking about and I'll have a look if time permits. I guess I have a few ideas why something like that can happen but I'd like to look first. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 02/05/2011 03:12 AM, Philipp Thomas wrote:
[Please, no extra copy via private mail as I do read the list]
On Fri, 04 Feb 2011 23:22:45 +0200, Dave Plater <davejplater@gmail.com> wrote:
Am I correct in saying that a full stop "." isn't allowed to be in the library name and needs to be replaced with an underscore "_" ?
Yes, that' what the shared library policy tells you.
It does now after I updated the wiki, IIRC the old one said that, the new one didn't but it's something I won't forget anymore.
Meanwhile you wouldn't have an idea why libtool is naming the devel .so link incorrectly. You can see it taking place in the makeinstall section of the log?
You tell me what project we're talking about and I'll have a look if time permits. I guess I have a few ideas why something like that can happen but I'd like to look first.
Philipp
You have a choice with home:plater/mjpegtools and multimedia:libs/mjpegtools or the unfixed openSUSE:Factory/mjpegtools that's broken gstreamer-0_10-plugins-bad. If you look at the requires of gstreamer-0_10-plugins-bad you'll see that it doesn't know where the two libs from mjpegtools come from. I'm still not sure if the gstreamer build is fixed because factory builds are stuck and it doesn't build for < 11.4 and mjpegtools is waiting to be checked in. Vincent Untz went to the conference. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 02/05/2011 03:12 AM, Philipp Thomas wrote:
You tell me what project we're talking about and I'll have a look if time permits. I guess I have a few ideas why something like that can happen but I'd like to look first.
Here's the versioning part of configure.ac : dnl Process this file with autoconf to produce a configure script. AC_INIT([mjpegtools],[2.0.0],[mjpeg-developer@lists.sourceforge.net]) AC_PREREQ(2.57) AC_CONFIG_SRCDIR([lavtools/lav_io.c]) MJPEG_MAJOR_VERSION=1 MJPEG_MINOR_VERSION=99 MJPEG_MICRO_VERSION=0 MJPEG_VERSION=$MJPEG_MAJOR_VERSION.$MJPEG_MINOR_VERSION.$MJPEG_MICRO_VERSION AC_CONFIG_HEADERS([config.h]) AC_CANONICAL_HOST AM_INIT_AUTOMAKE([1.7]) AM_MAINTAINER_MODE # libtool versioning LT_RELEASE=$MJPEG_MAJOR_VERSION.$MJPEG_MINOR_VERSION LT_CURRENT=$MJPEG_MICRO_VERSION LT_REVISION=$MJPEG_MICRO_VERSION LT_AGE=$MJPEG_MICRO_VERSION AC_SUBST(LT_RELEASE) AC_SUBST(LT_CURRENT) AC_SUBST(LT_REVISION) AC_SUBST(LT_AGE) AC_SUBST(LT_STATIC) Can you see anything amiss? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Sat, 05 Feb 2011 13:46:09 +0200, Dave Plater <davejplater@gmail.com> wrote:
Here's the versioning part of configure.ac :
That doesn't help much. Ihave to see that in context.
Can you see anything amiss?
From this, not really. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 02/06/2011 08:04 PM, Philipp Thomas wrote:
On Sat, 05 Feb 2011 13:46:09 +0200, Dave Plater <davejplater@gmail.com> wrote:
Here's the versioning part of configure.ac :
That doesn't help much. Ihave to see that in context.
Can you see anything amiss?
From this, not really.
Philipp
The configure.ac isn't that big, I've been reading and comparing with the libtool website and I suspect the developer did something in good faith but used the wrong macro. The top level Makefile.am is the same as the previous version, the one I reverted to except for this diff with the previous version '+' = new : --- mjpegtools-1.9.0/configure.ac 2009-01-06 08:33:48.000000000 +0200 +++ mjpegtools-2.0.0/configure.ac 2010-12-31 10:05:23.000000000 +0200 @@ -1,18 +1,16 @@ dnl Process this file with autoconf to produce a configure script. -AC_INIT([mjpegtools],[1.9.0],[mjpeg-developer@lists.sourceforge.net]) +AC_INIT([mjpegtools],[2.0.0],[mjpeg-developer@lists.sourceforge.net]) AC_PREREQ(2.57) AC_CONFIG_SRCDIR([lavtools/lav_io.c]) MJPEG_MAJOR_VERSION=1 -MJPEG_MINOR_VERSION=9 +MJPEG_MINOR_VERSION=99 MJPEG_MICRO_VERSION=0 MJPEG_VERSION=$MJPEG_MAJOR_VERSION.$MJPEG_MINOR_VERSION.$MJPEG_MICRO_VERSION AC_CONFIG_HEADERS([config.h]) AC_CANONICAL_HOST -dnl CANONICAL-TARGET is only there because SDL's sdl.m4 is broken. bleah. -AC_CANONICAL_TARGET AM_INIT_AUTOMAKE([1.7]) AM_MAINTAINER_MODE @@ -451,8 +449,11 @@ dnl ********************************************************************** dnl Handle forcing static linkage in key places -if test "x$enable_force_static" = "xyes" ; then +if test "x$enable_static_build" = "xyes" ; then + echo "Forcing static linkage..." LT_STATIC=-all-static +else + echo enable_static_build="\'${enable_static_build}\'" fi Anyway atm I shouldn't be driving a car and I shouldn't be doing anything more than this. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 02/06/2011 11:28 PM, Dave Plater wrote:
On 02/06/2011 08:04 PM, Philipp Thomas wrote:
On Sat, 05 Feb 2011 13:46:09 +0200, Dave Plater <davejplater@gmail.com> wrote:
Here's the versioning part of configure.ac :
That doesn't help much. Ihave to see that in context.
Can you see anything amiss?
From this, not really.
Philipp
The configure.ac isn't that big, I've been reading and comparing with the libtool website and I suspect the developer did something in good faith but used the wrong macro. The top level Makefile.am is the same as the previous version, the one I reverted to except for this diff with the previous version '+' = new : --- mjpegtools-1.9.0/configure.ac 2009-01-06 08:33:48.000000000 +0200 +++ mjpegtools-2.0.0/configure.ac 2010-12-31 10:05:23.000000000 +0200 @@ -1,18 +1,16 @@ dnl Process this file with autoconf to produce a configure script. -AC_INIT([mjpegtools],[1.9.0],[mjpeg-developer@lists.sourceforge.net]) +AC_INIT([mjpegtools],[2.0.0],[mjpeg-developer@lists.sourceforge.net]) AC_PREREQ(2.57) AC_CONFIG_SRCDIR([lavtools/lav_io.c])
MJPEG_MAJOR_VERSION=1 -MJPEG_MINOR_VERSION=9 +MJPEG_MINOR_VERSION=99 MJPEG_MICRO_VERSION=0 MJPEG_VERSION=$MJPEG_MAJOR_VERSION.$MJPEG_MINOR_VERSION.$MJPEG_MICRO_VERSION
AC_CONFIG_HEADERS([config.h])
AC_CANONICAL_HOST -dnl CANONICAL-TARGET is only there because SDL's sdl.m4 is broken. bleah. -AC_CANONICAL_TARGET AM_INIT_AUTOMAKE([1.7]) AM_MAINTAINER_MODE
@@ -451,8 +449,11 @@
dnl ********************************************************************** dnl Handle forcing static linkage in key places -if test "x$enable_force_static" = "xyes" ; then +if test "x$enable_static_build" = "xyes" ; then + echo "Forcing static linkage..." LT_STATIC=-all-static +else + echo enable_static_build="\'${enable_static_build}\'" fi
Anyway atm I shouldn't be driving a car and I shouldn't be doing anything more than this. Dave P
The libraries in 1.9.0 are still .so.0.0.0 but I think the intention is for them to have a major version of 1, this is good autotools practise for me, the answer is most probably in Makefile.am and because libtool rejected the age the developer worked around it and it's come back to haunt. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* Dave Plater (davejplater@gmail.com) [20110207 08:16]:
The libraries in 1.9.0 are still .so.0.0.0 but I think the intention is
Keep in mind that you can have libraries ending in .so with no version following that aren't symlinks. This is the case when yoo call libtool with the --release parameter. In that case you're telling libtool, that the library has a version but is binary incompatible to all other versions. In that case libtool will create libraries with names like lib<name>-<version>.so . This is documented behaviour. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 02/07/2011 02:48 PM, Philipp Thomas wrote:
* Dave Plater (davejplater@gmail.com) [20110207 08:16]:
The libraries in 1.9.0 are still .so.0.0.0 but I think the intention is
Keep in mind that you can have libraries ending in .so with no version following that aren't symlinks. This is the case when yoo call libtool with the --release parameter. In that case you're telling libtool, that the library has a version but is binary incompatible to all other versions. In that case libtool will create libraries with names like lib<name>-<version>.so . This is documented behaviour.
Philipp
That's extra food for thought, but the build log clearly shows libtool symlinking lib.so.0.0.0 with link lib.so.0 OTH what is in configure.ac clearly gets changed along the way. I don't have time to spend on mjpegtools atm, my first shared lib package openCOLLADA has changed a lot and I have to update it to enable the latest blender to build and I've picked up a few problems with the build, one library isn't getting packaged. I'll get back to my libtool "baptism of fire" after openCOLLADA and blender. It looks like the mjpegtools developer knows as much about libtool as I do atm. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* Dave Plater (davejplater@gmail.com) [20110206 22:55]:
The configure.ac isn't that big, I've been reading and comparing with the libtool website and I suspect the developer did something in good faith but used the wrong macro.
Found it! ;-) Something in that way. The error is that configure.ac has: LT_RELEASE=$MJPEG_MAJOR_VERSION.$MJPEG_MINOR_VERSION LT_CURRENT=$MJPEG_MICRO_VERSION LT_REVISION=$MJPEG_MICRO_VERSION LT_AGE=$MJPEG_MICRO_VERSION While initializing LT_RELEASE works this way, the initialisation of the other variables does not work and they all get initialised to '0' as you can see in the generated Makefile. But even if all worked the error is in using all the variables (and IMO in using the variables at all). The author(s) should decide on which way to version the libraries. Either make the libraries binary incompatible and use '-release' in AM_LDFLAGS (or set LT_RELEASE) or decide to care for binary compatibility and follow libtools versioning scheme documented in '(libtool.info.gz)Libtool versioning'. That would mean that the libraries have versions differing from the main package but would IMNSHO be the best solution. I'm trying to come up with a patch that does "The Right Thing"(tm) ;-) Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 02/07/2011 08:31 PM, Philipp Thomas wrote:
* Dave Plater (davejplater@gmail.com) [20110206 22:55]:
The configure.ac isn't that big, I've been reading and comparing with the libtool website and I suspect the developer did something in good faith but used the wrong macro.
Found it! ;-) Something in that way. The error is that configure.ac has:
LT_RELEASE=$MJPEG_MAJOR_VERSION.$MJPEG_MINOR_VERSION LT_CURRENT=$MJPEG_MICRO_VERSION LT_REVISION=$MJPEG_MICRO_VERSION LT_AGE=$MJPEG_MICRO_VERSION
While initializing LT_RELEASE works this way, the initialisation of the other variables does not work and they all get initialised to '0' as you can see in the generated Makefile. But even if all worked the error is in using all the variables (and IMO in using the variables at all).
The author(s) should decide on which way to version the libraries. Either make the libraries binary incompatible and use '-release' in AM_LDFLAGS (or set LT_RELEASE) or decide to care for binary compatibility and follow libtools versioning scheme documented in '(libtool.info.gz)Libtool versioning'. That would mean that the libraries have versions differing from the main package but would IMNSHO be the best solution.
I'm trying to come up with a patch that does "The Right Thing"(tm) ;-)
Philipp
Thanks LT_RELEASE is what becomes the suffix of the libname ie. libname-1.99.so. which I don't think was the intention. I think the developers intention was to step the libs up one $MAJOR_VERSION from what I can gather from his announcement of the 2.0.0 release. Thanks for your help. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 08 Feb 2011 16:05:32 +0200, Dave Plater <davejplater@gmail.com> wrote:
I think the developers intention was to step the libs up one $MAJOR_VERSION from what I can gather from his announcement of the 2.0.0 release.
Which is IMO still wrong. See info '(libtool.info.gz)Updating version info' for how it should be done. Specially the last paragraph: *_Never_* try to set the interface numbers so that they correspond to the release number of your package. This is an abuse that only fosters misunderstanding of the purpose of library versions. Instead, use the `-release' flag (*note Release numbers::), but be warned that every release of your package will not be binary compatible with any other release.
Thanks for your help.
You're welcome. Philip -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 02/08/2011 10:28 PM, Philipp Thomas wrote:
On Tue, 08 Feb 2011 16:05:32 +0200, Dave Plater <davejplater@gmail.com> wrote:
I think the developers intention was to step the libs up one $MAJOR_VERSION from what I can gather from his announcement of the 2.0.0 release.
Which is IMO still wrong. See
info '(libtool.info.gz)Updating version info'
for how it should be done. Specially the last paragraph:
*_Never_* try to set the interface numbers so that they correspond to the release number of your package. This is an abuse that only fosters misunderstanding of the purpose of library versions. Instead, use the `-release' flag (*note Release numbers::), but be warned that every release of your package will not be binary compatible with any other release.
Thanks for your help.
You're welcome.
Philip
I suppose we need to set him right with a patch, there's no activity with the bug yet. I'm planning on attempting to use autotools for a makeinstall of the collada libraries (scons build system) it looks very easy to use and the documentation is easy to understand. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* Dave Plater (davejplater@gmail.com) [20110208 22:15]:
I suppose we need to set him right with a patch, there's no activity with the bug yet.
I'm finishing a patch that uses -release. Therefor the libs will be called lib<xyz>-1.9.so. If upstream decides to really care for the ABI and thus use -version we can easily cahnge that.
I'm planning on attempting to use autotools for a makeinstall of the collada libraries (scons build system)
That would at least increase the number of folks that understand the configuration.
it looks very easy to use and the documentation is easy to understand.
Don't be fooled. The autotools can get rather tricky in some cases, but on the whole automake does IMNSHO make things rather easy. And the documentation is better then that for other build systems. BTW, I finally found the reason for the libxxx-1.9.so.0.0.0! configure.ac has MJPEG_MAJOR_VERSION=1 MJPEG_MINOR_VERSION=9 MJPEG_MICRO_VERSION=0 MJPEG_VERSION=$MJPEG_MAJOR_VERSION.$MJPEG_MINOR_VERSION.$MJPEG_MICRO_VERSION LT_RELEASE=$MJPEG_MAJOR_VERSION.$MJPEG_MINOR_VERSION LT_CURRENT=$MJPEG_MICRO_VERSION LT_REVISION=$MJPEG_MICRO_VERSION LT_AGE=$MJPEG_MICRO_VERSION AC_SUBST(LT_RELEASE) AC_SUBST(LT_CURRENT) AC_SUBST(LT_REVISION) AC_SUBST(LT_AGE) AC_SUBST(LT_STATIC) Which explains why LT_CURRENT, LT_REVISION and LT_AGE are all set to 0. And then the Makefile.am files have: -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) \ -release $(LT_RELEASE) $(EXTRA_LDFLAGS) which results to '-version-info 0:0:0 -release 1.9' being passed to libtool and that's exactly what you get. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* Philipp Thomas (pth@suse.de) [20110209 15:32]:
I'm finishing a patch that uses -release.
Which I did plus a few additional patches. Although I do have check-in rights for multimedia:libs I'm leaving it for you to approve. Note that there is a bug in mplex/main.cc that the compiler warns about and that you'll see reported at the end of a build. The code in question is in CmdLineMultiplexJob::ParseWorkaroundOpt: bool CmdLineMultiplexJob::ParseWorkaroundOpt( const char *optarg ) { char *endptr, *startptr; endptr = const_cast<char *>(optarg); struct { const char *longname; char shortname; bool *flag; } flag_table[] = { { 0, '\0', 0 } }; [...] if( flag_table[flag].longname == 0 ) { std::string message( "Illegal work-around option: not one of "); flag = 0; char sep[] = ","; do { message += flag_table[flag].longname; message += sep; message += flag_table[flag].shortname; ++flag; if( flag_table[flag].longname != 0 ) message += sep; } and that last access to flag_table[flag].longname does AFAICS point to junk on the stack. Please rteport this upstream and ask them how this was intended to work as I don't see the logic and don't have the time to figure it out. HTH Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 02/09/2011 07:05 PM, Philipp Thomas wrote:
* Philipp Thomas (pth@suse.de) [20110209 15:32]:
I'm finishing a patch that uses -release.
Which I did plus a few additional patches. Although I do have check-in rights for multimedia:libs I'm leaving it for you to approve. Note that there is a bug in mplex/main.cc that the compiler warns about and that you'll see reported at the end of a build. The code in question is in CmdLineMultiplexJob::ParseWorkaroundOpt:
bool CmdLineMultiplexJob::ParseWorkaroundOpt( const char *optarg ) { char *endptr, *startptr; endptr = const_cast<char *>(optarg); struct { const char *longname; char shortname; bool *flag; } flag_table[] = { { 0, '\0', 0 } }; [...]
if( flag_table[flag].longname == 0 ) { std::string message( "Illegal work-around option: not one of "); flag = 0; char sep[] = ","; do { message += flag_table[flag].longname; message += sep; message += flag_table[flag].shortname; ++flag; if( flag_table[flag].longname != 0 ) message += sep; }
and that last access to flag_table[flag].longname does AFAICS point to junk on the stack. Please rteport this upstream and ask them how this was intended to work as I don't see the logic and don't have the time to figure it out.
HTH Philipp
That was 1.9.0 which I actually copied from 11.3 update. Now for 2.0.0rc1. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, 09 Feb 2011 19:46:59 +0200, Dave Plater <davejplater@gmail.com> wrote:
That was 1.9.0 which I actually copied from 11.3 update. Now for 2.0.0rc1.
Which shouldn't be too hard, now that the culprit for the versioning mess has been spotted. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (3)
-
Dave Plater -
Philipp Thomas -
Philipp Thomas