#872 Issues cross-compiling 32-bit on a 64-bit (Linux) system

[Anonymous]

I have run into a couple small issues that prevent compiling a 32-bit executable on a 64-bit Linux system.
For reference, I am setting LDFLAGS, CFLAGS, and CXXFLAGS to -m32 when running configure.

1. libvpi is compiled directly using $(CC) and does not incorporate $(CFLAGS) and $(CPPFLAGS), so it loses the -m32. Either $(CFLAGS) and $(CPPFLAGS) should be added to the command in vvp/Makefile.in, or (preferably) the rule should be split into steps that Make can understand and automatically fill in the details.

2. libveriuser.o is linked directly using $(LD), so it too loses -m32 (libveriuser/Makefile.in). I thought it was pretty strange that you're manually combining the .o files with LD when ar can do that for you. I removed that rule entirely and just had libveriuser.a pull in all of the object files in $O, rendering that issue moot.

3. cadpli.vpl (cadpli/Makefile.in) is linked directly using $(CC) and does not...you guessed it...incorporate $(LDFLAGS). Also, as a continuation of 3, I made it depend on libveriuser.a instead of the intermediate .o.

4. null.tgt, stub.tgt and vvp.tgt (tgt-{null,stub,vvp}/Makefile.in) are compiled directly using $(CC) and don't have the $(CFLAGS) and $(CPPFLAGS)

5. vhdl.tgt (tgt-vhdl/Makefile.in) is missing $(CXXFLAGS) and $(CPPFLAGS)

6. check_identifier in lexor_keyword.cc seems to be getting lost. Removing __inline fixes it. This may just be an issue with my system, but building 64-bit works fine.
g++ -rdynamic -m32 -o ivl main.o async.o design_dump.o discipline.o dup_expr.o elaborate.o elab_expr.o elaborate_analog.o elab_lval.o elab_net.o elab_pexpr.o elab_scope.o elab_sig.o elab_sig_analog.o emit.o eval.o eval_attrib.o eval_tree.o expr_synth.o functor.o lexor.o lexor_keyword.o link_const.o load_module.o netlist.o netmisc.o net_analog.o net_assign.o net_design.o net_event.o net_expr.o net_func.o net_link.o net_modulo.o net_nex_input.o net_nex_output.o net_proc.o net_scope.o net_tran.o net_udp.o pad_to_width.o parse.o parse_misc.o pform.o pform_analog.o pform_disciplines.o pform_dump.o pform_types.o set_width.o symbol_search.o sync.o sys_funcs.o verinum.o verireal.o target.o Attrib.o HName.o LineInfo.o Module.o PDelays.o PEvent.o PExpr.o PGate.o PGenerate.o PScope.o PSpec.o PTask.o PUdp.o PFunction.o PWire.o Statement.o AStatement.o StringHeap.o cprop.o nodangle.o synth.o synth2.o syn-rules.o t-dll.o t-dll-api.o t-dll-expr.o t-dll-proc.o t-dll-analog.o -ldl
lexor_keyword.o: In function `lexor_keyword_code(char const*, unsigned int)':
lexor_keyword.cc:(.text+0x14): undefined reference to `check_identifier(char const*, unsigned int)'
collect2: ld returned 1 exit status

With these changes, I am able to build a 32-bit iverilog on a 64-bit system with the above configure parameters.

Patches attached (#6 is a separate patch since I'm not entirely sure what's up with that).

[Anonymous]

Patches needed for compilation

[Cary R.]

I'll look at these patches when I have some free time. I've been working on getting the development branch to correctly cross compile and this sounds related to that work.

Thanks for the patches.

[Cary R.]

Just FYI lexor_keywords.cc is generated by gperf and the code you are changing is automatically generated so we can't apply the patch since this file is not part of the repository. We may need more information about your setup and exactly what you are doing to get this to fail. I'll use a 64 bit system to emulate what I think you are doing, but there's no guarantee I'll get the same results.

[Cary R.]

What exact Linux system and compiler version are you using for this? I agree with the spirit of the changes mentioned in 1-5, but 6 seems like a compiler bug. The good thing is I think I can reproduce it on my 64 bit RHEL 5 machine.

[Nobody/Anonymous]

This build is on Ubuntu 11.04, x86_64, kernel 2.6.38-10-server.
gcc --version: 4.5.2-8ubuntu4
bison --version: 2.4.1

[Cary R.]

Thanks, I'll create a VirtualBox image of this if my existing systems don't provide enough clues.

[Cary R.]

I've submitted a patch that addresses some of these issues. I will look at this in a holistic manner and try to address all the issues later when I have some free time.

[Stephen Williams]

Have you tried using CC='cc =-m32' CXX='g++ -m32' when configuring? This is more typically how it is done, and gives configure a chance to configure based on the cross choice.

[Cary R.]

Note that should be CC='cc -m32'

I've been debugging this using the mingw32-w64 compiler under Cygwin. There are still a few things I want to straighten out, but I don't have time at the moment. It will probably be a few weeks. Unless things go really well and unfortunately I'm not expecting that.