Re: State of multilib development

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 16 October 2006 09:30, Hans de Goede wrote:
> Dennis Gilmore wrote:
> > On Monday 16 October 2006 03:04, Hans de Goede wrote:
> >> Hi all,
> >>
> >> Yesterday I tried to build i386 rpms on my x86_64 using the new
> >> multilib-devel packages instead of resorting to an i386 chroot.
> >>
> >> Although we have come a long way to making this possible there are still
> >> a few issues which makes doing this very hard:
> >>
> >> 1) gcc ignores setarch
> >> ======================
> >>
> >> "gcc -o hello helloworld.c", creates an x86_64 elf file on my x86_64
> >> system as expected however, "setarch i386 gcc -o hello helloworld.c"
> >> also creates an x86_64 elf file instead of an i386 one, to get an i386
> >> one I must do: "gcc -m32 -o hello helloworld.c".

>
> Thanks for responding, but I don't see how /etc/rpm/platform has
> anything todo with problem nr 1) I've described as that only involves
> gcc not rpmbuild.
it has nothing to do with gcc invoked in that way.  AFAIK  you should always 
really set -m64 or -m32  when using gcc but it doesn have  to do with what 
you were seeing when running rpmbuild  in the two different mannaers  the 
correct invocation is setarch i686 rpmbuild   but it wont work propperly with 
an /etc/rpm/platform file in place

> >> 2) rpmbuild ignores setarch
> >> ===========================
> >>
> >> "setarch i386 rpmbuild -bb foo.spec" Still tries to build an x86_64 foo,
> >> I know "rpmbuild --target i386" works better but still has issues, for
> >> example libdir is still set to /usr/lib64, this is already in bugzilla.
> >>
> >> I however still believe that rpmbuild should change its default build
> >> target when using setarch and should call setarch itself when called
> >> with --target, shall I BZ this?
> >
> > Again due to /etc/rpm/platform
>
> Okay, this may be true, I indeed have an /etc/rpm/platform, and it is
> not owned by any package, still I didn't put it there I'll try removing it.

anaconda put it there

> >> 4) rpmbuild lets x86_64 packages satisfy BR's when building for i386
> >> ====================================================================
> >>
> >> The subject says most of it, when doing an rpmbuild --target=i386 I
> >> don't want libXt-devel.x86_64 to satisfy a BR: libXt-devel .
> >>
> >> I know things aren't that easy because with something like BR:
> >> desktop-file-utils, the x86_64 version will do fine.
> >>
> >> Suggestion: make rpmbuild check the arch of BR's who's name ends with
> >> -devel.
> >>
> >> This will still have a few exceptions, but will be a big improvement in
> >> general. BZ?
> >
> > again due to /etc/rpm/platform   it overrides some of rpms logic  and it
> > thinks its building x86_64  always
>
> Erm, please read properly before commenting, having any arch of
> libXt-devel installed will currently make rpmbuild happy with regards to
> a BR: libXt-devel, no matter what platform is being build.
are you really sure ?  with the /etc/rpm/platform file there rpm thinks your 
system is x86_64  even though you used setarch.


> >> 5) xxx-devel.arch should require xxx.arch not just xxx
> >> ======================================================
> >>
> >> When I install libXt-devel.i386 I expect it to drag in libXt.i386 and
> >> not to be happy with the already installed libXt.x86_64 .
> >
> > possibly due to the same issue.
>
> Nope, it does the same too drag in i386 packages to resolve x86_64
> -devel packages deps. To fix this we need a way to add the arch to deps,
>   because currently deps don't have archs.
>
> Regards,
>
> Hans

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux