[Mesa-dev] [PATCH 1/2] build libgallium shared by default.

[Johannes Obermayr]

Am Dienstag, 19. März 2013, 21:36:47 schrieb Andreas Boll:
> 2013/3/19 Johannes Obermayr <johannesobermayr at gmx.de>:
> > Am Montag, 18. März 2013, 15:38:31 schrieb Maarten Lankhorst:
> >> This is one of the 2 patches used in ubuntu for decreasing size of mesa build.
> >>
> >> The other one is more hacky, and links libmesagallium into libgallium,
> >> and then links libgallium against libdricore too for minimal duplication.
> >>
> >
> > I am against both patches:
> >
> > 1. libgallium shared in this version causes duplicate symbols for depending targets if using static LLVM libs and generally links to much LLVM components/libs
> >
> > 2. libmesagallium shared in a right implementation unconditionally depends on shared libglapi and shared libgallium to avoid duplicate symbol for depending targets
> >
> > 3. It is not "-no-undefined" but "-Wl,--no-undefined" to show missing symbols (and currently there are a lot of them in Mesa) ...
> 
> This is because libtool is broken.
> 
> >
> > 4. I have worked to target issues of 1. to 3. in a bottom-up series since December while splitting mesa into libmesacore, libmesadri and libmesagallium to reduce binary sizes as much as possible for distributions
> 
> Hi Johannes,
> 
> any chance you could continue the work on shared libs?
> We all have the same goals, reduce binary sizes, fix undefined
> symbols, reduce the number of build configurations, support for make
> dist and make distcheck
> - long story short improve mesa's build system.
> This time we have more time until the next mesa release to work out all issues.

I have not stopped this work mainly for my own ego and researches (currently it works for my test cases and should be almost finished for all cases).

But I am not really sure whether I will publish the patches because my general experience has been sad when my work shall become pushed to mainline repositories: core devs complained, sb. reinvented the wheel some months later and/or recognized my first approach wasn't so wrong ...
Also asking and begging core devs a few times to get patches pushed is not the thing I want to do anymore.

I know: If it works for my common test cases it isn't guaranteed that it will work for all cases.
But you can find most issues only if patches landed in git master and become tested by more people / configure switches.
Automake work is a good example: People don't test branches although they were asked to do so and complained firstly if configure switches in master were broken after the big push. But you should have seen during that time my interests were and are to quickly fix build failures caused by automake work ...

If you ensure core developers agree with unconditionally shared libs, the "Drop last parts of compatibility for the old Mesa build system." patch and generally the patch series will become pushed within a week after publishing for testing it will be likelier that I publish the patch series.

Johannes

> 
> Andreas.
> 
> >
> > If 4. will be finished right this patch should become obsolete:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=cf69a591e1ad16b590c9ae2eba0da6fa6c4fc741
> >
> > And also most of the C++ linker forces will become obsolete.
> >
> > But pushing things like
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=2506b035031d6022fec0465bffac8eedd43de0f9
> > without saying in which cases it is required (e. g. not for me) doesn't make it easier to fulfill less memory consumption ...
> >
> >
> > Johannes
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev