[meego-commits] 5034: Changes to Trunk:Testing/zlib

[Zhang, Austin]

> but test64 will fail, which seems related with the profile guided optimization.
So any error.log/config.log/building.log? 
You can chroot into and manually execute those 3 steps to see if it works for 1.2.5 with PGO.


-----Original Message-----
From: meego-commits-bounces at meego.com [mailto:meego-commits-bounces at meego.com] On Behalf Of Yin, Yan
Sent: Wednesday, June 30, 2010 5:10 PM
To: meego-commits at meego.com; Arjan van de Ven
Subject: Re: [meego-commits] 5034: Changes to Trunk:Testing/zlib

Thanks Austin! The optimization seems should be kept when upgrade to 1.2.5 then.

However, this *non-standard build process* makes the upgrade to 1.2.5 rather difficult, as top-level Makefile has changed a lot between 1.2.3 and 1.2.5, I tried very hard to fix the dependency issue in Arjian's spec file, but with no luck to success. :-(

After fixed several dependency issues, I'm blocked at this line "make test -f Makefile.old LDFLAGS="libz.a -lgcov"", in 1.2.5, it will check teststatic, testshared, test64 respectively, the teststatic and testshared will succeed, but test64 will fail, which seems related with the profile guided optimization. 

Arjan/Austin, any suggestions on this?


> -----Original Message-----
> From: meego-commits-bounces at meego.com
> [mailto:meego-commits-bounces at meego.com] On Behalf Of Zhang, Austin
> Sent: Wednesday, June 30, 2010 3:09 PM
> To: meego-commits at meego.com; Arjan van de Ven
> Subject: Re: [meego-commits] 5034: Changes to Trunk:Testing/zlib
> 
> > what kind of benefits can we get from this optimization?
> 
> Quote from arjan's commit in Feb:
> "What's this optimization for?  Is such optimization common and can be used
> in other packages?
> 
> using PGO means that the compiler gets information about how the code runs
> in practice; you compile an instrumented version, then you run a representative
> workload, and then you compile again, now using the result of the workload.
> This gives the compiler information on what to inline, how to do branches etc
> etc....
> and for zlib gave me 5%.
> 
> how much it works for other packages I don't know yet... that's what I'm
> looking at next once I find 2 or 3 I was going to write up some documentation
> and see if there's a wider pattern."
> 
> -----Original Message-----
> From: meego-commits-bounces at meego.com
> [mailto:meego-commits-bounces at meego.com] On Behalf Of Yin, Yan
> Sent: Wednesday, June 30, 2010 2:42 PM
> To: Arjan van de Ven; meego-commits at meego.com
> Subject: Re: [meego-commits] 5034: Changes to Trunk:Testing/zlib
> 
> Hi Arjan,
> 
> Thanks for your comments, especially for you're the one who made changes to
> this package recently. :-)
> 
> The original spec is a bit difficult to read, especially for the optimization and the
> post_install section, this is why I trying to change it to YAML.
> 
> To keep the profile guided optimization initially imported by you for latest 1.2.5,
> I have made some changes, including "configure options", "make teststatic"
> ("make test" will fail at "make test64", is this ), and also the post_install
> section. It's not easy to get it work actually, I checked the fedora spec file and
> found no such sections there, what kind of benefits can we get from this
> optimization? Can it be dropped?
> 
> I also tried to use the old style spec file and just upgrade it to 1.2.5, but it will
> fail, I'm still investigating the reasons, I will post you once any update...
> 
> > -----Original Message-----
> > From: Arjan van de Ven [mailto:arjan at linux.intel.com]
> > Sent: Wednesday, June 30, 2010 1:46 PM
> > To: meego-commits at meego.com
> > Cc: Yin, Yan
> > Subject: Re: [meego-commits] 5034: Changes to Trunk:Testing/zlib
> >
> > On 6/29/2010 10:36 PM, Yan Yin wrote:
> > >    submit:   home:yyin2:branches:Trunk:Testing/zl
> >
> >
> > is using yaml for this really an improvement?
> > I'd not call this spec an easy simple one to be honest....
> > and things like
> >
> > +rm -rf %{buildroot}
> > +#>>  install pre
> >   rm -rf ${RPM_BUILD_ROOT}
> > +%make_install
> > +#<<  install pre
> >
> > -make install DESTDIR=$RPM_BUILD_ROOT  libdir=/%{_lib}
> > +#>>  install post\\
> >
> > don't make me feel good; things like losing the libdir= causing an actual 5 line
> > mess instead
> >
> > I would in fact call this a step backwards.
> >
> > spectacle is great for many packages.
> > but not for all. it's not meant to be, and that's ok.
> >
> > I suspect this is one of those "eh no" packages.
> >
> >
> 
> _______________________________________________
> Meego-commits mailing list
> Meego-commits at meego.com
> http://lists.meego.com/listinfo/meego-commits
> _______________________________________________
> Meego-commits mailing list
> Meego-commits at meego.com
> http://lists.meego.com/listinfo/meego-commits
_______________________________________________
Meego-commits mailing list
Meego-commits at meego.com
http://lists.meego.com/listinfo/meego-commits