Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I also ran into this strange (to me) linker error for my build of Boost on Windows Server 2003 using VS2005. I'm using similar <code>bjam</code> command-line options as the OP was, but without the <code>--layout=system</code> option since I don't mind the version info in them (not yet).</p> <p>The <em>executive summary</em> of the verbiage that follows is: If you see <code>LINK : fatal error LNK1104: cannot open file 'libboost_regex-vc80-mt-gd-1_42.lib'</code>, then you need to to specify the same <code>-D</code> compile line options in your downstream application build as Boost's builds do when they build the Boost Regex library. The documentation does not state that AFAICT (as of 2010-03-23).</p> <p>The details: Things I found quite helpful debugging this problem were:</p> <ol> <li><p>Use the <code>-d+2</code> option to <code>bjam</code> when building. This dumps out a huge amount of logging about exactly what command-line options are being used. That was how I determined that <code>-DBOOST_ALL_NO_LIB=1</code> and <code>-DBOOST_REGEX_DYN_LINK=1</code> were being specified on the <code>cl.exe</code> compile line when building the Boost Regex library.</p></li> <li><p>Realize that you have to also supply the <em>same</em> special <code>-D</code> flags (use either <code>-D</code> or <code>/D</code> options which VS2005 accepts as the same thing) when you compile the <code>.cpp</code> files in the app that uses that Boost library (true for Boost Regex, and I am guessing it is true for others, which I have not confirmed). That is why you will see a linker failure of: <code>LINK : fatal error LNK1104: cannot open file 'libboost_regex-vc80-mt-gd-1_42.lib'</code>, since without the <code>-DBOOST_ALL_NO_LIB=1</code> and <code>-DBOOST_REGEX_DYN_LINK=1</code> options, the auto-linking will kick in when the compiler parses <em>your</em> <code>.cpp</code> file and <code>#include</code>'s the Boost header, the latter of which <code>#include</code>'s the auto-linking headers, the latter of which by default uses the auto-linking logic which are compiler pragmas that tell the linker which library to use. And guess which ones that auto-linking logic chooses by default? Answer: The <em>static</em> ones that are of the form <code>libblablabla.lib</code> and not <code>blablabla.lib</code> which are the import libraries you expect. This pragma-based linker directive logic is what had me chasing my tail for 3 hours trying to figure out what I did wrong on my linker line, when it is under C-preprocessor control in the auto-linking logic that did it.</p></li> </ol>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload