Hi,
> It's not an architecture issue because it builds OK on my x86 box
> but fails in mock on the very same x86 box. I thought at first it
> was a missing buildreq but I can't think of anything appropriate to
> add. So it's probably something to do with the mock environment
> itself. Unfortunately the assertion failure is pretty unhelpful in
> terms of diagnostics.
It certainly would point to a mock problem. Which architecture are you try to
get mock to build it as?
> > and change the make install to
> >
> > make DESTDIR=%{buildroot} install
>
> Huh? That's what it already is (except with the macro version of
> "make" used)
Just removing the possibility of a macro problem
> > and you'll probably find that will work just fine. One thing that is puzzling
> > me is why you have the same export in two places. Surely when you run the
> > configure step that will remember what you've exported as it will be written
> > to a file somewhere in the BUILD/<package_name> directory.
>
> Not sure about this; this is an idiom I spotted in a few mono specs
> I looked at whilst trying to figure out what was breaking. If the
> configure script *doesn't* record the setting in the Makefile, then
> the multiple exports would certainly be needed as the %build and
> %install scripts are separate shell scripts.
Fair enough
> > Mono is a strange beast which (from what I can see) has little respect for
> > where things should be placed! ;-)
>
> Yeah, I noticed.
I normally work it like this to eliminate problems. Build with /usr/lib set
statically, do a basic build (%configure and make DESTDIR install without any
other parameters). If that builds, move it to my x86_64 box and build. If
that's happy then I try with mock.
With each build, it's tested to ensure things aren't broken[1].
Once the builds are happy like that, then I move it to mock.
Now, if the build fails (as has happened with monodevelop on quite a few
occassions), then I start looking at where it fails and check the makefile. If
it still fails then I hand code the %install step (which can be bloomin' long!)
If only mono packages were sane!
TTFN
Paul
[1] The problem here is that I tend to have a large number of packages on my
test system, so I don't always pick up on missing deps (see my submission for
gtksourceview-sharp)
--
Get your free @ukpost.com account now
http://www.ukpost.com/
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
