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 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

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

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 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 Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

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

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

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 Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

On Wed, 27 Apr 2011 15:37, Cristian Rodríguez 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.

2011/4/27 Cristian Rodríguez :

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

2011/4/28 Cristian Morales Vega :

2011/4/27 Cristian Rodríguez :

...

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

2011/4/30 Cristian Rodríguez :

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/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 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 Cristian Morales Vega :

2011/4/24 Dave Plater :

...

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