On 02/14/2010 10:51 AM, Cristian Morales Vega wrote:

2010/2/14 Dave Plater :

...

Hi, the next generation of the package I maintain, blender has a new feature called collada which enables 3D import and export similar to cad's dxf file format. In order to enable this feature I've had to incorporate a package called openCOLLADA into blender and the build of the package produces several libraries named :- libbuffer.so libftoa.so libGeneratedSaxParser.so libMathMLSolver.so libOpenCOLLADABaseUtils.so libOpenCOLLADAFramework.so libOpenCOLLADASaxFrameworkLoader.so libOpenCOLLADAStreamWriter.so libUTF.so Which following the "Shared_Library_Packaging_Policy" guidlines, I've added a 0.0.0 suffix with symbolic links containing plain .so and .so.0.

The "Shared_Library_Packaging_Policy" guidlines say: "SONAME - the name (query for it using objdump -x libfoo.so.1 | grep SONAME)". "0.0.0" is really the output you get from objdump or you just used that because nothing else was available?

objdump -x doesn't give any output containing upper or lowercase soname for any of the generated libs. The libs build with an .so extension only, I had to add the 0.0.0 suffix and create the links myself. This package is a work in progress package from GOC and they state that the shared lib build is untested, in the output from scons -h, but blender devels have tested it and are happy that it works. I had to patch a few SConscripts and SConstruct to get it to build properly with openSUSE expat and pcre.

...

I'm getting several rpmlint warning which would indicate to me that I've done something wrong, "W: no-soname" for each lib and

Either these files aren't libraries but plugins (shouldn't be in /usr/lib and should be packaged in the main blender package or blender-plugins) or openCOLLADA doesn't follows any versioning scheme. If the latter, either you worry about maintaining an openSUSE-specific soname, or it's better to use the static versions of these libraries.

The "Shared_Library_Packaging_Policy" only makes sense if the libraries maintain sonames that make sense (change every time the binary compatibility is broken).

They are definitely libraries needed for blender-2.50 with Collada import/export to build against and there are sure to be more packages that use them in the future. They should be packaged separately once the package is more mature as it also contains other 3D graphics rendering programs. At the moment I have to create the tarball from svn as there isn't a release yet, I'm just getting the next generation blender in order in advance. It will most probably be another month before blender-2.5 is released. So what to do, fix the versioning and soname generation in openCOLLADA or is there a way for me to package it successfully as it is without altering it? This is a good learning curve for me although collada is the most resource hungry package I've ever built on my box. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 02/14/2010 12:42 PM, Cristian Morales Vega wrote:

It is not just getting it to work, it is to make a promise for the future. If now you package it as libopenCOLLADA0 every new package with that name must be binary compatible with the old version. But you are not under control about that, upstream devs are the ones that decide if they want to break the compatibility.

Looking at the openCOLLADA website it seems they release 3DS Max/Maya plugins. The libOpenCOLLADABaseUtils.so and other libraries look like internal libraries to them, not something they think to release. So, what you need is to contact openCOLLADA devs and know what their plans are: - If they plan to release shared versions of these libs with a sane versioning scheme great. Meanwhile you can use the static versions. Or, if you think more packages will use this library before upstream releases an official version, use a soname that you know they will never use in the future (libOpenCOLLADABaseUtils.so.pre0a?) - If they have no plans to release shared versions bad luck. Perhaps they change the API too frequently and you will never get two packages able to compile with the same version. If so just use the static libs. Otherwise you can think about using your own sonames, but isn't something I would like to do in the long term... Perhaps you could talk with other distro packagers to make it easier and try to maintain some cross-distro compatibility.

I will follow the blender developers decisions because that's the package I maintain, the reason for building the shared libraries in the first place was because the developer of the blender collada section was using shared libraries. They also have a prebuilt dll for their ms windows build. Meanwhile, before I start searching for static lib packaging policies, is building blender against the static libraries and including them in the blender rpm ok? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 02/14/2010 03:28 PM, David Haller wrote:

Hello,

On Sun, 14 Feb 2010, Dave Plater wrote:

...

Meanwhile, before I start searching for static lib packaging policies, is building blender against the static libraries and including them in the blender rpm ok?

