Why a multilib wrapper for non-multilib architectures?!
Hello everbody,
can somebody please explain me, why we've multilib wrappers for packages
at non-multilib architectures such as arm, alpha, ia64 and sh?
- http://cvs.fedoraproject.org/viewvc/devel/gmp/gmp-mparam.h?view=co
-
http://cvs.fedoraproject.org/viewvc/devel/e2fsprogs/ext2_types-wrapper.h?view=co
- http://cvs.fedoraproject.org/viewvc/devel/apr/apr-wrapper.h?view=co
- http://cvs.fedoraproject.org/viewvc/devel/openssl/opensslconf-new.h?view=co
Where's the reason to have a whatever-archname.h if there's no multilib
available on that architecture? From my point of view, multilib wrappers
only make sense on the architectures %{ix86}/x86_64, ppc/ppc64, s390/s390x,
%{sparc}/%{sparcx} and %{mips}/%{mipsel}/%{mipsx}. Tell me, if I'm wrong,
but %{arm}, alpha, ia64 and sh are single-lib, ie. they've only 32 or 64
bit and no multi-arch.
I've already raised up the question to the package maintainers, and Joe
has suggested me to ask on fedora-devel for the correct list or reasons
for the current behaviour.
Greetings,
Robert
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why a multilib wrapper for non-multilib architectures?!
On Sat, 13 Jun 2009, Chris Adams wrote:
> Just for starters, long before x86_64 came into the picture, we had
> i386, i486, i586, and i686. On Alpha, you have (IIRC) ev4, ev5, ev6,
> ev67, etc.
You have seen, that these wrappers treat alpha as alpha and %{ix86} as i386
and that's it?! So your explanation doesn't make any sense to me, sorry.
Greetings,
Robert
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why a multilib wrapper for non-multilib architectures?!
On Sat, 13 Jun 2009, Kevin Kofler wrote: > Probably because it's less maintenance work in the specfile to just always > add the wrapper. (On the other hand, it means extra work (adding an #ifdef) > when adding a secondary arch.) Well, how would it help to have a wrapper for ia64 if no non-ia64 packages are getting installed on ia64? Replace ia64 by alpha and rerun my question. Why a wrapper file, if there's nothing, that could conflict? Greetings, Robert -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why a multilib wrapper for non-multilib architectures?!
On Sat, 13 Jun 2009, Orcan Ogetbil wrote: > Because as a Fedora packager, neither am I responsible nor do I care > about ia64 packages. Replace ia64 by alpha (or any other secondary > arch) and rerun my answer. Sorry, but wrong answer for a Fedora packager. If you lack knowledge, you should try to get the missing knowledge. And some of the architectures I mentioned in my initial e-mail are secondary architectures of Fedora, thus they shouldn't get ignored or wrong handled. Greetings, Robert -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Help needed for undefined symbol _ZN10ECMemTable6CreateEP14_SPropTagArrayjPPS_
Good evening, I'm still on the way to get the Zarafa Groupware into Fedora (see Fedora Package review request https://bugzilla.redhat.com/show_bug.cgi?id=498194) and beside of the ongoing legal issue, I've also found a technical issue where I need some help. At the moment, it's a bit difficult: I'm using a non-public pre-release of Zarafa which will public available and AGPL licensed once it's final. That means for now, investigating is a bit hard but I'm looking for some tips or hints to get the issue solved. The error message itself is as follows: May 31 17:11:57 tux /usr/bin/zarafa-spooler: symbol lookup error: /usr/lib/libmapi.so.0: undefined symbol: _ZN10ECMemTable6CreateEP14_SPropTagArrayjPPS_ Well, there's a symbol missing somewhere, so I executed following: $ nm -D /usr/lib/libmapi.so.0 | grep _ZN10ECMemTable6CreateEP14_SPropTagArrayjPPS_ U _ZN10ECMemTable6CreateEP14_SPropTagArrayjPPS_ $ Okay, looks like the symbol is really missing. So let's have a look to the files in the build dir and how it behaves there: $ nm ./common/.libs/libcommon_mapi.a | grep _ZN10ECMemTable6CreateEP14_SPropTagArrayjPPS_ 3da0 T _ZN10ECMemTable6CreateEP14_SPropTagArrayjPPS_ $ versus $ nm -D ./mapi4linux/src/.libs/libmapi.so | grep _ZN10ECMemTable6CreateEP14_SPropTagArrayjPPS_ U _ZN10ECMemTable6CreateEP14_SPropTagArrayjPPS_ $ versus $ nm -D ./inetmapi/.libs/libinetmapi.so.1 | grep _ZN10ECMemTable6CreateEP14_SPropTagArrayjPPS_ 0005f270 T _ZN10ECMemTable6CreateEP14_SPropTagArrayjPPS_ $ So far. Interestingly, that issue only exists on Fedora 11 and above, not on Fedora 10 or below. As it seems, the issue is not GCC 4.4 relevant, so it is maybe a libtool linking issue? Ideas? Hints? Suggestions? What else could I check? Upstream doesn't have a pointer for me, but given that Fedora and bleeding edge are not their default target (they focus to the long-term supported distributions where Zarafa mostly gets used), it's understandable to me... Note, that OpenChange libmapi.so is not involved anywhere here, it's only Zarafa libmapi.so everywhere above. Greetings, Robert -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora rawhide rebuild in mock status 2009-11-18 x86_64
Hello Matt, On Wed, 18 Nov 2009, Matt Domsch wrote: > mksh-39-1.fc12 (build/make) robert I tried to reproduce your build failure from your mass rebuild for mksh - http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/x86_64/mksh-39-1.fc12.src.rpm/result/build.log - http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/i386/mksh-39-1.fc12.src.rpm/result/build.log using a koji scratch build at the Fedora buildsystem - and there it did not fail: http://koji.fedoraproject.org/koji/taskinfo?taskID=1820331 I think, you've enabled SELinux at your buildsystem which causes the /dev/* files to be missing in the end, but compare yourself: - http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/i386/mksh-39-1.fc12.src.rpm/result/root.log - http://koji.fedoraproject.org/koji/getfile?taskID=1820333&name=root.log Please either solve your buildsystem issue for the next mass rebuild or exclude my mksh package...thank you :) Greetings, Robert -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
