Ralf Corsepius wrote:
> On Wed, 2007-06-06 at 09:36 +0100, Andy Green wrote:
>> Andy Green wrote:
>>
>>>> But .. could it be that you are not having redhat-rpm-config installed?
>>>> At least on FC6 it screws up --target, produces invalid *debuginfo*.rpm
>>>> for foreign object formats and many other details.
>>> No it's installed, but --target works... well it works as far as setting
>>> %{_target_cpu} goes which is pretty much all I ask of it. Note you seem
>>> to need to give an arch-dist-os triplet like this
>> Just to be a bit clearer, I have a single ~/.rpmmacros with everything
>> that cares about the arch using %{_target_cpu} ...
>>
>> %packager Andy Green <andy@xxxxxxxxxxx>
>> %vendor Octotux (http://octotux.org)
>> %_signature gpg
>> %_gpg_name Octotux Packaging
>> %_gpg_path ~/.gnupg
>> %_topdir /projects/octotux/packages/rpm
>> %crosspath /opt/%{_target_cpu}/bin
>> %develfilesystem %{_topdir}/devel-filesystem-%{_target_cpu}
>> %__strip %crosspath/%{_target_cpu}-linux-strip
>> %__objdump %crosspath/%{_target_cpu}-linux-objdump
>> %__patch /usr/bin/patch -f
> OK, this explains one half: You are switching off many of the implicitly
> presets.
Well overriding them according to the arch, yes.
>> %_use_internal_dependency_generator 0
> And this is the other half: You are disabling a lot of the hard-coded magic.
No, this is only turned off because the library rpm used to parse ELF
internally segfaulted when dealing with avr32 ELF... it worked fine
without this, using the internal one, for arm for example.
>> I guess the debuginfo problem you saw was because you did not override
>> %__strip,
> Not quite. It's because a toolchain package contains both host and
> target binaries and the redhat-* scripts don't distinguish between host
> and target binaries, but blindly run "one strip" on all binaries they
> find. This doesn't building rpms to abort, as long as target and host
> binary formats are sufficiently compatible. Instead it causes
> *debuginfo*.rpms to contain both host and target sources.
But strip runs only on built executables/libraries that are going into
the binary packages. There are packages that produce host-compiled
binaries during the build, but they aren't often (I never saw it)
packaged. I can remember seeing little host-compiled utilities built in
some packages as part of the build process, but they are run as part of
the build and not packaged, so they should not be stripped.
> If host and target object format differ, rpmbuild bombs out.
I have never experienced that, so I guess it must be okay for all the
packages I addressed, at least. And that includes some big stuff like
db4, postfix, asterisk, gdb, linux itself...
> AFAIS, you are building pure target binary packages.
Right.
>> defnitely debuginfo rpms are generated and work fine on arm
>> with gdb.
> Not unlikely, but you should check your buildlogs for error/warning
> messages and your resulting rpms for correctness.
My scripts will stop dead if rpmbuild chokes so I am pretty sure none of
my packages so far fell into this unusual category of building and
packaging apps compiled for both host and target.
Anyway the end result is that with a macro setup like this it is quite
possible to tell rpmbuild --target=<arch> and if you had the right cross
compilers installed you can end up with blah.<arch>.rpm binaries for any
arch from a single specfile and source. That is cool!
If Fedora wanted to address it I have no doubt that they can fix/meddle
with the "official" macros and get it to work cleaner, but the whole
deal can and does work soup to nuts with just ~/.rpmmacros set up.
-Andy
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
