[opensuse-packaging] What is an "undefined-non-weak-symbol" and how is it fixed?
A Fedora packager is basing his openCOLLADA on mine and during his review rpmlint picked up "undefined-non-weak-symbol"s in one of the libraries. This seems like something that I should fix and possibly something that our rpmlint needs to check for. This is what shows it up, rpmlint doesn't : ldd -r /usr/lib64/libbuffer.so undefined symbol: _ZN6Common4ftoaEfPc (/usr/lib64/libbuffer.so) undefined symbol: _ZN6Common4dtoaEdPcb (/usr/lib64/libbuffer.so) linux-vdso.so.1 => (0x00007fffe5d37000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f7017757000) libm.so.6 => /lib64/libm.so.6 (0x00007f7017500000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70172e9000) libc.so.6 => /lib64/libc.so.6 (0x00007f7016f7c000) /lib64/ld-linux-x86-64.so.2 (0x00007f7017ca3000) I assume this has to do with the two undefined symbols in libbuffer.so : # c++filt _ZN6Common4ftoaEfPc _ZN6Common4dtoaEdPcb Common::ftoa(float, char*) Common::dtoa(double, char*, bool) The closest match I can find in the sources are from libftoa's (also part of openCOLLADA) Commondtoa.h and Commonftoa.h : /* Copyright (c) 2009 NetAllied Systems GmbH This file is part of Common libftoa. Licensed under the MIT Open Source License, for details please see LICENSE file or the website http://www.opensource.org/licenses/mit-license.php */ #ifndef __COMMON_DTOA_H__ #define __COMMON_DTOA_H__ #include <stdlib.h> namespace Common { /** The minimum size of the buffer, passed to dtoa.*/ static const size_t DTOA_BUFFERSIZE = 30; /** Returns the number of bytes written in to the buffer. @param buffer The buffer the string representation of the number will be written to. Its size must be at least DTOA_BUFFERSIZE. @param doublePrecision If set to true, up to 16 significant digits are written, otherwise 6*/ int dtoa(double f, char* buffer, bool doublePrecision = false); } #endif // __COMMON_DTOA_H__ I won't paste it's brother Commonftoa.h but the package is at : https://build.opensuse.org/package/show?package=openCOLLADA&project=home%3Aplater%3Ablender If you want to see the Fedora review : https://bugzilla.redhat.com/show_bug.cgi?id=694287 Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
A Fedora packager is basing his openCOLLADA on mine and during his review rpmlint picked up "undefined-non-weak-symbol"s in one of the libraries. This seems like something that I should fix and possibly something that our rpmlint needs to check for. This is what shows it up, rpmlint doesn't : ldd -r /usr/lib64/libbuffer.so undefined symbol: _ZN6Common4ftoaEfPc (/usr/lib64/libbuffer.so) undefined symbol: _ZN6Common4dtoaEdPcb (/usr/lib64/libbuffer.so) linux-vdso.so.1 => (0x00007fffe5d37000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f7017757000) libm.so.6 => /lib64/libm.so.6 (0x00007f7017500000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70172e9000) libc.so.6 => /lib64/libc.so.6 (0x00007f7016f7c000) /lib64/ld-linux-x86-64.so.2 (0x00007f7017ca3000)
I assume this has to do with the two undefined symbols in libbuffer.so : # c++filt _ZN6Common4ftoaEfPc _ZN6Common4dtoaEdPcb Common::ftoa(float, char*) Common::dtoa(double, char*, bool)
The closest match I can find in the sources are from libftoa's (also part of openCOLLADA) Commondtoa.h and Commonftoa.h : /* Copyright (c) 2009 NetAllied Systems GmbH
This file is part of Common libftoa.
Licensed under the MIT Open Source License, for details please see LICENSE file or the website http://www.opensource.org/licenses/mit-license.php */
#ifndef __COMMON_DTOA_H__ #define __COMMON_DTOA_H__
#include <stdlib.h>
namespace Common {
/** The minimum size of the buffer, passed to dtoa.*/ static const size_t DTOA_BUFFERSIZE = 30;
/** Returns the number of bytes written in to the buffer. @param buffer The buffer the string representation of the number will be written to. Its size must be at least DTOA_BUFFERSIZE. @param doublePrecision If set to true, up to 16 significant digits are written, otherwise 6*/ int dtoa(double f, char* buffer, bool doublePrecision = false);
}
#endif // __COMMON_DTOA_H__
I won't paste it's brother Commonftoa.h but the package is at : https://build.opensuse.org/package/show?package=openCOLLADA&project=home%3Aplater%3Ablender If you want to see the Fedora review : https://bugzilla.redhat.com/show_bug.cgi?id=694287
Thanks Dave P Hi Can't help with your issue, but did note that your using dos2unix, see
On Fri, 2011-04-22 at 00:56 +0200, Dave Plater wrote: this ;) http://en.opensuse.org/openSUSE:Packaging_checks#wrong-file-end-of-line-enco... -- Cheers Malcolm °¿° (Linux Counter #276890) SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.32.29-0.3-default up 3 days 20:08, 4 users, load average: 0.32, 0.30, 0.19 GPU GeForce 8600 GTS Silent - Driver Version: 270.41.03 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Apr 21, 11 18:43:06 -0500, Malcolm wrote:
Hi Can't help with your issue, but did note that your using dos2unix, see this ;) http://en.opensuse.org/openSUSE:Packaging_checks#wrong-file-end-of-line-enco...
Dos2unix is not that bad. You may want to avoid 'dos2unix -c iso' which also mangles the encoding. I've updated the wiki page to reflect those details. Malcolm, do you confirm? cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) SuSE. Supporting Linux since 1992. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 22/04/11 13:09, Juergen Weigert wrote:
Dos2unix is not that bad. You may want to avoid 'dos2unix -c iso' which also mangles the encoding. I've updated the wiki page to reflect those details. Malcolm, do you confirm?
I don't get it. the wikipage says: You must not use dos2unix in iso mode, because that not only changes CRLF to LF, but also changes the encoding from CP437 to ISO-8859-1. Use one of: * dos2unix -c ascii file * ... other options But when I check dos2unix manpage it says: -c, --convmode CONVMODE Set conversion mode. Where CONVMODE is one of: ascii, 7bit, iso, mac with ascii being the default. So -c ascii does not make sense I guess as dos2unix by default uses ascii and not iso. For the same reason the whole "must not use dos2unix in iso mode" warning seems invalid. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Friday 2011-04-22 13:40, Pavol Rusnak wrote:
On 22/04/11 13:09, Juergen Weigert wrote:
Dos2unix is not that bad. You may want to avoid 'dos2unix -c iso' which also mangles the encoding. I've updated the wiki page to reflect those details. Malcolm, do you confirm?
I don't get it.
the wikipage says:
You must not use dos2unix in iso mode, because that not only changes CRLF to LF, but also changes the encoding from CP437 to ISO-8859-1. Use one of:
* dos2unix -c ascii file * ... other options
But when I check dos2unix manpage it says:
-c, --convmode CONVMODE Set conversion mode. Where CONVMODE is one of: ascii, 7bit, iso, mac with ascii being the default.
So -c ascii does not make sense I guess as dos2unix by default uses ascii and not iso. For the same reason the whole "must not use dos2unix in iso mode" warning seems invalid.
-c ascii was not always the default. Now it is. Irk. One more reason to have just used perl. Better safe than sorry. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Apr 22, 11 14:10:19 +0200, Jan Engelhardt wrote:
On Friday 2011-04-22 13:40, Pavol Rusnak wrote:
So -c ascii does not make sense I guess as dos2unix by default uses ascii and not iso. For the same reason the whole "must not use dos2unix in iso mode" warning seems invalid.
-c ascii was not always the default. Now it is. Irk. One more reason to have just used perl. Better safe than sorry.
Given that Jan found one cannot always rely on the default (e.g. for building old distributions) the warning makes sense. No? cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) SuSE. Supporting Linux since 1992. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* Pavol Rusnak <prusnak@opensuse.org> [2011-04-22 13:40]:
* dos2unix -c ascii file * ... other options
But when I check dos2unix manpage it says:
There seems to be even different versions of dos2unix around on different Linux distributions. SUSE uses [1] while Arch Linux provides the dos2unix binary in the hd2u package from [2]. The last one doesn't even have that '-c' option. Regards, Bernhard [1] http://www.xs4all.nl/~waterlan/#DOS2UNIX [2] http://hany.sk/~hany/software/hd2u/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 04/22/2011 03:42 PM, Bernhard Walle wrote:
There seems to be even different versions of dos2unix around on different Linux distributions. SUSE uses [1] while Arch Linux provides the dos2unix binary in the hd2u package from [2]. The last one doesn't even have that '-c' option.
Thanks for the info. Maybe we should pick one option and promote using that one: I'd suggest sed -i 's/\r$//' $file because it does not introduce any extra dependencies and most of the people understand that. I'll patch spec-cleaner to consolidate this usage ... -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
El 21/04/11 19:56, Dave Plater escribió:
A Fedora packager is basing his openCOLLADA on mine and during his review rpmlint picked up "undefined-non-weak-symbol"s in one of the libraries. This seems like something that I should fix and possibly something that our rpmlint needs to check for. This is what shows it up, rpmlint doesn't : ldd -r /usr/lib64/libbuffer.so undefined symbol: _ZN6Common4ftoaEfPc (/usr/lib64/libbuffer.so) undefined symbol: _ZN6Common4dtoaEdPcb (/usr/lib64/libbuffer.so) linux-vdso.so.1 => (0x00007fffe5d37000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f7017757000) libm.so.6 => /lib64/libm.so.6 (0x00007f7017500000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70172e9000) libc.so.6 => /lib64/libc.so.6 (0x00007f7016f7c000) /lib64/ld-linux-x86-64.so.2 (0x00007f7017ca3000)
I assume this has to do with the two undefined symbols in libbuffer.so : # c++filt _ZN6Common4ftoaEfPc _ZN6Common4dtoaEdPcb Common::ftoa(float, char*) Common::dtoa(double, char*, bool)
The closest match I can find in the sources are from libftoa's (also part of openCOLLADA) Commondtoa.h and Commonftoa.h :
You just answered your own cuestion, link libbuffer.so against libftoa... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 04/22/2011 01:53 AM, Cristian Rodríguez wrote:
El 21/04/11 19:56, Dave Plater escribió:
A Fedora packager is basing his openCOLLADA on mine and during his review rpmlint picked up "undefined-non-weak-symbol"s in one of the libraries. This seems like something that I should fix and possibly something that our rpmlint needs to check for. This is what shows it up, rpmlint doesn't : ldd -r /usr/lib64/libbuffer.so undefined symbol: _ZN6Common4ftoaEfPc (/usr/lib64/libbuffer.so) undefined symbol: _ZN6Common4dtoaEdPcb (/usr/lib64/libbuffer.so) linux-vdso.so.1 => (0x00007fffe5d37000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f7017757000) libm.so.6 => /lib64/libm.so.6 (0x00007f7017500000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70172e9000) libc.so.6 => /lib64/libc.so.6 (0x00007f7016f7c000) /lib64/ld-linux-x86-64.so.2 (0x00007f7017ca3000)
I assume this has to do with the two undefined symbols in libbuffer.so : # c++filt _ZN6Common4ftoaEfPc _ZN6Common4dtoaEdPcb Common::ftoa(float, char*) Common::dtoa(double, char*, bool)
The closest match I can find in the sources are from libftoa's (also part of openCOLLADA) Commondtoa.h and Commonftoa.h :
You just answered your own cuestion, link libbuffer.so against libftoa...
Aha "LINKFLAGS=-lftoa"? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 04/22/2011 01:53 AM, Cristian Rodríguez wrote:
El 21/04/11 19:56, Dave Plater escribió:
A Fedora packager is basing his openCOLLADA on mine and during his review rpmlint picked up "undefined-non-weak-symbol"s in one of the libraries. This seems like something that I should fix and possibly something that our rpmlint needs to check for. This is what shows it up, rpmlint doesn't : ldd -r /usr/lib64/libbuffer.so undefined symbol: _ZN6Common4ftoaEfPc (/usr/lib64/libbuffer.so) undefined symbol: _ZN6Common4dtoaEdPcb (/usr/lib64/libbuffer.so) linux-vdso.so.1 => (0x00007fffe5d37000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f7017757000) libm.so.6 => /lib64/libm.so.6 (0x00007f7017500000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70172e9000) libc.so.6 => /lib64/libc.so.6 (0x00007f7016f7c000) /lib64/ld-linux-x86-64.so.2 (0x00007f7017ca3000)
I assume this has to do with the two undefined symbols in libbuffer.so : # c++filt _ZN6Common4ftoaEfPc _ZN6Common4dtoaEdPcb Common::ftoa(float, char*) Common::dtoa(double, char*, bool)
The closest match I can find in the sources are from libftoa's (also part of openCOLLADA) Commondtoa.h and Commonftoa.h :
You just answered your own cuestion, link libbuffer.so against libftoa...
It actually needed "-L../libftoa/lib -lftoa" because I had a "can't find ftoa". Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, 21 Apr 2011, Cristian Rodríguez wrote:
El 21/04/11 19:56, Dave Plater escribió:
A Fedora packager is basing his openCOLLADA on mine and during his review rpmlint picked up "undefined-non-weak-symbol"s in one of the libraries. This seems like something that I should fix and possibly something that our rpmlint needs to check for. This is what shows it up, rpmlint doesn't : ldd -r /usr/lib64/libbuffer.so undefined symbol: _ZN6Common4ftoaEfPc (/usr/lib64/libbuffer.so) undefined symbol: _ZN6Common4dtoaEdPcb (/usr/lib64/libbuffer.so) linux-vdso.so.1 => (0x00007fffe5d37000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f7017757000) libm.so.6 => /lib64/libm.so.6 (0x00007f7017500000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70172e9000) libc.so.6 => /lib64/libc.so.6 (0x00007f7016f7c000) /lib64/ld-linux-x86-64.so.2 (0x00007f7017ca3000)
I assume this has to do with the two undefined symbols in libbuffer.so : # c++filt _ZN6Common4ftoaEfPc _ZN6Common4dtoaEdPcb Common::ftoa(float, char*) Common::dtoa(double, char*, bool)
The closest match I can find in the sources are from libftoa's (also part of openCOLLADA) Commondtoa.h and Commonftoa.h :
You just answered your own cuestion, link libbuffer.so against libftoa...
Necessary because Fedora now uses --no-copy-dt-needed-entries by default. See http://fedoraproject.org/wiki/UnderstandingDSOLinkChange Richard. -- Richard Guenther <rguenther@suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
* Richard Guenther (rguenther@suse.de) [20110426 11:02]:
See http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
Those are IMO sound reasons so why we don't we follow suit? Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
El 26/04/11 14:00, Philipp Thomas escribió:
* Richard Guenther (rguenther@suse.de) [20110426 11:02]:
See http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
Those are IMO sound reasons so why we don't we follow suit?
yeah,IMHO --no-copy-dt-needed-entries offers a sane behaviour and apparently the gold linker defaults on that as well. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, Apr 26, 2011 at 02:10:07PM -0300, Cristian Rodríguez wrote:
El 26/04/11 14:00, Philipp Thomas escribió:
* Richard Guenther (rguenther@suse.de) [20110426 11:02]:
See http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
Those are IMO sound reasons so why we don't we follow suit?
yeah,IMHO --no-copy-dt-needed-entries offers a sane behaviour and apparently the gold linker defaults on that as well.
How does it relate to --as-needed, which we made quite painfully the default already? Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
El 26/04/11 14:14, Marcus Meissner escribió:
On Tue, Apr 26, 2011 at 02:10:07PM -0300, Cristian Rodríguez wrote:
How does it relate to --as-needed, which we made quite painfully the default already?
That's what Im trying to figure out as well =) not clear to me if it is complementary or mutually exclusive to as-needed. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
El 26/04/11 14:20, Cristian Rodríguez escribió:
El 26/04/11 14:14, Marcus Meissner escribió:
On Tue, Apr 26, 2011 at 02:10:07PM -0300, Cristian Rodríguez wrote:
How does it relate to --as-needed, which we made quite painfully the default already?
That's what Im trying to figure out as well =) not clear to me if it is complementary or mutually exclusive to as-needed.
Got it, https://wiki.kubuntu.org/NattyNarwhal/ToolchainTransition it is complementary.. http://sourceware.org/binutils/docs/ld/Options.html -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 26 Apr 2011, Cristian Rodríguez wrote:
El 26/04/11 14:14, Marcus Meissner escribió:
On Tue, Apr 26, 2011 at 02:10:07PM -0300, Cristian Rodríguez wrote:
How does it relate to --as-needed, which we made quite painfully the default already?
That's what Im trying to figure out as well =) not clear to me if it is complementary or mutually exclusive to as-needed.
They are complementary and have similar fallout scenarios. Richard. -- Richard Guenther <rguenther@suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
El 27/04/11 05:48, Richard Guenther escribió:
On Tue, 26 Apr 2011, Cristian Rodríguez wrote:
El 26/04/11 14:14, Marcus Meissner escribió:
On Tue, Apr 26, 2011 at 02:10:07PM -0300, Cristian Rodríguez wrote:
How does it relate to --as-needed, which we made quite painfully the default already?
That's what Im trying to figure out as well =) not clear to me if it is complementary or mutually exclusive to as-needed.
They are complementary and have similar fallout scenarios.
IMHO, we need both. sure, it may cause some workload, but should be worth it. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, 27 Apr 2011 15:37, Cristian Rodríguez <crrodriguez@...> wrote:
El 27/04/11 05:48, Richard Guenther escribió:
On Tue, 26 Apr 2011, Cristian Rodríguez wrote:
El 26/04/11 14:14, Marcus Meissner escribió:
On Tue, Apr 26, 2011 at 02:10:07PM -0300, Cristian Rodríguez wrote:
How does it relate to --as-needed, which we made quite painfully the default already?
That's what Im trying to figure out as well =) not clear to me if it is complementary or mutually exclusive to as-needed.
They are complementary and have similar fallout scenarios.
IMHO, we need both. sure, it may cause some workload, but should be worth it.
About the workload: Wouldn't it be clever to ask the distros, that already use this option about what packages / versions /patches are already done, and what's left to be pushed upstream or patches to copied / recreated ? No need to do the same work again. Just remembering everybody here, packageing between distros hasn't have to be a one-way-road. No need to ignore others, just to do the same PITA work again. Yamaban out.
El 27/04/11 11:19, Yamaban escribió:
About the workload: Wouldn't it be clever to ask the distros, that already use this option about what packages / versions /patches are already done, and what's left to be pushed upstream or patches to copied / recreated ? No need to do the same work again.
Both debian and fedora have public bug lists with affected packages, I have take a look on them, nothing mayor breaks. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2011/4/27 Cristian Rodríguez <crrodriguez@opensuse.org>:
El 27/04/11 05:48, Richard Guenther escribió:
On Tue, 26 Apr 2011, Cristian Rodríguez wrote:
El 26/04/11 14:14, Marcus Meissner escribió:
On Tue, Apr 26, 2011 at 02:10:07PM -0300, Cristian Rodríguez wrote:
How does it relate to --as-needed, which we made quite painfully the default already?
That's what Im trying to figure out as well =) not clear to me if it is complementary or mutually exclusive to as-needed.
They are complementary and have similar fallout scenarios.
IMHO, we need both. sure, it may cause some workload, but should be worth it.
If I understood it correctly it's a funny behavior. In the example from Fedora, gcc -o foo1 foo1.o foo2.so -Wl,--rpath-link=. without --no-copy-dt-needed-entries would create a perfectly valid binary. foo1 will have a DT_NEEDED entry for foo3. But if changed to gcc -shared -o foo1.so foo1.o foo2.so -Wl,--rpath-link=. the resulting foo1.so library will miss the DT_NEEDED entry for foo3. So by default DT_NEEDED entries are copied in binaries but no in libraries. So "--no-copy-dt-needed-entries" seems useful for libraries... but it will only make binaries fail to build when they would otherwise be created perfectly correct. To lower the workload, there is some way to use it only in libraries? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
El 27/04/11 19:02, Cristian Morales Vega escribió:
To lower the workload, there is some way to use it only in libraries?
there should be ready to apply patches in fedora and debian, I dont think it is such a big deal. However, there might be some painful stuff, like broken configure scripts that may silently fail and ignore optional dependencies. In short, failing to compile or link is not a problem. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2011/4/28 Cristian Morales Vega <cmorve69@yahoo.es>:
2011/4/27 Cristian Rodríguez <crrodriguez@opensuse.org>:
El 27/04/11 05:48, Richard Guenther escribió:
On Tue, 26 Apr 2011, Cristian Rodríguez wrote:
El 26/04/11 14:14, Marcus Meissner escribió:
On Tue, Apr 26, 2011 at 02:10:07PM -0300, Cristian Rodríguez wrote:
How does it relate to --as-needed, which we made quite painfully the default already?
That's what Im trying to figure out as well =) not clear to me if it is complementary or mutually exclusive to as-needed.
They are complementary and have similar fallout scenarios.
IMHO, we need both. sure, it may cause some workload, but should be worth it.
If I understood it correctly it's a funny behavior. In the example from Fedora,
gcc -o foo1 foo1.o foo2.so -Wl,--rpath-link=.
without --no-copy-dt-needed-entries would create a perfectly valid binary. foo1 will have a DT_NEEDED entry for foo3.
But if changed to
gcc -shared -o foo1.so foo1.o foo2.so -Wl,--rpath-link=.
the resulting foo1.so library will miss the DT_NEEDED entry for foo3.
So by default DT_NEEDED entries are copied in binaries but no in libraries. So "--no-copy-dt-needed-entries" seems useful for libraries... but it will only make binaries fail to build when they would otherwise be created perfectly correct.
OK I'm sleepy, but I also were when I wrote the other message :-p I'm wrong or --[no-]copy-dt-needed-entries has no effect at all when creating shared libraries? If so, I would be against it. What are we going to win? For shared libraries makes no difference and its only effect is making binaries fail to build! Yes, those binaries could fail to build in the future, but making ALL of them fail to build NOW is not any better. $ readelf -d foo2.so | fgrep NEEDED 0x0000000000000001 (NEEDED) Shared library: [foo3.so] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] $ gcc -o foo1 foo1.o foo2.so -Wl,--rpath-link=. $ readelf -d foo1 | fgrep NEEDED 0x0000000000000001 (NEEDED) Shared library: [foo2.so] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [foo3.so] $ gcc -shared -o foo1.so foo1.o foo2.so -Wl,--rpath-link=. $ readelf -d foo1.so | fgrep NEEDED 0x0000000000000001 (NEEDED) Shared library: [foo2.so] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] $ gcc -shared -Wl,--no-copy-dt-needed-entries -o foo1.so foo1.o foo2.so -Wl,--rpath-link=. $ readelf -d foo1.so | fgrep NEEDED 0x0000000000000001 (NEEDED) Shared library: [foo2.so] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] $ gcc -shared -Wl,--copy-dt-needed-entries -o foo1.so foo1.o foo2.so -Wl,--rpath-link=. $ readelf -d foo1.so | fgrep NEEDED 0x0000000000000001 (NEEDED) Shared library: [foo2.so] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] The binary is correct, links to foo3.so even if it was not specified in the command line. And the shared library always missed the foo3.so DT_NEEDED entry. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
El 29/04/11 19:51, Cristian Morales Vega escribió:
OK I'm sleepy, but I also were when I wrote the other message :-p I'm wrong or --[no-]copy-dt-needed-entries has no effect at all when creating shared libraries?
"This option also has an effect on the resolution of symbols in dynamic libraries. With the default setting dynamic libraries mentioned on the command line will be recursively searched, following their DT_NEEDED tags to other libraries, in order to resolve symbols required by the output binary. With --no-copy-dt-needed-entries specified however the searching of dynamic libraries that follow it will stop with the dynamic library itself. No DT_NEEDED links will be traversed to resolve symbols." If so, I would be against it. What are we
going to win?
Less magic behaviour. Binary compatibility with fedora,debian and ubuntu,removing or adding NEEDED entries count as a ABI change to me at least =) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2011/4/30 Cristian Rodríguez <crrodriguez@opensuse.org>:
El 29/04/11 19:51, Cristian Morales Vega escribió:
OK I'm sleepy, but I also were when I wrote the other message :-p I'm wrong or --[no-]copy-dt-needed-entries has no effect at all when creating shared libraries?
"This option also has an effect on the resolution of symbols in dynamic libraries. With the default setting dynamic libraries mentioned on the command line will be recursively searched, following their DT_NEEDED tags to other libraries, in order to resolve symbols required by the output binary. With --no-copy-dt-needed-entries specified however the searching of dynamic libraries that follow it will stop with the dynamic library itself. No DT_NEEDED links will be traversed to resolve symbols."
When it says "This option also has an effect on the resolution of symbols in dynamic libraries" I understand it means in the "-lxxx" entries when creating a binary. And the symbol resolution it talks about would be at link time, not load time. So would have no effect on the creation of shared libraries.
If so, I would be against it. What are we
going to win?
Less magic behaviour.
Binary compatibility with fedora,debian and ubuntu,removing or adding NEEDED entries count as a ABI change to me at least =)
But when are NEEDED entries going to be removed/added? Without --no-copy-dt-needed-entries binaries will have all the needed entries, with --no-copy-dt-needed-entries binaries will fail to build... until you fix them, and when fixed the NEEDED entries will be the same than before using --no-copy-dt-needed-entries. And shared libraries will always have only the NEEDED entries explicitly added, no more no less.
From the examples given in my previous email: foo1 always will have NEEDED for foo2.so and foo3.so, and foo1.so always will have the NEEDED for foo2.so but will miss the one for foo3.so. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 04/30/2011 02:10 AM, Cristian Rodríguez wrote:
El 29/04/11 19:51, Cristian Morales Vega escribió:
OK I'm sleepy, but I also were when I wrote the other message :-p I'm wrong or --[no-]copy-dt-needed-entries has no effect at all when creating shared libraries?
"This option also has an effect on the resolution of symbols in dynamic libraries. With the default setting dynamic libraries mentioned on the command line will be recursively searched, following their DT_NEEDED tags to other libraries, in order to resolve symbols required by the output binary. With --no-copy-dt-needed-entries specified however the searching of dynamic libraries that follow it will stop with the dynamic library itself. No DT_NEEDED links will be traversed to resolve symbols."
If so, I would be against it. What are we
going to win?
Less magic behaviour.
Binary compatibility with fedora,debian and ubuntu,removing or adding NEEDED entries count as a ABI change to me at least =)
It actually means more work, I really wouldn't know how many bundled library packages will need to have their builds patched after searching for the lib to link to (must check ffmpeg) although it may just be me and openCOLLADA and all the libs with builds created upstream don't have a problem. No wonder Debian use a static openCOLLADA in their blender. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 04/27/2011 10:48 AM, Richard Guenther wrote:
On Tue, 26 Apr 2011, Cristian Rodríguez wrote:
El 26/04/11 14:14, Marcus Meissner escribió:
On Tue, Apr 26, 2011 at 02:10:07PM -0300, Cristian Rodríguez wrote:
How does it relate to --as-needed, which we made quite painfully the default already?
That's what Im trying to figure out as well =) not clear to me if it is complementary or mutually exclusive to as-needed.
They are complementary and have similar fallout scenarios.
Richard.
Just to let you know, the sponsor of the packager that I'm working with has fulfilled my TODO and patched the cmake build of openCOLLADA into life with automatic versioning and soname, scons is as good as the python programming it. Cmake doesn't allow "undefined-non-weak-symbol"s. It's an interesting concept that Fedora have where you file a bug for a sponsor to review your package openly and mentoring the packager gives a good foundation for package maintenance. One interesting thing is Fedora wants the package to be called openCOLLADA with no so number Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 26 Apr 2011, Philipp Thomas wrote:
* Richard Guenther (rguenther@suse.de) [20110426 11:02]:
See http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
Those are IMO sound reasons so why we don't we follow suit?
ISTR raising it shortly in some internal conversation, but supposedly it simply fell through the cracks. Note that Fedora doesn't use --as-needed by default. Richard. -- Richard Guenther <rguenther@suse.de> 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
2011/4/22 Dave Plater <davejplater@gmail.com>:
rpmlint picked up "undefined-non-weak-symbol"s in one of the libraries. This seems like something that I should fix and possibly something that our rpmlint needs to check for.
Indeed. In my home project I use a patched binutils to force "--no-undefined" (which could be argued upstream should use if they don't need to have undefined symbols), and even if most of the found problems have been just theoretical I have also found a bunch of real problems (and my home project has not so much packages...). But the check has been in the upstream rpmlint for years (http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1170/trunk/BinariesCheck....). I don't know how rpmlint works, but I suppose it's just "disabled"? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
El 23/04/11 14:44, Cristian Morales Vega escribió:
But the check has been in the upstream rpmlint for years (http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1170/trunk/BinariesCheck....). I don't know how rpmlint works, but I suppose it's just "disabled"?
I think we should enable this in factory. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 04/23/2011 07:46 PM, Cristian Rodríguez wrote:
El 23/04/11 14:44, Cristian Morales Vega escribió:
But the check has been in the upstream rpmlint for years (http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1170/trunk/BinariesCheck....). I don't know how rpmlint works, but I suppose it's just "disabled"?
I think we should enable this in factory.
+1 I wonder how many packages have this problem. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2011/4/24 Dave Plater <davejplater@gmail.com>:
On 04/23/2011 07:46 PM, Cristian Rodríguez wrote:
El 23/04/11 14:44, Cristian Morales Vega escribió:
But the check has been in the upstream rpmlint for years
(http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1170/trunk/BinariesCheck....). I don't know how rpmlint works, but I suppose it's just "disabled"?
I think we should enable this in factory.
+1 I wonder how many packages have this problem.
ldd -u /usr/lib/* will help you make an idea. But I'm still trying to understand how rpmlint is used in openSUSE. A "rpmlint libgle3" in my 11.4 system returns a few "undefined-non-weak-symbol" warnings, but the build log from https://build.opensuse.org/package/live_build_log?arch=x86_64&package=gle&project=openSUSE%3A11.4&repository=standard doesn't says a thing about the problem. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2011/4/24 Cristian Morales Vega <cmorve69@yahoo.es>:
2011/4/24 Dave Plater <davejplater@gmail.com>:
On 04/23/2011 07:46 PM, Cristian Rodríguez wrote:
El 23/04/11 14:44, Cristian Morales Vega escribió:
But the check has been in the upstream rpmlint for years
(http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1170/trunk/BinariesCheck....). I don't know how rpmlint works, but I suppose it's just "disabled"?
I think we should enable this in factory.
+1 I wonder how many packages have this problem.
ldd -u /usr/lib/* will help you make an idea.
But I'm still trying to understand how rpmlint is used in openSUSE. A "rpmlint libgle3" in my 11.4 system returns a few "undefined-non-weak-symbol" warnings, but the build log from https://build.opensuse.org/package/live_build_log?arch=x86_64&package=gle&project=openSUSE%3A11.4&repository=standard doesn't says a thing about the problem.
OK, rpmlint only shows the problem if the package is installed. We would need to modify the way rpmlint is used in the OBS to detect this problem. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 04/24/2011 03:30 PM, Cristian Morales Vega wrote:
2011/4/24 Cristian Morales Vega<cmorve69@yahoo.es>:
2011/4/24 Dave Plater<davejplater@gmail.com>:
On 04/23/2011 07:46 PM, Cristian Rodríguez wrote:
El 23/04/11 14:44, Cristian Morales Vega escribió:
But the check has been in the upstream rpmlint for years
(http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1170/trunk/BinariesCheck....). I don't know how rpmlint works, but I suppose it's just "disabled"?
I think we should enable this in factory.
+1 I wonder how many packages have this problem.
ldd -u /usr/lib/* will help you make an idea.
But I'm still trying to understand how rpmlint is used in openSUSE. A "rpmlint libgle3" in my 11.4 system returns a few "undefined-non-weak-symbol" warnings, but the build log from https://build.opensuse.org/package/live_build_log?arch=x86_64&package=gle&project=openSUSE%3A11.4&repository=standard doesn't says a thing about the problem.
OK, rpmlint only shows the problem if the package is installed. We would need to modify the way rpmlint is used in the OBS to detect this problem. Yeh, it has to be done in a populated %{buildroot} prior to packing. That worked with openCOLLADA, needs to be inserted just before %{buildroot} is deleted.
Dave -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (13)
-
Bernhard Walle -
Cristian Morales Vega -
Cristian Rodríguez -
Dave Plater -
Dave Plater -
Jan Engelhardt -
Juergen Weigert -
Malcolm -
Marcus Meissner -
Pavol Rusnak -
Philipp Thomas -
Richard Guenther -
Yamaban