Bug 50754 - Building 32 bit mesa on 64 bit OS fails since change for automake
Summary: Building 32 bit mesa on 64 bit OS fails since change for automake
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: git
Hardware: x86-64 (AMD64) All
: medium major
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 45466 41700
  Show dependency treegraph
 
Reported: 2012-06-05 20:17 UTC by Alexandre Demers
Modified: 2014-08-16 16:17 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
hopeful fix (1.22 KB, patch)
2012-08-17 10:45 UTC, Tapani Pälli
Details | Splinter Review
Move LT_INIT where it should so it can test correctly (AM_)C(XX)FLAGS and others (1.69 KB, patch)
2013-11-22 07:31 UTC, Alexandre Demers
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Demers 2012-06-05 20:17:40 UTC
Since the last couple of days, I'm unable to build mesa. It appeared after the automake move. I can't bisect since another automake bug was in the way, but I'm sure it is related to this move. I'm using git 17e047242e82111859eb8220369c601c79a26350. The files ld is looking for exist under /usr/lib32 and /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/32/.

make[3]: Entering directory `/home/dema1701/projects/display/mesa/src/mesa/libdricore'
  CXXLD    libdricore.la
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/libstdc++.a when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libstdc++.a when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../libstdc++.a when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/libc.a when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.a when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../libc.a when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/crti.o' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/crtbeginS.o' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/crtendS.o' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/crtn.o' is incompatible with i386 output
collect2: error: ld returned 1 exit status
make[3]: *** [libdricore.la] Error 1
make[3]: Leaving directory `/home/dema1701/projects/display/mesa/src/mesa/libdricore'
make[2]: *** [dricore] Error 2
make[2]: Leaving directory `/home/dema1701/projects/display/mesa/src/mesa'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/dema1701/projects/display/mesa/src'
make: *** [default] Error 1
Comment 1 Kenneth Graunke 2012-06-05 21:46:43 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.
Comment 2 Tapani Pälli 2012-06-05 22:34:48 UTC
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."
Comment 3 Tapani Pälli 2012-06-05 23:46:07 UTC
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.
Comment 4 Brian Paul 2012-06-06 07:04:49 UTC
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.
Comment 5 Tapani Pälli 2012-06-08 00:52:46 UTC
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.
Comment 6 Ian Romanick 2012-06-08 11:09:38 UTC
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
Comment 7 Alexandre Demers 2012-06-08 11:31:03 UTC
(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.
Comment 8 Tapani Pälli 2012-08-17 10:45:33 UTC
Created attachment 65690 [details] [review]
hopeful fix

attached patch fixes the issue for me
Comment 9 Kenneth Graunke 2012-08-18 17:46:21 UTC
(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 10 Alexandre Demers 2012-08-18 18:02:25 UTC
Comment on attachment 65690 [details] [review]
hopeful fix

Review of attachment 65690 [details] [review]:
-----------------------------------------------------------------

It does the trick over here.
Comment 11 Matt Turner 2012-08-18 20:31:02 UTC
(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?
Comment 12 Alexandre Demers 2012-08-18 22:03:34 UTC
(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.
Comment 13 Tapani Pälli 2012-08-19 05:56:52 UTC
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.
Comment 14 Matt Turner 2012-08-20 17:33:34 UTC
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.
Comment 15 Alexandre Demers 2012-08-21 02:33:40 UTC
(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.
Comment 16 Matt Turner 2012-08-21 02:43:26 UTC
No. Reread the manual.

> the author(s) of the Makefile.am and configure.ac files—may adjust these shadow variables however necessary.
Comment 17 Alexandre Demers 2012-08-21 06:31:45 UTC
(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.
Comment 18 Alexandre Demers 2012-10-09 17:43:35 UTC
(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?
Comment 19 Alexandre Demers 2013-01-11 07:15:25 UTC
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.
Comment 20 Tapani Pälli 2013-01-30 12:00:14 UTC
(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'.
Comment 21 Armin K 2013-01-30 14:54:47 UTC
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
Comment 22 Alexandre Demers 2013-08-09 18:30:50 UTC
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.
Comment 23 Eero Tamminen 2013-11-21 11:46:39 UTC
(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.
Comment 24 Alexandre Demers 2013-11-22 06:31:53 UTC
(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.
Comment 25 Alexandre Demers 2013-11-22 07:31:06 UTC
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.
Comment 26 Tapani Pälli 2013-11-22 08:54:33 UTC
(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 :)
Comment 27 Alexandre Demers 2013-12-15 17:06:32 UTC
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.
Comment 28 Emil Velikov 2014-08-12 22:50:08 UTC
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
Comment 29 Emil Velikov 2014-08-14 14:53:06 UTC
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.
Comment 30 Eero Tamminen 2014-08-14 16:46:26 UTC
(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?
Comment 31 Emil Velikov 2014-08-14 16:58:12 UTC
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.
Comment 32 Matt Turner 2014-08-14 18:29:55 UTC
(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.
Comment 33 Eero Tamminen 2014-08-15 07:21:31 UTC
(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.
Comment 34 Emil Velikov 2014-08-15 09:46:09 UTC
(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 :\
Comment 35 Emil Velikov 2014-08-15 17:15:42 UTC
(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
Comment 36 Marek Olšák 2014-08-16 16:17:53 UTC
We need --build. See $host_cpu in configure.ac.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.