[Boost-users] statically linked boost libs with VS2010 missing ?

[tre...@nurotek.com.au]

Hi all,

I'm new to boost, and I'm trying to compile a windows console app
statically so the end user doesn't need vcredist.

I've changed my code generation options to use /mt (static
multithreaded) instead of dynamic multithreaded, but the linker cannot
find any libs with libboost*-sgd*.lib (ie.any static boost libs), and
they certainly don't exist on my computer. I've performed a --clean-all
and recompiled boost using "b2 link=static", but the libs are still
missing, even though the compile seems to work fine - and the generated
libs are actually following the dynamic naming convention, not the
static convention.

Is this some MSVC toolchain issue ? Is there another option I need to
be using for this toolchain ?

thanks
Trevor.


_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[tre...@nurotek.com.au]

OIC said the blind man.....solved.

OK, so I thought that all that was required was "link=static", but I
was neglecting "runtime-link=static". I suppose a "complete" build
would've solved my problem too.


carry on.

[Lars Viklund]

On Wed, Aug 08, 2012 at 10:21:41AM +1000, tre...@nurotek.com.au wrote:
> Hi all,
>
> I'm new to boost, and I'm trying to compile a windows console app
> statically so the end user doesn't need vcredist.
>
> I've changed my code generation options to use /mt (static
> multithreaded) instead of dynamic multithreaded, but the linker cannot
> find any libs with libboost*-sgd*.lib (ie.any static boost libs), and
> they certainly don't exist on my computer. I've performed a --clean-all
> and recompiled boost using "b2 link=static", but the libs are still
> missing, even though the compile seems to work fine - and the generated
> libs are actually following the dynamic naming convention, not the
> static convention.
>
> Is this some MSVC toolchain issue ? Is there another option I need to be
> using for this toolchain ?

link=static makes static-linked Boost libraries (lib- prefix)

runtime-link=static makes libraries linked against
the static runtime (-s-).

Your use case probably wants both static link and runtime-link, as
dynamic linking a Boost that uses a static runtime is pretty much always
a bad thing.

--
Lars Viklund | z...@acc.umu.se

[tre...@nurotek.com.au]

Thanks Lars,
looks like I just realised at the same time you sent this through, and
thanks for the clarification!

[Armin Pies]

You might try
b2 link=static runtime-link=static

Regards

Armin

-----Ursprüngliche Nachricht-----
Von: boost-use...@lists.boost.org [mailto:boost-use...@lists.boost.org] Im Auftrag von tre...@nurotek.com.au
Gesendet: Mittwoch, 8. August 2012 02:22
An: boost...@lists.boost.org
Betreff: [Boost-users] statically linked boost libs with VS2010 missing ?

[Robert Ramey]

Lars Viklund wrote:
> On Wed, Aug 08, 2012 at 10:21:41AM +1000, tre...@nurotek.com.au wrote:

>> Is this some MSVC toolchain issue ? Is there another option I need
>> to be using for this toolchain ?
>
> link=static makes static-linked Boost libraries (lib- prefix)
>
> runtime-link=static makes libraries linked against
> the static runtime (-s-).
>
> Your use case probably wants both static link and runtime-link, as
> dynamic linking a Boost that uses a static runtime is pretty much
> always a bad thing.

This requires a little more clarification somewhere.

It's true that creating a DLL which uses static linking can
cause problems and avoiding doing this will avoid them.
But, sometimes it's necessary. It's not clear what the rules
are that would permit one to do this without problems.

Robert Ramey

[Lemay.Steve]

Here's what I trying below (as a first time Boost advocate). I need Boost 1.50 libraries for use with VS2010/12 (Win64) and gcc 4.4.2/4.63 (QNX). I am trying to create static library with position independent code to be linked with executable and shared objects/libraries too. Am I heading the wrong direction? Any suggestions/criticisms?

(I'm having issues compiling MPI with qcc currently and why it is turned off in the build).

For MSVS:

bjam -a -q -j4 --prefix=%DRIVE%\boostVS2010 --build-type=minimal --build-dir=%DRIVE%\boostBuild_VS2010_%BOOSTVER% toolset=msvc --variant=release link=static threading=multi runtime-link=shared --without-python --without-mpi install >build.log 2>&1

For QCC:

bjam -a -q -j4 --prefix=%DRIVE%\boost --build-type=minimal --build-dir=%DRIVE%\boostBuild_QCC_%BOOSTVER% --layout=system toolset=qcc target-os=qnxnto threadapi=pthread --variant=release link=static threading=multi runtime-link=shared cxxflags="-DFD_SETSIZE=2048 -march=pentium3 -mtune=k8-sse3 -mmmx -msse -mfpmath=sse -mstackrealign -Wc,-fPIC,-std=c++0x,-std=gnu++0x" --without-python --without-mpi install >build.log 2>&1

Boost newbie,
SGL

[Lars Viklund]

On Wed, Aug 08, 2012 at 08:29:27AM -0800, Robert Ramey wrote:
> Lars Viklund wrote:
> > On Wed, Aug 08, 2012 at 10:21:41AM +1000, tre...@nurotek.com.au wrote:
>
> >> Is this some MSVC toolchain issue ? Is there another option I need
> >> to be using for this toolchain ?
> >
> > link=static makes static-linked Boost libraries (lib- prefix)
> >
> > runtime-link=static makes libraries linked against
> > the static runtime (-s-).
> >
> > Your use case probably wants both static link and runtime-link, as
> > dynamic linking a Boost that uses a static runtime is pretty much
> > always a bad thing.
>
> This requires a little more clarification somewhere.
>
> It's true that creating a DLL which uses static linking can
> cause problems and avoiding doing this will avoid them.
> But, sometimes it's necessary. It's not clear what the rules
> are that would permit one to do this without problems.
>
> Robert Ramey

The set of circumstances where this is valid is very narrow.

In essence, if you have a statically linked runtime, allocations and
deallocations must be done in the same module, you cannot pass standard
library types (both std::whatever<T> and things like FILE*) across the
module boundary.

In essence, unless you use something that is completely independent of
both allocation, I/O and standard library types, you're very likely to
blow up.

You pretty much need a proper plugin-style interface for anything like
that to remotely have a chance of succeeding. I don't see any part of
Boost designed to work like that.

--
Lars Viklund | z...@acc.umu.se