You don't need to. Linking with a static library includes all needed objects from the lib in the binary, just as any other object. Here's an example (I have a small "utility lib" of my own):

$ ar t ~/lib/libdhaller.a xmalloc.o xexit.o dhtextutil.o sumiton.o xreadline.o hexdump.o xstrftime.o itoa.o llseek.o mkdtemp.o

Now, let's create a program that uses something from that lib:

$ cat <<EOF > linkingdemo.c #include int main(void) { int sum = sum0ton(8); return sum; } EOF

Now build dynamically:

$ set -x $ gcc -Wl,-t -o linkingdemo linkingdemo.c $(dhaller-config --cflags --libs) ++ dhaller-config --cflags --libs + gcc -Wl,-t -o linkingdemo linkingdemo.c -I/home/dh/include -L/home/dh/lib -ldhaller /opt/gcc/3.3.5/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../../i686-pc-linux-gnu/bin/ld: mode elf_i386 /usr/lib/crt1.o /usr/lib/crti.o /opt/gcc/3.3.5/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.3.5/crtbegin.o /tmp/ccSgP8ha.o -ldhaller (/home/dh/lib/libdhaller.so) -lgcc_s (/opt/gcc/3.3.5/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.3.5/libgcc_s.so) /lib/libc.so.6 -lgcc_s (/opt/gcc/3.3.5/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.3.5/libgcc_s.so) /opt/gcc/3.3.5/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.3.5/crtend.o /usr/lib/crtn.o

Now, the binary is dynamically linked against libdhaller.so. Let's check that:

$ nm linkingdemo | grep sum U sum0ton

Our demo-program _USES_ one function.

And now, let's link statically (only against libdhaller):

$ gcc -Wl,-t -o linkingdemo linkingdemo.c -Wl,-Bstatic $(dhaller-config --cflags --libs) -Wl,-Bdynamic ++ dhaller-config --cflags --libs + gcc -Wl,-t -o linkingdemo linkingdemo.c -Wl,-Bstatic -I/home/dh/include -L/home/dh/lib -ldhaller -Wl,-Bdynamic /opt/gcc/3.3.5/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../../i686-pc-linux-gnu/bin/ld: mode elf_i386 /usr/lib/crt1.o /usr/lib/crti.o /opt/gcc/3.3.5/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.3.5/crtbegin.o /tmp/cceh9bpI.o (/home/dh/lib/libdhaller.a)sumiton.o -lgcc_s (/opt/gcc/3.3.5/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.3.5/libgcc_s.so) /lib/libc.so.6 -lgcc_s (/opt/gcc/3.3.5/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.3.5/libgcc_s.so) /opt/gcc/3.3.5/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.3.5/crtend.o /usr/lib/crtn.o

As you can see in the middle, only 'sumiton.o' gets pulled from libdhaller.a and linked together with the linkingdemo.o (here: /tmp/cceh9bpI.o), and the usual startup stuff and libgcc/libc.

The sumiton.o is an _integral_ part of the resulting binary. Let's check with 'nm':

$ nm linkingdemo | grep sum 08048510 T sum0ton 080484c0 T sumiton

There are (basically) only those two functions in sumiton.o. And our demo-program _CONTAINS_ both functions, the .o from the library was included just like any of "our" object files (here the linkingdemo.o called /tmp/cceh9bpI.o as of gcc magic using tempfiles ;)

So, the conclusion is: Just link statically against those libs (easiest way is just putting the lib in the gcc-call, see below) and your binary _will contain_ the libs. Sample (without the -Wl,-t stuff, it's the same as above):

$ gcc $(dhaller-config --cflags) -o linkingdemo linkingdemo.c ~/lib/libdhaller.a

Remember: you need to put the libs _after_ the code that uses them on the commandline. If I reverse linkingdemo.c and the lib I get:

$ gcc $(dhaller-config --cflags) -o linkingdemo ~/lib/libdhaller.a linkingdemo.c /tmp/cc0cyuLi.o: In function `main': linkingdemo.c:(.text+0x20): undefined reference to `sum0ton' collect2: ld returned 1 exit status

(linkingdemo.c plays the role of the .o object file as well here).

Recap for linking statically:

a) ... OBJECTS_THAT_USE_libfoo ${PATH}/libfoo.a ...

b) ... OBJECTS_THAT_USE_libfoo -Wl,-Bstatic -L${PATH} -lfoo -Wl,-Bdynamic ...

Where ${PATH} may be a relative or absolute path to the lib.

BTW: yes, -Wl,-t (i.e. '-t' option to 'ld') is at times extremely helpful tracking down linking errors :) And "-Wp,-H" is the corresponding option for tracking Header-inclusion ;)

HTH, -dnh

Thanks for the comprehensive explanation, static libs it is for now. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Sun, 14 Feb 2010, Dave Plater wrote:

On 02/14/2010 12:42 PM, Cristian Morales Vega wrote:

...

It is not just getting it to work, it is to make a promise for the future. If now you package it as libopenCOLLADA0 every new package with that name must be binary compatible with the old version. But you are not under control about that, upstream devs are the ones that decide if they want to break the compatibility.

Looking at the openCOLLADA website it seems they release 3DS Max/Maya plugins. The libOpenCOLLADABaseUtils.so and other libraries look like internal libraries to them, not something they think to release. So, what you need is to contact openCOLLADA devs and know what their plans are: - If they plan to release shared versions of these libs with a sane versioning scheme great. Meanwhile you can use the static versions. Or, if you think more packages will use this library before upstream releases an official version, use a soname that you know they will never use in the future (libOpenCOLLADABaseUtils.so.pre0a?) - If they have no plans to release shared versions bad luck. Perhaps they change the API too frequently and you will never get two packages able to compile with the same version. If so just use the static libs. Otherwise you can think about using your own sonames, but isn't something I would like to do in the long term... Perhaps you could talk with other distro packagers to make it easier and try to maintain some cross-distro compatibility.

I will follow the blender developers decisions because that's the package I maintain, the reason for building the shared libraries in the first place was because the developer of the blender collada section was using shared libraries. They also have a prebuilt dll for their ms windows build. Meanwhile, before I start searching for static lib packaging policies, is building blender against the static libraries and including them in the blender rpm ok?

That's probably the best given the current uncertain state of the library. Note that you then simply should not package shared libraries of collanda but instead only have a -devel package which contains the static libraries. It would btw be a good idea to talk to the collanda developers that they fix their make system - a shared library without an SNOAME is broken and will not work. Richard. -- Richard Guenther Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Sun, 14 Feb 2010 14:39:16 +0100 (CET), you wrote:

No SONAME, but at least the library name is changed on every release. (libfmodex-4.28.so -> libfmodex-4.29.so)

If you don't care about ABI compatibility or don't want to maintain it then this is IMO OK because that tells people that no two versions of the library are compatible. Libtool uses the same if you decide to not follow it's rules for handling library versions but instead use --release to force a certain version number. But the fmodex folks should set the soname to the library name. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 02/14/2010 03:37 PM, Richard Guenther wrote:

On Sun, 14 Feb 2010, Dave Plater wrote:

...

On 02/14/2010 12:42 PM, Cristian Morales Vega wrote:

...

It is not just getting it to work, it is to make a promise for the future. If now you package it as libopenCOLLADA0 every new package with that name must be binary compatible with the old version. But you are not under control about that, upstream devs are the ones that decide if they want to break the compatibility.

Looking at the openCOLLADA website it seems they release 3DS Max/Maya plugins. The libOpenCOLLADABaseUtils.so and other libraries look like internal libraries to them, not something they think to release. So, what you need is to contact openCOLLADA devs and know what their plans are: - If they plan to release shared versions of these libs with a sane versioning scheme great. Meanwhile you can use the static versions. Or, if you think more packages will use this library before upstream releases an official version, use a soname that you know they will never use in the future (libOpenCOLLADABaseUtils.so.pre0a?) - If they have no plans to release shared versions bad luck. Perhaps they change the API too frequently and you will never get two packages able to compile with the same version. If so just use the static libs. Otherwise you can think about using your own sonames, but isn't something I would like to do in the long term... Perhaps you could talk with other distro packagers to make it easier and try to maintain some cross-distro compatibility.

