On 5 February 2018 at 22:14, kallisti5 <kallis...@unixzen.com> wrote: > On 2018-02-05 15:39, Dylan Baker wrote: >> >> Quoting kallisti5 (2018-02-05 12:58:30) >>> >>> On 2017-10-24 11:47, Emil Velikov wrote: >>> > Hi Jerome, >>> > >>> > On 23 October 2017 at 16:58, Jerome Duval <jerome.du...@gmail.com> >>> > wrote: >>> >> * configure.ac: >>> >> -pthread is not available on Haiku. >>> >> Haiku doesn't require --enable-dri >>> >> build hgl on Haiku >>> >> * egl/Makefile.am: define backendfiles for Haiku >>> >> * src/gallium/Makefile.am: build winsys/sw/hgl, state_trackers/hgl and >>> >> targets/haiku-softpipe on Haiku. >>> >> * src/gallium/targets/haiku-softpipe: add Makefile.am >>> >> * src/gallium/state_trackers/hgl: add Makefile.am >>> >> * winsys/sw/hgl: add Makefile.am >>> >> * src/hgl/Makefile.am: add Makefile.am >>> >> --- >>> > Thanks for the patch. I think Eric has a point regarding splitting this >>> > up. >>> > Here is one way to handle it: >>> > - patch 1 - the driver, aka st/hgl + sw/hgl + targets/haiku >>> > - 2 - src/egl >>> > - 3 - src/hgl >>> > - 4 misc fixes (the SoftwareRenderer.cpp hunk?) >>> > - 5 toggle - configure.ac + src/Makefile.am >>> >>> Hm, it looks like Jerome never got back to work on these changes... let >>> me try to >>> pick up the ball and run with it. >>> >>> > Couple of small suggestions: >>> > - keep all the sources and headers in the sources lists in >>> > Makefile.sources >>> > - how do you guys manage pthreads - please mention that in the commit >>> > message. >>> > >>> > If I'm reading this correctly, you strip out -pthread and there's no >>> > pthread-stubs on Haiku. >>> >>> Haiku (and BeOS for that matter) has pthread support built into its core >>> libroot.so. >>> >>> No need for -lpthread, all applications can assume its presence. Things >>> that link -lpthread actually fail due to a non-existant libpthread... >>> *however* as i'm typing this i'm being told we recently implemented a >>> dummy static libpthread.a to try and appease assumptions about -lpthread >>> existence.... so i'll remove the pthread checks :-) >>>
Seems like an extra L was added where it's not needed. Namely I mentioned pthread (notice the lack of L) For a while gcc/clang has worked on unifying all the pthread platform specifics behind the -pthread toggle. Some specifics include: presence/lack of a separate library, -D_REENTRANT, >>> -- Alex >> >> >> Hi Alex, >> >> I have a branch for building haiku with meson, when I was trying to >> compile >> neither the scons build nor the autotools build seemed to compile on a >> Haiku VM >> instance (x86_64), that was a few months ago though, so maybe its fixed. >> >> Our plan is to remove autotools from mesa, probably this year. I'm >> thinking if >> things look pretty good through the 18.0 release cycle I'll probably >> propose >> marking autotools as deprecated for 18.1 and propose removal in 18.2. > > > Ah. crap. I just got autoconfig working :-). Historically I have only used > SCons for our builds. I always preferred the SCons build since autotools > always > ends up looking like spaghetti. Here is what our current build does: > > https://github.com/haikuports/haikuports/blob/master/sys-libs/mesa/mesa-17.1.4.recipe#L52 > > It looks like Jerome hacked in a patch for autotools... but i've heard some > reports > of instability with the resulting artifacts. > AFAICT Jerome's work was fine, modulo the "let's do everything at once" which tends to bite us all. Can you please send that over, even if there's a meson support in the works. Two is better than none ;-) Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
