linker error boost with 1.69 and 1.70

From: Danny K (qdtk41_at_[hidden])
Date: 2019-05-20 16:16:34

So I have been using boost for awhile.  I compile boost the same way for
all the versions and have been since 1.48.  My platforms are CentOS 6 & 7
and Windows 10 vs2017.  My code has compiled on all 3 platforms with Boost
without a problem.    My current version is 1.66 and I wanted to upgrade to
1.69.  Under Windows, I build 1.69 with ZLIB & BZIP and my applications
have no problems.  I use zlib & bzip in the IOstreams library to read &
write compressed files. So I built 1.69 under Linux the same way as I
always have but I am now getting a linker error that I don't understand and
I am stuck.

The error starts with:
API_utiltyFunctions.cpp:(.text+0x154): undefined reference to
`boost::iostreams::detail::zlib_base::before(char const*&, char const*,
char*&, char*)'
API_utiltyFunctions.cpp:(.text+0x15b): undefined reference to
`boost::iostreams::zlib::sync_flush'
API_utiltyFunctions.cpp:(.text+0x165): undefined reference to
`boost::iostreams::detail::zlib_base::xinflate(int)'
API_utiltyFunctions.cpp:(.text+0x177): undefined reference to
`boost::iostreams::detail::zlib_base::after(char const*&, char*&, bool)'
API_utiltyFunctions.cpp:(.text+0x17e): undefined reference to
`boost::iostreams::zlib_error::check(int)'
API_utiltyFunctions.cpp:(.text+0x185): undefined reference to
`boost::iostreams::zlib::stream_end'

The boost portion of my linker line is:
        -L[ path to boost 1.69] \
        -lboost_random-1_69 \
        -lboost_program_options-1_69 \
        -lboost_date_time-1_69 \
        -lboost_chrono-1_69 \
        -lboost_regex-1_69 \
        -lboost_thread-1_69 \
        -lboost_exception-1_69 \
        -lboost_filesystem-1_69 \
        -lboost_system-1_69 \
        -lboost_iostreams-1_69 -lrt -lbz2 -lz -lm

Any help would be appreciate.  Weirdly if I revert back to boost 1.66, I
don't have a problem.

I also tested this compilation against boost 1.70 and I get the same
problem.

I do compile boost statically with shared runtime libraries and threads.

Respectfully,
Danny K