Problem with resource files on Ubuntu

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with resource files on Ubuntu

Ian Emmons
I am trying to build a shared library on several platforms (Windows, Macintosh, and Ubuntu Linux), and in both 32- and 64-bits (universal binaries on Mac).  This works well on Windows and Mac, but I am having trouble with Ubuntu.  I am running Ubuntu Linux 10.04, 64-bit, with the Boost.Build that is bundled in Boost 1.43.0 and bjam 3.1.18.  The 64-bit build works fine, but cross-compiling for 32-bits fails on the resource file, Version.res.  The output of bjam is shown below (abbreviated a bit by removing most of the .o's from the link command).

I've tried digging into the Boost.Build sources to find the problem, but unfortunately I am not expert enough to decode exactly what's going on.  It appears that on non-Windows platforms, a .res target causes an invocation of the assembler to create an empty .o, thus effectively making the .res file into a no-op.  However, when cross-compiling the appropriate options (in this case "--32" or "--64") are not added to the assembler's command line, and so it compiles a native .o that then fails to link with the .o's that came from the C++ compiler.

I'm not sure why Boost.Build doesn't just invoke the C++ compiler on an empty .cpp file to accomplish the same thing.  That would ensure compatibility of the .o's without any extra work to get the command line options right.

Any ideas on how I can fix (or work around) this issue?

Thanks in advance,

Ian

P.S.:  When I build a .res file on Macintosh (using "architecture=combined address-model=32_64" to get universal binaries), the link command generates innocuous warnings because the "empty" .o resulting from the .res file has only the one architecture in it.  I was able to produce a universal .o manually with the following commands:

touch empty.cpp
g++ -arch i386 -arch x86_64 -arch ppc -arch ppc64 -o empty.o -c empty.cpp

Boost.Build links this file into my universal binary without any warnings.  (On Snow Leopard, of course, we don't want the "-arch ppc64" option, but that seems to be correctly handled elsewhere in Boost.Build.)


=========================================


gcc.link.dll ../../target/bin/native/Parliament/KbCore/gcc-4.4/release/address-model-32/threading-multi/libParliament.so
/usr/bin/ld: i386:x86-64 architecture of input file `../../target/bin/native/Parliament/KbCore/gcc-4.4/release/address-model-32/threading-multi/Version_res.o' is incompatible with i386 output
collect2: ld returned 1 exit status

 "g++" -L"/usr/local/BerkeleyDB.5.0/32/lib"   -o "../../target/bin/native/Parliament/KbCore/gcc-4.4/release/address-model-32/threading-multi/libParliament.so" -Wl,-h -Wl,libParliament.so -shared -Wl,--start-group "../../target/bin/native/Parliament/KbCore/gcc-4.4/release/address-model-32/threading-multi/Config.o" <<snip>> "../../target/bin/native/Parliament/KbCore/gcc-4.4/release/address-model-32/threading-multi/Version_res.o"  -Wl,-Bstatic  -Wl,-Bdynamic -ldb -lrt -Wl,--end-group -pthread -m32

...failed gcc.link.dll ../../target/bin/native/Parliament/KbCore/gcc-4.4/release/address-model-32/threading-multi/libParliament.so...
...failed updating 1 target...
...updated 1 target...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Problem with resource files on Ubuntu

Juergen Hunold-2
Hi Ian,

On Tuesday, 7. September 2010 14:13:35 Ian Emmons wrote:
> The 64-bit
> build works fine, but cross-compiling for 32-bits fails on the resource
> file, Version.res.

Yes, because the resource compiler is not specified.

> I've tried digging into the Boost.Build sources to find the problem, but
> unfortunately I am not expert enough to decode exactly what's going
> on.  It appears that on non-Windows platforms, a .res target causes an
> invocation of the assembler to create an empty .o, thus effectively making
> the .res file into a no-op.  However, when cross-compiling the appropriate
> options (in this case "--32" or "--64") are not added to the assembler's
> command line, and so it compiles a native .o that then fails to link with
> the .o's that came from the C++ compiler.

Symptoms of a missing resource compiler.

> I'm not sure why Boost.Build doesn't just invoke the C++ compiler on an
> empty .cpp file to accomplish the same thing.  That would ensure
> compatibility of the .o's without any extra work to get the command line
> options right.

That would be an option, yes.

> Any ideas on how I can fix (or work around) this issue?

I configure gcc like this

using gcc :
          : # compile-command                  
            i386-mingw32-g++
          : #options
            <rc>i386-mingw32-windres
            <archiver>i386-mingw32-ar
          ;

you just have to add <rc> and maybe <archiver> for static linking.

Yours,

Jürgen
--
* Dipl.-Math. Jürgen Hunold       ! Ingenieurgesellschaft für
* voice: ++49 511 262926 57       ! Verkehrs- und Eisenbahnwesen mbH  
* fax  : ++49 511 262926 99       ! Lister Straße 15
* [hidden email]        ! www.ivembh.de
*
* Geschäftsführer:                ! Sitz des Unternehmens: Hannover
* Prof. Dr.-Ing. Thomas Siefer    ! Amtsgericht Hannover, HRB 56965
* PD Dr.-Ing. Alfons Radtke       !

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Problem with resource files on Ubuntu

Ian Emmons
Jürgen,

Thanks for responding.

On Sep 7, 2010, at 10:26 AM, Jürgen Hunold wrote:
> On Tuesday, 7. September 2010 14:13:35 Ian Emmons wrote:
>> The 64-bit
>> build works fine, but cross-compiling for 32-bits fails on the resource
>> file, Version.res.
>
> Yes, because the resource compiler is not specified.

I was under the impression (possibly wrong) that on Ubuntu (and Linux in general), there is no resource compiler and Boost.Build simply creates an "empty" .o file (meaning it contains no symbols, not that it is literally zero-length) to serve as the compiled form of the .rc file.  This preserves the chain of targets and dependencies that links the .rc source to the linker output.

My interpretation of the error messages (see my original email on this thread) is that Boost.Build invokes the "resource compiler" (actually the assembler) to correctly produce the "empty" .o, but that it ignores the address-model setting while doing so, and therefore produces a .o of the wrong bitness.  The linker then fails to link this .o into the final executable.

This is why I recommend using the C++ compiler (rather than the assembler) to produce the "empty" .o -- Boost.Build can then use the identical command line args for the .rc as it does for the .cpp sources, and the "empty" .o will be guaranteed to be compatible.

Thanks,

Ian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build