| Summary: | Building 32 bit mesa on 64 bit OS fails since change for automake | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Alexandre Demers <alexandre.f.demers> |
| Component: | Other | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | medium | CC: | eero.t.tamminen, petri.latvala |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 41700, 45466 | ||
| Attachments: |
hopeful fix
Move LT_INIT where it should so it can test correctly (AM_)C(XX)FLAGS and others |
||
|
Description
Alexandre Demers
2012-06-05 20:17:40 UTC
One change is that the --enable-32-bit configure option doesn't propagate -m32 to all the right places anymore. I was able to successfully build Mesa master with: CFLAGS='-m32' CXXFLAGS='-m32' ./autogen.sh --enable-32-bit --enable-gles2 --enable-gles1 --disable-glu --with-gallium-drivers= --with-dri-drivers=swrast,i965 --enable-texture-float --enable-debug --enable-shared-glapi --enable-glx-tls I'm going to assume you didn't specify CFLAGS/CXXFLAGS and close the bug, but feel free to reopen if that doesn't work for you. I'm hitting this issue in linking phase as well, I've tried to hunt down where it all fails and my main suspect is libtool, either its usage of '-nostdlib' or maybe its hitting this one : https://projects.coin-or.org/BuildTools/ticket/13 Quote from the bug : "The problem is (at least for -m32 on x86_84) that libtool sets sys_lib_search_path_spec incorrectly. If the GNU compiler is used, it gets the value from gcc -print-search-dirs, which doesn't give the correct values for compilation with the -m32 flag." but it seems Kenneth's CFLAGS='-m32' CXXFLAGS='-m32' does the trick indeed, would be good to hunt these down so that '--enable-32-bit' would be enough. I think this should be fixed too. Having to set CFLAGS and CXXFLAGS is rather cryptic. (Same story with -g and --enable-debug, grrr). I'm going to re-open this as a reminder that this should be fixed. There is a difference in the generated libtool script. When running autogen.sh by manually setting CFLAGS and CXXFLAGS as "-m32" it has : # Compile-time system search path for libraries. sys_lib_search_path_spec="/usr/lib/gcc/x86_64-redhat-linux/4.7.0 /usr/lib /lib " # The linker used to build libraries. LD="/usr/bin/ld -m elf_i386" however without them (only using --enable-32-bit) you have : # Compile-time system search path for libraries. sys_lib_search_path_spec="/usr/lib/gcc/x86_64-redhat-linux/4.7.0 /usr/lib64 /lib64 " # The linker used to build libraries. LD="/usr/bin/ld -m elf_x86_64". I believe this is the reason, I will continue debugging this. Let's be honest, building 32-bit Mesa on a 64-bit system has been a disaster for a long time. See bug #41700, bug #45466, and http://lists.freedesktop.org/archives/mesa-dev/2012-March/020481.html (In reply to comment #6) > Let's be honest, building 32-bit Mesa on a 64-bit system has been a disaster > for a long time. See bug #41700, bug #45466, and > http://lists.freedesktop.org/archives/mesa-dev/2012-March/020481.html I don't know for others, but I'm used to build mesa 32 bit on Arch 64 without any efforts. From time to time, yes, problems arise, but mostly they get fixed when someone take care to look at them. A couple of months ago, I was doing the same thing under Ubuntu 64. So, in my point of view, things are not that bad when we work together. I just need to specify some installation paths. At some point, I had to specify some C and C++ flags, but not anymore (well, not since this bug report). By the way, bug 41700 should be closed if the patch proposed in comment 1 is true. Created attachment 65690 [details] [review] hopeful fix attached patch fixes the issue for me (In reply to comment #8) > Created attachment 65690 [details] [review] [review] > hopeful fix > > attached patch fixes the issue for me That does seem to produce a 32-bit build with only --enable-32-bit. Nice :) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Comment on attachment 65690 [details] [review] hopeful fix Review of attachment 65690 [details] [review]: ----------------------------------------------------------------- It does the trick over here. (In reply to comment #8) > Created attachment 65690 [details] [review] [review] > hopeful fix > > attached patch fixes the issue for me Can you explain why this works? (In reply to comment #11) > (In reply to comment #8) > > Created attachment 65690 [details] [review] [review] [review] > > hopeful fix > > > > attached patch fixes the issue for me > > Can you explain why this works? According to http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html, LT_INIT will test some environment variables, CFLAGS being one of them. By moving the LT_INIT macro from line 27 below line 274, CFLAGS is now defined according to 32 or 64 bit build (done between lines 240 and 270). That is, by setting "--enable-32-bit" when building mesa (line 248), CFLAGS="$CFLAGS -m32" (line 250), thus LT_INIT will consider using 32 bit mode when initialized. Yep, this is the configuration step for generated libtool script, sys_lib_search_path_spec value gets correct library paths this way depending on arch. It looks like in general that we shouldn't modify the CFLAGS/CXXFLAGS in configure.ac, but rather use AM_* (according to http://www.gnu.org/software/automake/manual/automake.html#User-Variables). I'll play with this and see if I can get it to work. (In reply to comment #14) > It looks like in general that we shouldn't modify the CFLAGS/CXXFLAGS in > configure.ac, but rather use AM_* (according to > http://www.gnu.org/software/automake/manual/automake.html#User-Variables). I'll > play with this and see if I can get it to work. Indeed. But may I suggest applying the current patch anyway. Reason is: we should call LT_INIT after the --enable-XX-bit flags whatever we use CFLAGS or AM_something since these variables will be defined by the --enable-XX-bit flags. No. Reread the manual.
> the author(s) of the Makefile.am and configure.ac files—may adjust these shadow variables however necessary.
(In reply to comment #16) > No. Reread the manual. > > > the author(s) of the Makefile.am and configure.ac files—may adjust these shadow variables however necessary. I do see your point. I don't mean we should use CFLAGS, I mean that from what I understand, some (shadow) variables will be set first before being used. We could go with predefined macros AC_CANONICAL_BUILD, AC_CANONICAL_HOST and AC_CANONICAL_TARGET where --build, --host and --target can be used to override the macros detection (http://www.gnu.org/software/automake/manual/autoconf.html#Canonicalizing). We could also choose to define AM_CFLAGS, AM_CXXFLAGS and AM_CCASFLAGS according to --enable-XX-bit flags (http://www.gnu.org/software/automake/manual/automake.html#Flag-Variables-Ordering). Then, maybe LT_INIT can do something of it, but I haven't read until there. Anyway, from what you said, you are already looking at it. I'm curious to see what will come up. (In reply to comment #14) > It looks like in general that we shouldn't modify the CFLAGS/CXXFLAGS in > configure.ac, but rather use AM_* (according to > http://www.gnu.org/software/automake/manual/automake.html#User-Variables). > I'll play with this and see if I can get it to work. Any development on fixing this issue? Even with today's changes to mesa, it's not fixed. We still need to add -m32 to CFLAGS and CXXFLAGS for everything to successfully build. osMesa is the first I'm hitting a bug with. (In reply to comment #19) > Even with today's changes to mesa, it's not fixed. We still need to add -m32 > to CFLAGS and CXXFLAGS for everything to successfully build. osMesa is the > first I'm hitting a bug with. My patch fixes this issue, I see no problems of initializing libtool only later, it is not used before that point, libtool init can also be moved to happen just before AC_OUTPUT if you think this would look 'cleaner'. I can confirm this on latest 9.1 checkout. CC osmesa.lo CXXLD libOSMesa.la /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ast_expr.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ast_function.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ast_to_hir.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ast_type.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(builtin_variables.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(glcpp-lex.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(glcpp-parse.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(glsl_lexer.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(glsl_parser.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(glsl_parser_extras.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(glsl_symbol_table.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(glsl_types.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(hir_field_selection.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_basic_block.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_builder.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_clone.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_constant_expression.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_expression_flattening.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_function.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_function_can_inline.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_function_detect_recursion.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_hierarchical_visitor.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_hv_accept.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_import_prototypes.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_print_visitor.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_reader.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_rvalue_visitor.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_set_program_inouts.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_validate.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ir_variable_refcount.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(link_functions.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(link_uniform_block_active_visitor.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(link_uniform_blocks.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(link_uniform_initializers.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(link_uniforms.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(link_varyings.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(linker.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(loop_analysis.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(loop_controls.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(loop_unroll.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_clip_distance.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_discard.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_discard_flow.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_if_to_cond_assign.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_instructions.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_jumps.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_mat_op_to_vec.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_noise.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_output_reads.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_packed_varyings.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_packing_builtins.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_texture_projection.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_ubo_reference.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_variable_index_to_cond_assign.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_vec_index_to_cond_assign.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_vec_index_to_swizzle.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(lower_vector.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_algebraic.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_array_splitting.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_constant_folding.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_constant_propagation.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_constant_variable.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_copy_propagation.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_copy_propagation_elements.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_dead_code.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_dead_code_local.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_dead_functions.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_function_inlining.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_if_simplification.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_noop_swizzle.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_redundant_jumps.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_structure_splitting.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_swizzle_swizzle.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(opt_tree_grafting.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(pp.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(ralloc.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(s_expression.o)' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `../../../../src/mesa/.libs/libmesa.a(strtod.o)' is incompatible with i386 output ../../../../src/mesa/.libs/libmesa.a(ir_variable_refcount.o): In function `ir_variable_refcount_visitor::get_variable_entry(ir_variable*)': /home/armin/src/Mesa-9.1+git20130129-32/src/glsl/builtin_compiler/../../../src/glsl/ir_variable_refcount.cpp:79: undefined reference to `operator new(unsigned long)' ../../../../src/mesa/.libs/libmesa.a(link_uniforms.o): In function `link_assign_uniform_locations(gl_shader_program*)': /home/armin/src/Mesa-9.1+git20130129-32/src/glsl/builtin_compiler/../../../src/glsl/link_uniforms.cpp:633: undefined reference to `operator new(unsigned long)' ../../../../src/mesa/.libs/libmesa.a(loop_analysis.o): In function `loop_analysis::loop_analysis()': /home/armin/src/Mesa-9.1+git20130129-32/src/glsl/builtin_compiler/../../../src/glsl/loop_analysis.cpp:134: undefined reference to `operator new(unsigned long)' ../../../../src/mesa/.libs/libmesa.a(opt_function_inlining.o): In function `ir_call::generate_inline(ir_instruction*)': /home/armin/src/Mesa-9.1+git20130129-32/src/glsl/builtin_compiler/../../../src/glsl/opt_function_inlining.cpp:113: undefined reference to `operator new[](unsigned long)' /home/armin/src/Mesa-9.1+git20130129-32/src/glsl/builtin_compiler/../../../src/glsl/opt_function_inlining.cpp:113: undefined reference to `operator new[](unsigned long)' collect2: error: ld returned 1 exit status make[5]: *** [libOSMesa.la] Error 1 Tried with various combinations of configure scripts PKG_CONFIG_PATH=/usr/lib32/pkgconfig LLVM_CONFIG=/usr/bin/llvm-config32 ./configure --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib32 --enable-32-bit --enable-texture-float --enable-gles1 --enable-gles2 --enable-openvg --enable-osmesa --enable-xa --enable-gbm --enable-gallium-egl --enable-gallium-gbm --enable-glx-tls --with-egl-platforms="drm,x11,wayland" --with-gallium-drivers="nouveau,r300,r600,radeonsi,svga,swrast" --with-llvm-shared-libs --enable-opencl --enable-xvmc --enable-vdpau --with-clang-libdir=/usr/lib CFLAGS="-m32 -march=core2 -O2" CXXFLAGS="-m32 -march=core2 -O2" CC="gcc -m32" CXX="g++ -m32" PKG_CONFIG_PATH=/usr/lib32/pkgconfig LLVM_CONFIG=/usr/bin/llvm-config32 ./configure --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib32 --enable-32-bit --enable-texture-float --enable-gles1 --enable-gles2 --enable-openvg --enable-osmesa --enable-xa --enable-gbm --enable-gallium-egl --enable-gallium-gbm --enable-glx-tls --with-egl-platforms="drm,x11,wayland" --with-gallium-drivers="nouveau,r300,r600,radeonsi,svga,swrast" --with-llvm-shared-libs --enable-opencl --enable-xvmc --enable-vdpau --with-clang-libdir=/usr/lib CFLAGS="-march=core2 -O2" CXXFLAGS="-march=core2 -O2" CC="gcc -m32" CXX="g++ -m32" PKG_CONFIG_PATH=/usr/lib32/pkgconfig LLVM_CONFIG=/usr/bin/llvm-config32 ./configure --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib32 --enable-32-bit --enable-texture-float --enable-gles1 --enable-gles2 --enable-openvg --enable-osmesa --enable-xa --enable-gbm --enable-gallium-egl --enable-gallium-gbm --enable-glx-tls --with-egl-platforms="drm,x11,wayland" --with-gallium-drivers="nouveau,r300,r600,radeonsi,svga,swrast" --with-llvm-shared-libs --enable-opencl --enable-xvmc --enable-vdpau --with-clang-libdir=/usr/lib CC="gcc -m32" CXX="g++ -m32" PKG_CONFIG_PATH=/usr/lib32/pkgconfig LLVM_CONFIG=/usr/bin/llvm-config32 ./configure --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib32 --enable-32-bit --enable-texture-float --enable-gles1 --enable-gles2 --enable-openvg --enable-osmesa --enable-xa --enable-gbm --enable-gallium-egl --enable-gallium-gbm --enable-glx-tls --with-egl-platforms="drm,x11,wayland" --with-gallium-drivers="nouveau,r300,r600,radeonsi,svga,swrast" --with-llvm-shared-libs --enable-opencl --enable-xvmc --enable-vdpau --with-clang-libdir=/usr/lib32 CC="gcc -m32" CXX="g++ -m32" PKG_CONFIG_PATH=/usr/lib32/pkgconfig LLVM_CONFIG=/usr/bin/llvm-config32 ./configure --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib32 --enable-32-bit --enable-texture-float --enable-gles1 --enable-gles2 --enable-openvg --enable-osmesa --enable-xa --enable-gbm --enable-gallium-egl --enable-gallium-gbm --enable-glx-tls --with-egl-platforms="drm,x11,wayland" --with-gallium-drivers="nouveau,r300,r600,radeonsi,svga,swrast" --enable-xvmc --enable-vdpau --with-clang-libdir=/usr/lib I'm closing this bug because I'm able to crosscompile anytime with the help of some variables. export CFLAGS='-m32' export CXXFLAGS='-m32' export LLVM_CONFIG='/usr/bin/llvm-config32' export PKG_CONFIG_PATH="/usr/lib/i386-linux-gnu/pkgconfig" Exec32="$baseExec --enable-32-bit --build=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu --libdir=/usr/lib/i386-linux-gnu --includedir=/usr/include/i386-linux-gnu" I'm using the same options for a couple of projects and it works great instead of relying only on the auto configuration scripts. (In reply to comment #22) > I'm closing this bug because I'm able to crosscompile anytime with the help > of some variables. This is Mesa bug. You being able to work around Mesa bug doesn't mean that it's fixed in Mesa. Re-opening. IMHO either --enable-32-bit should be removed as misleading[1], or Mesa should be fixed. [1] as discussed, it sets CFLAGS/CXXFLAGS too late, so they don't have the required effect. Regarding Tapani's patch fixing this, there would need to be also a comment in configure.ac about the libtool initialization dependency on C/XXFLAGS values. (In reply to comment #23) > (In reply to comment #22) > > I'm closing this bug because I'm able to crosscompile anytime with the help > > of some variables. > > This is Mesa bug. You being able to work around Mesa bug doesn't mean that > it's fixed in Mesa. Re-opening. > > IMHO either --enable-32-bit should be removed as misleading[1], or Mesa > should be fixed. > > [1] as discussed, it sets CFLAGS/CXXFLAGS too late, so they don't have the > required effect. > > > Regarding Tapani's patch fixing this, there would need to be also a comment > in configure.ac about the libtool initialization dependency on C/XXFLAGS > values. The problem has been flagged many times. No decision has ever been taken. Having a recurring bug like this one where it is a matter of either fixing it or removing it shouldn't stay forever opened. When I closed it, because I had a workaround, I was considering the silence on this bug and the other similar ones as "WONTBEFIXED". I'd be glad to either see it being fixed or dumped. As you say, if --enable-32-bit is not working as intended for anybody, then it is misleading and useless, thus it should be removed. In the Doc, we could indicate the "workaround" (which is not a workaround per-se because it is actually the detailed way of doing it instead of relying on an automated flag like "--enable-32-bit"). We even have an almost (yet simple) patch proposed that only needs a little fix as it seems. Created attachment 89621 [details] [review] Move LT_INIT where it should so it can test correctly (AM_)C(XX)FLAGS and others Updated patch against latest git code. Based on previous patch with further explanations. LT_INIT needs to work with the final content of variables to be able to correctly run some tests and determine the host type. So it must be called after setting anything we want to set in (AM_)C(XX)FLAGS or (AM_)LDFLAGS. Fixing LT_INIT must be done independently from modifying environment variables or build variables since LT_INIT will check both variables and shadow variables if they are set. Tested on my setup and it works. I'd like someone else to also test it. Another patch should be made to fix llvm-config, which is another topic. (In reply to comment #25) > Created attachment 89621 [details] [review] [review] > Move LT_INIT where it should so it can test correctly (AM_)C(XX)FLAGS and > others > > Updated patch against latest git code. > Based on previous patch with further explanations. > > LT_INIT needs to work with the final content of variables to be able to > correctly run some tests and determine the host type. So it must be called > after setting anything we want to set in (AM_)C(XX)FLAGS or (AM_)LDFLAGS. > > Fixing LT_INIT must be done independently from modifying environment > variables or build variables since LT_INIT will check both variables and > shadow variables if they are set. > > Tested on my setup and it works. I'd like someone else to also test it. > > Another patch should be made to fix llvm-config, which is another topic. Yep I verified this on my machine, the patch still works with the comments :) The proposed patch here is a trivial change. It fixes the reported bug by moving LT_INIT where it should be according to the documentation (it needs to know the full content of (AM_)C(XX)FLAGS variables). Could someone review it and push it if it is ok with them? Otherwise, please explain why it can't be. Thanks for the patch Alexandre, and sorry for the delay - it went under my radar. Pushed to master commit 2af28040d639dddbb7c258981a00eaf3dfcbcf03 Author: Alexandre Demers <alexandre.f.demers@gmail.com> Date: Fri Nov 22 20:06:20 2013 -0500 configure: Fix --enable-XX-bit flags by moving LT_INIT where it should Moving LT_INIT after setting completely (AM_)C(XX)FLAGS and LDFLAGS. LT_INIT needs them as they are expected to be used all along the compilation when the macro runs its tests to determine among other things the host type. For info, see http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html Hello gents, While this patch looks correct at first sight I caused quite a few issues with other parts of mesa. As such I've reverted it, removed the hacky --enable-32,64-bit options, and documented (docs/autoconf.html) a reasonable approach towards multilib/cross-compile builds. (In reply to comment #29) > While this patch looks correct at first sight I caused quite a few issues > with other parts of mesa. As such I've reverted it, removed the hacky > --enable-32,64-bit options, and documented (docs/autoconf.html) a reasonable > approach towards multilib/cross-compile builds. Could you document here what kind of issues it causes? From the revert https://bugs.freedesktop.org/show_bug.cgi?id=82536 https://bugs.freedesktop.org/show_bug.cgi?id=82546 The latter of which is due to "enable_static" being defined way too late in configure.ac, while I've not really investigated the former. I'm suspecting another issue where the LIBDRM_* ends up undefined, although that one is yet to be confirmed. (In reply to comment #30) > (In reply to comment #29) > > While this patch looks correct at first sight I caused quite a few issues > > with other parts of mesa. As such I've reverted it, removed the hacky > > --enable-32,64-bit options, and documented (docs/autoconf.html) a reasonable > > approach towards multilib/cross-compile builds. > > Could you document here what kind of issues it causes? I don't think that's particularly useful to document in autoconf.html. Basically, the --enable-{32,64}-bit flags were neither necessary nor sufficient. configure.ac is not supposed to modify CFLAGS/CXXFLAGS. The --enable-{32,64}-bit flags operated by doing exactly that, and as such they didn't work (see this bug) and caused other problems. To work around this bug, you ended up setting -m32 in your CFLAGS anyway, so the only thing these flags did was to set the assembly architecture. Setting the --build and --host does that anyway. So throwing out these hacks is the right thing to do. (In reply to comment #29) > and documented (docs/autoconf.html) a reasonable approach towards > multilib/cross-compile builds. ---------- <p>The following should be sufficient to configure multilib Mesa</p> <code>./configure CC="gcc -m32" CXX="g++ -m32" --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu ...</code> ---------- You should also definitely mention here pkg-config. E.g. state it as: In addition to specifying correct PKG_CONFIG_PATH for the target architecture, following should be sufficient... Also, "--host" option is redundant, according to Autoconf manual it defaults to same as "--build" i.e. you need to specify it only if it differs from --build. (In reply to comment #33) > (In reply to comment #29) > > and documented (docs/autoconf.html) a reasonable approach towards > > multilib/cross-compile builds. > > ---------- > <p>The following should be sufficient to configure multilib Mesa</p> > > <code>./configure CC="gcc -m32" CXX="g++ -m32" --build=i686-pc-linux-gnu > --host=i686-pc-linux-gnu ...</code> > ---------- > > You should also definitely mention here pkg-config. E.g. state it as: > In addition to specifying correct PKG_CONFIG_PATH for the target > architecture, following should be sufficient... > I've assumed that will about PKG_CONFIG_PATH prior to host/build, but I guess it makes sense to explicitly mention it. Thanks. > Also, "--host" option is redundant, according to Autoconf manual it defaults > to same as "--build" i.e. you need to specify it only if it differs from > --build. Last minute typo there. --build should read x86_64-pc-linux-gnu on both places. Perhaps we could drop the multilib build/host if a brave soul checks mesa (src/mesa/main, src/glsl) and confirms that we no longer need them. Otherwise 'make check' will end up failing :\ (In reply to comment #34) > (In reply to comment #33) > > (In reply to comment #29) > > > and documented (docs/autoconf.html) a reasonable approach towards > > > multilib/cross-compile builds. > > > > ---------- > > <p>The following should be sufficient to configure multilib Mesa</p> > > > > <code>./configure CC="gcc -m32" CXX="g++ -m32" --build=i686-pc-linux-gnu > > --host=i686-pc-linux-gnu ...</code> > > ---------- > > > > You should also definitely mention here pkg-config. E.g. state it as: > > In addition to specifying correct PKG_CONFIG_PATH for the target > > architecture, following should be sufficient... > > > I've assumed that will about PKG_CONFIG_PATH prior to host/build, but I *assumed that people will read about... > guess it makes sense to explicitly mention it. Thanks. > > > Also, "--host" option is redundant, according to Autoconf manual it defaults > > to same as "--build" i.e. you need to specify it only if it differs from > > --build. > Last minute typo there. --build should read x86_64-pc-linux-gnu on both > places. Perhaps we could drop the multilib build/host if a brave soul checks > mesa (src/mesa/main, src/glsl) and confirms that we no longer need them. > Otherwise 'make check' will end up failing :\ Added your suggestion and cleared up the typos (I hope). Thanks We need --build. See $host_cpu in configure.ac. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.