I will follow the blender developers decisions because that's the package I maintain, the reason for building the shared libraries in the first place was because the developer of the blender collada section was using shared libraries. They also have a prebuilt dll for their ms windows build. Meanwhile, before I start searching for static lib packaging policies, is building blender against the static libraries and including them in the blender rpm ok?

That's probably the best given the current uncertain state of the library. Note that you then simply should not package shared libraries of collanda but instead only have a -devel package which contains the static libraries.

I don't quite understand the -devel package, should I still package the static libs? The blender-devel package is only for building blender plugins.

It would btw be a good idea to talk to the collanda developers that they fix their make system - a shared library without an SNOAME is broken and will not work.

Richard.

ATM the static version of the libs will only build with their supplied libxml and pcre due to a linker problem with finding pcre. The only successful build I get is with shared libs built against openSUSE libexpat1, the libxml2 build has problems, and libpcre0 has a posix and cpp variations to further confuse me. I'm still fixing the build problems and getting more knowledge of scons and gcc along the way and then I will make a bug at openCOLLADA. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hi, On Mon, 15 Feb 2010, Dave Plater wrote:

Strangely after finally checking the package into BS with the static library build, it succeeds on 11.0 and 11.1 but the collada lib build fails on 11.2 and factory with :- |g++ -o COLLADAValidator/bin/posix/x86_64/debuglibexpat/OpenCOLLADAValidator -static COLLADAValidator/obj/posix/x86_64/debuglibexpat/src/ValidationErrorHandler.o COLLADAValidator/obj/posix/x86_64/debuglibexpat/src/main.o -LCOLLADABaseUtils/lib/posix/x86_64/debug -Lcommon/libftoa/lib/posix/x86_64/debug -Lcommon/libBuffer/lib/posix/x86_64/debug -LCOLLADAFramework/lib/posix/x86_64/debug -LExternals/MathMLSolver/lib/posix/x86_64/debug -LExternals/UTF/lib/posix/x86_64/debug -LCOLLADASaxFrameworkLoader/lib/posix/x86_64/debuglibexpat -LGeneratedSaxParser/lib/posix/x86_64/debuglibexpat -lOpenCOLLADASaxFrameworkLoader -lMathMLSolver -lOpenCOLLADAFramework -lOpenCOLLADABaseUtils -lGeneratedSaxParser -lpcre -lftoa -lbuffer -lUTF -lexpat /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/bin/ld: cannot find -lpcre collect2: ld returned 1 exit status

Why would this happen?

Because libpcre.so is missing, which means pcre-devel is missing from BuildRequires. If it works in 11.0/11.1 it just means that the split into libpcre0 and pcre-devel was only done for 11.2 onwards. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hello, On Mon, 15 Feb 2010, Michael Matz wrote:

On Mon, 15 Feb 2010, Dave Plater wrote:

...

Strangely after finally checking the package into BS with the static library build, it succeeds on 11.0 and 11.1 but the collada lib build fails on 11.2 and factory with :- |g++ -o COLLADAValidator/bin/posix/x86_64/debuglibexpat/OpenCOLLADAValidator -static COLLADAValidator/obj/posix/x86_64/debuglibexpat/src/ValidationErrorHandler.o COLLADAValidator/obj/posix/x86_64/debuglibexpat/src/main.o -LCOLLADABaseUtils/lib/posix/x86_64/debug -Lcommon/libftoa/lib/posix/x86_64/debug -Lcommon/libBuffer/lib/posix/x86_64/debug -LCOLLADAFramework/lib/posix/x86_64/debug -LExternals/MathMLSolver/lib/posix/x86_64/debug -LExternals/UTF/lib/posix/x86_64/debug -LCOLLADASaxFrameworkLoader/lib/posix/x86_64/debuglibexpat -LGeneratedSaxParser/lib/posix/x86_64/debuglibexpat -lOpenCOLLADASaxFrameworkLoader -lMathMLSolver -lOpenCOLLADAFramework -lOpenCOLLADABaseUtils -lGeneratedSaxParser -lpcre -lftoa -lbuffer -lUTF -lexpat /usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/bin/ld: cannot find -lpcre collect2: ld returned 1 exit status

