On 05/14/2010 10:58 AM, Brian Paul wrote:
> Kevin H. Hobbs wrote:
>>
>> 1. a build of Mesa where only libOSMesa.so is produced?
>>
>> 2. a build of Mesa where libGL.so and libOSMesa.so are produced but the
>> dynamic linker will need no symbols from libGL.so in order to load
>> libOSMesa.so?
>>
>>
Brian Paul writes:
> Kevin H. Hobbs wrote:
> > On 05/14/2010 08:51 AM, Dan Nicholson wrote:
> >> On Thu, May 13, 2010 at 7:40 AM, Kevin H. Hobbs wrote:
> >>> I tried it and it tests as well with VTK as any recent build.
> >> Thanks. Well, you and Tom use a standalone osmesa. The only distro I
> >
Kevin H. Hobbs wrote:
On 05/14/2010 08:51 AM, Dan Nicholson wrote:
On Thu, May 13, 2010 at 7:40 AM, Kevin H. Hobbs wrote:
I tried it and it tests as well with VTK as any recent build.
Thanks. Well, you and Tom use a standalone osmesa. The only distro I
looked at (fedora) uses a standalone osm
On 05/14/2010 08:51 AM, Dan Nicholson wrote:
> On Thu, May 13, 2010 at 7:40 AM, Kevin H. Hobbs wrote:
>>
>> I tried it and it tests as well with VTK as any recent build.
>
> Thanks. Well, you and Tom use a standalone osmesa. The only distro I
> looked at (fedora) uses a standalone osmesa. Maybe t
On Thu, May 13, 2010 at 7:40 AM, Kevin H. Hobbs wrote:
> On 05/12/2010 02:21 PM, Dan Nicholson wrote:
>>
>>
>> Yeah, but you also have to stop it from being linked to libGL. Here's
>> what I'd try on master, although I have tested it. You'll have to rerun
>> autogen.sh.
>>
>> Dan
>>
>
> I tried it
On 05/12/2010 02:21 PM, Dan Nicholson wrote:
>
>
> Yeah, but you also have to stop it from being linked to libGL. Here's
> what I'd try on master, although I have tested it. You'll have to rerun
> autogen.sh.
>
> Dan
>
I tried it and it tests as well with VTK as any recent build.
signature.
On Wed, May 12, 2010 at 12:16:55PM -0400, Kevin H. Hobbs wrote:
> On 05/12/2010 11:45 AM, tom fogal wrote:
> > That said, I think Dan's idea of linking directly to libmesa is an
> > easier way to solve your problem.
> >
>
> Would that be done in :
>
> src/mesa/drivers/osmesa/Makefile
>
> by c
On 05/12/2010 11:45 AM, tom fogal wrote:
> That said, I think Dan's idea of linking directly to libmesa is an
> easier way to solve your problem.
>
Would that be done in :
src/mesa/drivers/osmesa/Makefile
by changing line 31 from
CORE_MESA =
to
CORE_MESA = $(TOP)/src/mesa/libmesa.a
?
On 05/12/2010 11:45 AM, tom fogal wrote:
> "Kevin H. Hobbs" writes:
>> Today, I plan to try to :
> [snip]
>> 2. Try surrounding the declarations of the hidden symbols needed by
>> OSMesa with "#pragma GCC visibility push(default)" and "#pragma GCC
>> visibility pop" or marking them with "__attribu
"Kevin H. Hobbs" writes:
> Today, I plan to try to :
[snip]
> 2. Try surrounding the declarations of the hidden symbols needed by
> OSMesa with "#pragma GCC visibility push(default)" and "#pragma GCC
> visibility pop" or marking them with "__attribute__
> ((visibility("default")))" whichever I'm t
On 05/10/2010 04:48 PM, Dan Nicholson wrote:
>
> I guess this is because configure adds -fvisibility=hidden to the
> CFLAGS. Maybe we should always build osmesa against the internal
> static libraries instead of against libGL.
>
Today, I plan to try to :
1. Try a VTK test build against static M
On 05/10/2010 04:48 PM, Dan Nicholson wrote:
> On Mon, May 10, 2010 at 12:51 PM, Kevin H. Hobbs wrote:
>> The mesa/configs/linux-x86-64 target makes this symbol global while the
>> auto tools configuration makes this symbol local...
>
> I guess this is because configure adds -fvisibility=hidden t
On Mon, May 10, 2010 at 11:09 PM, Kevin H. Hobbs wrote:
> On 05/10/2010 09:46 AM, Brian Paul wrote:
>>
>> A 'make clean' may be needed. Sometimes when source files move around
>> the 'depend' files don't get properly updated.
>>
>> -Brian
>
>
> I get the same result after 'make clean' err.. at le
On Mon, May 10, 2010 at 12:51 PM, Kevin H. Hobbs wrote:
> On 05/10/2010 03:25 PM, Kevin H. Hobbs wrote:
>>
>>
>> I really do not understand this missing symbol business since :
>>
>>
>> $ nm mesa/lib/libGL.so | grep _mesa_free_context_data
>> 00078030 t _mesa_free_context_data
>>
>> $ nm /
On 05/10/2010 03:25 PM, Kevin H. Hobbs wrote:
>
>
> I really do not understand this missing symbol business since :
>
>
> $ nm mesa/lib/libGL.so | grep _mesa_free_context_data
> 00078030 t _mesa_free_context_data
>
> $ nm /opt/Mesa-7.8.1/lib64/libGL.so | grep _mesa_free_context_data
>
On 05/10/2010 02:13 PM, Dan Nicholson wrote:
> On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs wrote:
>>
>> All I really want is Mesa with OSMesa from the development repository as
>> the "reference" library for my VTK and ParaView nightly test builds.
>
> ./configure --with-driver=xlib ? That w
On Mon, May 10, 2010 at 11:17 AM, tom fogal wrote:
> Dan Nicholson writes:
>> On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs wrote:
>
>> > All I really want is Mesa with OSMesa from the development
>> > repository as the "reference" library for my VTK and ParaView
>> > nightly test builds.
>>
Dan Nicholson writes:
> On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs wrote:
> > All I really want is Mesa with OSMesa from the development
> > repository as the "reference" library for my VTK and ParaView
> > nightly test builds.
>
> ./configure --with-driver=xlib ? That will link libOSMesa
On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs wrote:
>
> All I really want is Mesa with OSMesa from the development repository as
> the "reference" library for my VTK and ParaView nightly test builds.
./configure --with-driver=xlib ? That will link libOSMesa to libGL,
but that's what configs/l
"Kevin H. Hobbs" writes:
> On 05/10/2010 11:56 AM, tom fogal wrote:
> >=20
> > I recommend you check out the "build_mesa" function in:
> >=20
> > http://portal.nersc.gov/svn/visit/trunk/src/svn_bin/build_visit
> >=20
> > There's a lot we can do to make the whole VTK, Mesa/mangled or no,
> > and
On 05/10/2010 11:56 AM, tom fogal wrote:
>
> I recommend you check out the "build_mesa" function in:
>
> http://portal.nersc.gov/svn/visit/trunk/src/svn_bin/build_visit
>
> There's a lot we can do to make the whole VTK, Mesa/mangled or no,
> and VisIt/ParaView stack more amenable to compilatio
"Kevin H. Hobbs" writes:
> I deleted my mesa directory and re-cloned the repository and tried to
> build but the build stopped here :
[snip]
> In file included from nv50_context.h:19,
> from nv50_clear.c:28:
> =2E./../../../src/gallium/drivers/nouveau/nouveau_stateobj.h: In functi
On 05/10/2010 09:46 AM, Brian Paul wrote:
>
> A 'make clean' may be needed. Sometimes when source files move around
> the 'depend' files don't get properly updated.
>
> -Brian
I get the same result after 'make clean' err.. at least the build fails
with :
make[5]: *** No rule to make target
`.
On 05/10/2010 08:45 AM, Chia-I Wu wrote:
>
> I could not reproduce it here on my AMD64 machine. Can you post the
> full mesa_build.txt?
>
The entire mesa_build.txt is here:
http://crab-lab.zool.ohiou.edu/kevin/mesa_build.txt
signature.asc
Description: OpenPGP digital signature
_
On Mon, May 10, 2010 at 5:58 AM, Kevin H. Hobbs wrote:
> I run several nightly builds of VTK and ParaView with Mesa from the git
> repository.
>
> My builds for May 6 failed because Mesa failed to build.
>
> Mesa is built with :
>
> # Update Mesa
> echo "Update Mesa"
> cd /home/kevin/mesa
> make r
On Mon, May 10, 2010 at 7:58 PM, Kevin H. Hobbs wrote:
> I run several nightly builds of VTK and ParaView with Mesa from the git
> repository.
>
> My builds for May 6 failed because Mesa failed to build.
>
> Mesa is built with :
>
> # Update Mesa
> echo "Update Mesa"
> cd /home/kevin/mesa
> make r
I run several nightly builds of VTK and ParaView with Mesa from the git
repository.
My builds for May 6 failed because Mesa failed to build.
Mesa is built with :
# Update Mesa
echo "Update Mesa"
cd /home/kevin/mesa
make realclean > ~/mesa_build.txt 2>&1
git pull origin > ~/mesa_update.txt 2>&1
m
27 matches
Mail list logo