Menu
▾
▴
Re: [Mesa3d-users] Mesa compilation on sh4-STLinux.
|
From: Gabriel Z. <gab...@gm...> - 2009-08-11 10:01:04
|
Hi again, i checked out the scripts and i am slowly remembering what the problem was :). It is actually not and issue with the ASM flags. When mesa is compiling it is using the mklib script and i remember changing it. Now in the makefile i changed this line LIBS = $(TOP)/src/mesa/libmesa.a $(TOP)/src/mesa/libglapi.a if i remember correctly both libmesa.a and libglapi.a are made with mklib and thats where the problem was. I needed it working quickly so i did it the dirty way :) simply by replacing the aforementioned line with this: LIBS = \ ../../main/api_arrayelt.o \ ../../main/api_exec.o \ ../../main/api_loopback.o \ ../../main/api_noop.o \ ../../main/api_validate.o \ ../../main/accum.o \ ../../main/attrib.o \ ../../main/arrayobj.o \ ../../main/blend.o \ ../../main/bufferobj.o \ ../../main/buffers.o \ ../../main/clear.o \ ../../main/clip.o \ ../../main/colortab.o \ ../../main/context.o \ ../../main/convolve.o \ ../../main/debug.o \ ../../main/depth.o \ ../../main/depthstencil.o \ ../../main/dlist.o \ ../../main/dlopen.o \ ../../main/drawpix.o \ ../../main/enable.o \ ../../main/enums.o \ ../../main/eval.o \ ../../main/execmem.o \ ../../main/extensions.o \ ../../main/fbobject.o \ ../../main/feedback.o \ ../../main/ffvertex_prog.o \ ../../main/fog.o \ ../../main/framebuffer.o \ ../../main/get.o \ ../../main/getstring.o \ ../../main/hash.o \ ../../main/hint.o \ ../../main/histogram.o \ ../../main/image.o \ ../../main/imports.o \ ../../main/light.o \ ../../main/lines.o \ ../../main/matrix.o \ ../../main/mipmap.o \ ../../main/mm.o \ ../../main/multisample.o \ ../../main/pixel.o \ ../../main/pixelstore.o \ ../../main/points.o \ ../../main/polygon.o \ ../../main/queryobj.o \ ../../main/rastpos.o \ ../../main/rbadaptors.o \ ../../main/readpix.o \ ../../main/renderbuffer.o \ ../../main/scissor.o \ ../../main/shaders.o \ ../../main/state.o \ ../../main/stencil.o \ ../../main/texcompress.o \ ../../main/texcompress_s3tc.o \ ../../main/texcompress_fxt1.o \ ../../main/texenv.o \ ../../main/texenvprogram.o \ ../../main/texformat.o \ ../../main/texgen.o \ ../../main/teximage.o \ ../../main/texobj.o \ ../../main/texparam.o \ ../../main/texrender.o \ ../../main/texstate.o \ ../../main/texstore.o \ ../../main/varray.o \ ../../main/vtxfmt.o \ ../../math/m_debug_clip.o \ ../../math/m_debug_norm.o \ ../../math/m_debug_xform.o \ ../../math/m_eval.o \ ../../math/m_matrix.o \ ../../math/m_translate.o \ ../../math/m_vector.o \ ../../math/m_xform.o \ ../../vbo/vbo_context.o \ ../../vbo/vbo_exec.o \ ../../vbo/vbo_exec_api.o \ ../../vbo/vbo_exec_array.o \ ../../vbo/vbo_exec_draw.o \ ../../vbo/vbo_exec_eval.o \ ../../vbo/vbo_rebase.o \ ../../vbo/vbo_split.o \ ../../vbo/vbo_split_copy.o \ ../../vbo/vbo_split_inplace.o \ ../../vbo/vbo_save.o \ ../../vbo/vbo_save_api.o \ ../../vbo/vbo_save_draw.o \ ../../vbo/vbo_save_loopback.o \ ../../tnl/t_context.o \ ../../tnl/t_pipeline.o \ ../../tnl/t_draw.o \ ../../tnl/t_rasterpos.o \ ../../tnl/t_vb_program.o \ ../../tnl/t_vb_render.o \ ../../tnl/t_vb_texgen.o \ ../../tnl/t_vb_texmat.o \ ../../tnl/t_vb_vertex.o \ ../../tnl/t_vb_cull.o \ ../../tnl/t_vb_fog.o \ ../../tnl/t_vb_light.o \ ../../tnl/t_vb_normals.o \ ../../tnl/t_vb_points.o \ ../../tnl/t_vp_build.o \ ../../tnl/t_vertex.o \ ../../tnl/t_vertex_sse.o \ ../../tnl/t_vertex_generic.o \ ../../shader/arbprogparse.o \ ../../shader/arbprogram.o \ ../../shader/atifragshader.o \ ../../shader/grammar/grammar_mesa.o \ ../../shader/nvfragparse.o \ ../../shader/nvprogram.o \ ../../shader/nvvertparse.o \ ../../shader/program.o \ ../../shader/prog_cache.o \ ../../shader/prog_debug.o \ ../../shader/prog_execute.o \ ../../shader/prog_instruction.o \ ../../shader/prog_noise.o \ ../../shader/prog_parameter.o \ ../../shader/prog_print.o \ ../../shader/prog_statevars.o \ ../../shader/prog_uniform.o \ ../../shader/programopt.o \ ../../shader/shader_api.o \ ../../swrast/s_aaline.o \ ../../swrast/s_aatriangle.o \ ../../swrast/s_accum.o \ ../../swrast/s_alpha.o \ ../../swrast/s_atifragshader.o \ ../../swrast/s_bitmap.o \ ../../swrast/s_blend.o \ ../../swrast/s_blit.o \ ../../swrast/s_buffers.o \ ../../swrast/s_copypix.o \ ../../swrast/s_context.o \ ../../swrast/s_depth.o \ ../../swrast/s_drawpix.o \ ../../swrast/s_feedback.o \ ../../swrast/s_fog.o \ ../../swrast/s_fragprog.o \ ../../swrast/s_imaging.o \ ../../swrast/s_lines.o \ ../../swrast/s_logic.o \ ../../swrast/s_masking.o \ ../../swrast/s_points.o \ ../../swrast/s_readpix.o \ ../../swrast/s_span.o \ ../../swrast/s_stencil.o \ ../../swrast/s_texcombine.o \ ../../swrast/s_texfilter.o \ ../../swrast/s_texstore.o \ ../../swrast/s_triangle.o \ ../../swrast/s_zoom.o \ ../../swrast_setup/ss_context.o \ ../../swrast_setup/ss_triangle.o \ ../../drivers/common/driverfuncs.o \ ../../x86/common_x86.o \ ../../x86/x86.o \ ../../x86/3dnow.o \ ../../x86/sse.o \ ../../x86/rtasm/x86sse.o \ ../../sparc/sparc.o \ ../../ppc/common_ppc.o \ ../../x86-64/x86-64.o \ ../../shader/slang/slang_builtin.o \ ../../shader/slang/slang_codegen.o \ ../../shader/slang/slang_compile.o \ ../../shader/slang/slang_compile_function.o \ ../../shader/slang/slang_compile_operation.o \ ../../shader/slang/slang_compile_struct.o \ ../../shader/slang/slang_compile_variable.o \ ../../shader/slang/slang_emit.o \ ../../shader/slang/slang_ir.o \ ../../shader/slang/slang_label.o \ ../../shader/slang/slang_link.o \ ../../shader/slang/slang_log.o \ ../../shader/slang/slang_mem.o \ ../../shader/slang/slang_preprocess.o \ ../../shader/slang/slang_print.o \ ../../shader/slang/slang_simplify.o \ ../../shader/slang/slang_storage.o \ ../../shader/slang/slang_typeinfo.o \ ../../shader/slang/slang_vartable.o \ ../../shader/slang/slang_utility.o \ ../../main/dispatch.o \ ../../glapi/glapi.o \ ../../glapi/glapi_getproc.o \ ../../glapi/glthread.o all the objects are build correctly so this solved the linking issue to check whether this is the problem try objdumping the libmesa.a and libglapi.a libs - if they dont contain the symbols than that should be your issue as well. I changed these files to get mine version working: sources/Mesa-7.4.4/configs/default sources/Mesa-7.4.4/configs/linux-directfb Mesa-7.4.4/bin/mklib Mesa-7.4.4/src/mesa/drivers/directfb/Makefile <-- this is where the change i mentioned is Let me know if it wont solve the isssue. Your libGL definatelly doesnt look good. Here is greped glBegin part of mine: arm-linux-objdump -T /usr/local/arm/lib/libGL.so | grep glBegin 002024b4 g DF .text 00000058 Base glBeginQuery 001fadcc g DF .text 00000044 Base glBeginFragmentShaderATI 0021221c g DF .text 00000050 Base glBegin 0020245c g DF .text 00000058 Base glBeginQueryARB as you see the symbol glBegin is properly defined. Regards, Gabriel Zabusek On Tue, Aug 11, 2009 at 11:44 AM, Christophe Khamly <wet...@gm...>wrote: > Hi Gabriel! > > Thanks to reply so quickly I didn't expect to get an answer as fast as > yours! > Well, I will be very interesseted for testing your version. > According to my sh4-linux-objdump, I have no symbols related to the > functions needed for running the demos: > > g600219@osnp1263321f:~/target/root/Mesa-7.5/lib$ sh4-linux-objdump -t > libGL.so.7.5.0 > > libGL.so.7.5.0: file format elf32-sh-linux > > SYMBOL TABLE: > 000000b4 l d .gnu.hash 00000000 .gnu.hash > 000000f0 l d .dynsym 00000000 .dynsym > 00000180 l d .dynstr 00000000 .dynstr > 00000210 l d .gnu.version 00000000 .gnu.version > 00000224 l d .gnu.version_r 00000000 .gnu.version_r > 00000244 l d .rela.dyn 00000000 .rela.dyn > 00000274 l d .rela.plt 00000000 .rela.plt > 00000280 l d .init 00000000 .init > 000002e4 l d .plt 00000000 .plt > 00000320 l d .text 00000000 .text > 00000440 l d .fini 00000000 .fini > 00000478 l d .eh_frame 00000000 .eh_frame > 0001047c l d .ctors 00000000 .ctors > 00010484 l d .dtors 00000000 .dtors > 0001048c l d .jcr 00000000 .jcr > 00010490 l d .dynamic 00000000 .dynamic > 00010570 l d .data 00000000 .data > 00010578 l d .got 00000000 .got > 00010590 l d .bss 00000000 .bss > 00000000 l d .comment 00000000 .comment > 00000000 l df *ABS* 00000000 initfini.c > 00000000 l df *ABS* 00000000 crtstuff.c > 0001047c l O .ctors 00000000 __CTOR_LIST__ > 00010484 l O .dtors 00000000 __DTOR_LIST__ > 0001048c l O .jcr 00000000 __JCR_LIST__ > 00000320 l F .text 00000000 __do_global_dtors_aux > 00010590 l O .bss 00000001 completed.5793 > 00010574 l O .data 00000000 p.5791 > 000003a0 l F .text 00000000 frame_dummy > 00000000 l df *ABS* 00000000 crtstuff.c > 00010480 l O .ctors 00000000 __CTOR_END__ > 00010488 l O .dtors 00000000 __DTOR_END__ > 00000478 l O .eh_frame 00000000 __FRAME_END__ > 0001048c l O .jcr 00000000 __JCR_END__ > 000003e0 l F .text 00000000 __do_global_ctors_aux > 00000000 l df *ABS* 00000000 initfini.c > 00010578 l O *ABS* 00000000 .hidden _GLOBAL_OFFSET_TABLE_ > 00010570 l O .data 00000000 .hidden __dso_handle > 00010490 l O *ABS* 00000000 .hidden _DYNAMIC > 00000420 w F .text 00000000 __gmon_start__ > 00000000 w *UND* 00000000 _Jv_RegisterClasses > 00000440 g F .fini 00000000 _fini > 00000000 w F *UND* 000000d0 __cxa_finalize@@GLIBC_2.2 > 00010590 g *ABS* 00000000 __bss_start > 00010594 g *ABS* 00000000 _end > 00010590 g *ABS* 00000000 _edata > 00000280 g F .init 00000000 _init > > Also I tried to search into the folder to find the functions It seemed that > everything is done in asm for X86. > For directfb, my lib works perfectly I modifed the lower layer to fit with > my STB blitter driver. > How can you send me that? > Thanks again for your help. > > > > On Tue, Aug 11, 2009 at 11:19 AM, Gabriel Zabusek < > gab...@gm...> wrote: > >> Hi Christophe, >> >> I have successfully compiled both directfb + mesa-7.4.4 for my arm board >> (also without GPU and FPU). I actually also managed to get the OpenGLES >> wrapper (dgles) running which you might be interested in. I remember i had >> similar problem to yours however i did quite a lot of changes and dont >> remember exactly which one solved this particular issue. I wrote several >> shell scripts what build everything automatically for me (my arm-linux >> board) and everything seemed to work perfectly (i did a bit of testing - >> gears and other demos were working perfectly). Changing it to the sh4-linux >> should be very easy (probably only a matter of changing arm-linux-gcc to >> sh4-linux-gcc) so if you want i can try to do that for you and send it. I am >> not certain if i should send it to the mailing list or rather share it on >> rapidshare or something like that. >> >> Also before that you might want to objdump the library if it really >> doesn't define (*UND*) the symbols - you can do that with sh4-linux-objdumb >> -t libGL.so or sh4-linux-objdump -T ... >> >> Let me know if you are interested. >> >> Regards, >> Gabriel Zabusek >> >> On Tue, Aug 11, 2009 at 10:48 AM, Christophe Khamly <wet...@gm...>wrote: >> >>> Hi all, >>> >>> I'm trying to compile Mesa-7.5 for a SetTopBox. >>> It's a SH4 architechture for STLinux-2.3 and It will use directfb for >>> rendering (my STB has no GPU). >>> I modified the current configuration in configs/linux-directfb for doing >>> some cross-compiling and disabling the X86_source_asm compilation. >>> The compilation worked fine but after that when I wanted to compile a >>> demo in progs/demos I got this: >>> >>> root@wet:~/Mesa-7.5/progs/demos# sh4-linux-gcc -I../../include -Wall -O3 >>> -ffast-math -fPIC -std=c99 -D_GNU_SOURCE -D_POSIX_SOURCE -D_SVID_SOURCE >>> -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -DPTHREADS -fno-strict-aliasing >>> gears.c readtex.o -Xlinker -rpath /usr/X11R7/lib -L../../lib -lglut -lGLEW >>> -lGLU -lGL -L../../lib -lGL -lGLU -lglut -o gears >>> /tmp/ccTkyHLx.o: In function `gear': >>> gears.c:(.text+0x208): undefined reference to `glShadeModel' >>> gears.c:(.text+0x224): undefined reference to `glNormal3f' >>> gears.c:(.text+0x230): undefined reference to `glBegin' >>> gears.c:(.text+0x250): undefined reference to `glVertex3f' >>> gears.c:(.text+0x254): undefined reference to `glVertex3f' >>> gears.c:(.text+0x258): undefined reference to `glEnd' >>> gears.c:(.text+0x25c): undefined reference to `glBegin' >>> gears.c:(.text+0x47c): undefined reference to `glVertex3f' >>> gears.c:(.text+0x48c): undefined reference to `glVertex3f' >>> gears.c:(.text+0x498): undefined reference to `glVertex3f' >>> gears.c:(.text+0x4a4): undefined reference to `glVertex3f' >>> gears.c:(.text+0x4a8): undefined reference to `glEnd' >>> gears.c:(.text+0x4ac): undefined reference to `glNormal3f' >>> gears.c:(.text+0x4b8): undefined reference to `glBegin' >>> gears.c:(.text+0x6f0): undefined reference to `glVertex3f' >>> gears.c:(.text+0x6f4): undefined reference to `glVertex3f' >>> gears.c:(.text+0x6f8): undefined reference to `glEnd' >>> gears.c:(.text+0x6fc): undefined reference to `glBegin' >>> ......and so on >>> >>> I have all the libs needed by this compilation. >>> So It seems that the problem might be caused by disabling the X86_ASM >>> flags, which contains these symbols. >>> How I can solve this problem? is there a generic code in C replacing the >>> X86_ASM? >>> >>> Thanks for your answers. >>> >>> -- >>> Christophe KHAMLY >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Mesa3d-users mailing list >>> Mes...@li... >>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users >>> >>> >> >> >> -- >> >> .............................................................................................................................................. >> >> "...the finding of new proofs for known truths is often at least as >> important as the discovery itself..." >> >> > > > -- > Christophe KHAMLY > > -- .............................................................................................................................................. "...the finding of new proofs for known truths is often at least as important as the discovery itself..." |