Why would this happen?

Because libpcre.so is missing, which means pcre-devel is missing from BuildRequires. If it works in 11.0/11.1 it just means that the split into libpcre0 and pcre-devel was only done for 11.2 onwards.

Have you seen the -static? 11.1 still shiped libpcre.a. 11.2 does not. Dave: try without '-static' but with '-Wl,-Bstatic' before the Collada-Libs and '-Wl,-Bdynamic' after them (or at least before -lpcre). -dnh -- "Irrigation of the land with sewater desalinated by fusion power is ancient. It's called 'rain'." -- Michael McClary, in alt.fusion -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 02/15/2010 05:36 PM, David Haller wrote:

Have you seen the -static? 11.1 still shiped libpcre.a. 11.2 does not.

Dave: try without '-static' but with '-Wl,-Bstatic' before the Collada-Libs and '-Wl,-Bdynamic' after them (or at least before -lpcre).

-dnh

Thanks again, it works. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 02/15/2010 11:17 PM, David Haller wrote:

Hello,

On Mon, 15 Feb 2010, Dave Plater wrote:

...

On 02/15/2010 05:36 PM, David Haller wrote:

...

Dave: try without '-static' but with '-Wl,-Bstatic' before the Collada-Libs and '-Wl,-Bdynamic' after them (or at least before -lpcre).

Thanks again, it works.

Nice. Look again at my first mail (the long one with the sample compiles)...

-dnh

It was better that I read it after I had solved the problem, it makes much more sense. Thanks for the demonstration of library building and linking, it will help a lot in the future and I've also discovered another useful app in nm. The gcc man page doesn't give much info on -Bstatic and -Bdynamic. Incidentally COLLADAValidator builds a binary and isn't needed by blender anyway but at least it supplied a learning experience for me. Thanks for the knowledge, Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 02/16/2010 02:33 PM, Michael Matz wrote:

Hi,

On Tue, 16 Feb 2010, Dave Plater wrote:

...

It was better that I read it after I had solved the problem, it makes much more sense. Thanks for the demonstration of library building and linking, it will help a lot in the future and I've also discovered another useful app in nm. The gcc man page doesn't give much info on -Bstatic and -Bdynamic.

That is because they are linker options, not gcc options. Try ld(1).

Ciao, Michael.

They don't have anything in the ld man page apart from references to them in other options. There isn't anything to state why they are different from for instance -static. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 02/16/2010 03:08 PM, Michael Matz wrote:

Hi,

On Tue, 16 Feb 2010, Dave Plater wrote:

...

...

That is because they are linker options, not gcc options. Try ld(1).

They don't have anything in the ld man page apart from references to them in other options.

Um, I'm reading this:

-Bdynamic -dy -call_shared Link against dynamic libraries. This is only meaningful on plat- forms for which shared libraries are supported. This option is normally the default on such platforms. The different variants of this option are for compatibility with various systems. You may use this option multiple times on the command line: it affects library searching for -l options which follow it. ... -Bstatic -dn -non_shared -static Do not link against shared libraries. This is only meaningful on platforms for which shared libraries are supported. The different variants of this option are for compatibility with various systems. You may use this option multiple times on the command line: it affects library searching for -l options which follow it. This option also implies --unresolved-symbols=report-all. This option can be used with -shared. Doing so means that a shared library is being created but that all of the library's external references must be resolved by pulling in entries from static libraries.

...

There isn't anything to state why they are different from for instance -static.

In fact they aren't if used as linker options (which means using -Wl,option if gcc is used for linking), hence -Wl,-static ... -Wl,-call_shared is completely the same as -Wl,-Bstatic ... -Wl,-Bdynamic All the above options always influence the following -l arguments, so their behaviour depends on their position in the command line.

But, this is different from using -static as compiler option (i.e. without the -Wl). That one will also internally select a different set of helper libraries (libgcc/libgcc_s), and more importantly, it isn't position dependend, and there's no opposite option (-shared is something completely different, and there's no -Bdynamic equivalent as compiler option).

Ciao, Michael.

Ok now I understand, all 3 and all 4 options share the same description. I've archived this thread for future reference. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 02/16/2010 11:36 PM, David Haller wrote:

Hello,

On Tue, 16 Feb 2010, Dave Plater wrote:

...

It was better that I read it after I had solved the problem, it makes much more sense. Thanks for the demonstration of library building and linking, it will help a lot in the future and I've also discovered another useful app in nm. The gcc man page doesn't give much info on -Bstatic and -Bdynamic.

The gcc-option -Wl passes options to the linker (ld) and -Wp to the preprocessor (cpp). So, to read up on -Bstatic/-Bdynamic, look at 'info ld' ;)

...

Incidentally COLLADAValidator builds a binary and isn't needed by blender anyway but at least it supplied a learning experience for me.

You'll have to do the same when you link blender to the static libs.

-dnh

Blender builds a host of static libs to produce the executable and builds properly with static and shared collada libs. I will study the ld info. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Am 17.02.2010 um 13:19 schrieb Cristian Rodríguez:

On 15/02/10 09:41, Dave Plater wrote:

...

|g++ -o COLLADAValidator/bin/posix/x86_64/debuglibexpat/OpenCOLLADAValidator -static

Also note that static C++ libraries may not work properly if they use RTTI or exceptions.

I thought that's only the case when using a different compiler (version) for the binary and for the library. If not, what's the different between linking against a static library compared to linking with other object files? I mean, .a is only a collection of .o. Regards, Bernhard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Wednesday 2010-02-17 19:01, Philipp Thomas wrote:

* Cristian Rodríguez (crrodriguez@opensuse.org) [20100217 13:20]:

...

Also note that static C++ libraries may not work properly if they use RTTI or exceptions.

Richard, is this true? If so, why?

That would be news to me. RTTI does not postload dynamic libraries like NSS would. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hi, On Thu, 18 Feb 2010, Richard Guenther wrote:

On Wed, 17 Feb 2010, Philipp Thomas wrote:

...

* Cristian Rodríguez (crrodriguez@opensuse.org) [20100217 13:20]:

...

Also note that static C++ libraries may not work properly if they use RTTI or exceptions.

Richard, is this true? If so, why?

I think that is not true anymore.

It never was true. It was and is half-way true :-) Shared libraries linked against _static libgcc_ can't catch or throw exceptions, and depending on the used linker can't even propagate exceptions. Such libraries must be linked against the shared libgcc. (the reason is that parts of the code/data in libgcc implementing the exception machinery must exist only one time in the whole process image, that is all routines fiddling with exceptions have to use the same functions for doing so, not their own copies as would happen if they were linked against static libgcc). Ciao, Michael.

Hello, On Sun, 14 Feb 2010, Michael Matz wrote: [..]

Hence, you need to determine this before. If they turn out to be plugins, you simply need to package them into a non-libdir directory private to COLLADA (and need to make the changes in there to make it find those plugins in that directory).

I agree. Iff they're libraries though, and the 'lib-' prefix suggests that[1], I'd suggest static linking. If they're plugins, they should be included in the main or a -plugin package, and for an SONAME it seems to be common to use just 'foo.so' for the plugin foo.so. To use 'lib-' prefixes or versioned sonames for plugins is a bit uncommon.

In that case you also don't need to add version suffixes. A SONAME still would be good to have but isn't that terribly necessary either anymore.

Aye. For Dave: you can set the SONAME to "libfoo.so.N" by passing -soname libfoo.so.N to the linker ('ld') which you can do via gcc by using -Wl,-soname,libfoo.so.N or the equivalent -Wl,-soname -Wl,libfoo.so.N (or '-Wl,-soname,foo.so' for a plugin) on the commandline creating the .so (i.e. the 'gcc .. -shared ..' call). Depending on the buildsystem, it can be quite a pain to 'insert' that. *sigh* BTW: the SONAME is what rpm will also pick up as a dependency and provide (per default), possibly garnished with arch-stuff. HTH, -dnh [1] OTOH, I see no reason why plugins shouldn't have versions and a lib-prefix. It's just not commonly used / a convention, but I don't actually see where it'd do harm (other than suggest it's a generally useable lib). I think, much of it depends on the naming scheme. And actually, xmms uses lib- prefixes for it's plugins (e.g. ${prefix}/lib/xmms/Output/libdisk_writer.so). If plugins were named like lib${APP}[-_]?plugin[-_]${FUNCTION}.so[.${VERSION}], I don't think there'd be confusions about lib/plugin, e.g.: ${prefix}/lib/xmms/Output/libxmmsplugin_disk_writer.so.0 would be as easily identifiable as a plugin as the current plugin. Or as another example consider: ${prefix}/lib/mplayer/vidix/nvidia_vid.so vs. ${prefix}/lib/mplayer/vidix/libmplayerplugin_vidix_nvidia_vid.so.0 or ${prefix}/lib/mplayer/vidix/libmplayerplugin_vidix_nvidia.so.0 or whatever. --

Whatever happened to the "Measure twice, cut once" idea? -- G. Lane It obviously morphed into "Measure once, cut twice". It has a bias for action, you see. -- B. Iamandei -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 02/14/2010 08:23 PM, David Haller wrote:

Hello,

On Sun, 14 Feb 2010, Michael Matz wrote: [..]

...

Hence, you need to determine this before. If they turn out to be plugins, you simply need to package them into a non-libdir directory private to COLLADA (and need to make the changes in there to make it find those plugins in that directory).

I agree. Iff they're libraries though, and the 'lib-' prefix suggests that[1], I'd suggest static linking. If they're plugins, they should be included in the main or a -plugin package, and for an SONAME it seems to be common to use just 'foo.so' for the plugin foo.so. To use 'lib-' prefixes or versioned sonames for plugins is a bit uncommon.

...

In that case you also don't need to add version suffixes. A SONAME still would be good to have but isn't that terribly necessary either anymore.

Aye. For Dave: you can set the SONAME to "libfoo.so.N" by passing

-soname libfoo.so.N

to the linker ('ld') which you can do via gcc by using

-Wl,-soname,libfoo.so.N

Thanks, I will try that option, I'm still fighting with the SConscript option passing, I have a patch for that. I also need to get scons to accept options passed from the spec file, I think it's "import os" but I've yet to test it.

or the equivalent

-Wl,-soname -Wl,libfoo.so.N

(or '-Wl,-soname,foo.so' for a plugin)

Collada is definitely not a plugin, blender had a collada plugin a few years ago, it's an integrated part of the blender sources that needs to build against the openCOLLADA libraries.

on the commandline creating the .so (i.e. the 'gcc .. -shared ..' call). Depending on the buildsystem, it can be quite a pain to 'insert' that. *sigh*

BTW: the SONAME is what rpm will also pick up as a dependency and provide (per default), possibly garnished with arch-stuff.

Rpm picks up the sonames I created with:- "find *.so -exec mv -v {} {}.0.0.0 \; -exec ln -s {}.0.0.0 {} \; -exec ln -s {}.0.0.0 {}.0 \;" and puts the correct dependencies in blender but I wasn't aware of the SONAME lable in the binary which I imagine is for ldconfig or not?

HTH, -dnh

[1] OTOH, I see no reason why plugins shouldn't have versions and a lib-prefix. It's just not commonly used / a convention, but I don't actually see where it'd do harm (other than suggest it's a generally useable lib). I think, much of it depends on the naming scheme. And actually, xmms uses lib- prefixes for it's plugins (e.g. ${prefix}/lib/xmms/Output/libdisk_writer.so). If plugins were named like lib${APP}[-_]?plugin[-_]${FUNCTION}.so[.${VERSION}], I don't think there'd be confusions about lib/plugin, e.g.: ${prefix}/lib/xmms/Output/libxmmsplugin_disk_writer.so.0 would be as easily identifiable as a plugin as the current plugin. Or as another example consider: ${prefix}/lib/mplayer/vidix/nvidia_vid.so vs. ${prefix}/lib/mplayer/vidix/libmplayerplugin_vidix_nvidia_vid.so.0 or ${prefix}/lib/mplayer/vidix/libmplayerplugin_vidix_nvidia.so.0 or whatever.

Blender has a number of plugins that reside under %_libdir/%name/ and they neither have a version number nor a lib prefix, this was already there when I took over as maintainer and from what I read in Shared_Library_Packaging_Policy is acceptable. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org