[gentoo-user] custom boost in /usr/local = problem with libkolabxml, libixion

[gentoo-user] custom boost in /usr/local = problem with libkolabxml, libixion

[Kacper Kopczyński]

[-- Attachment #1: Type: text/plain, Size: 3772 bytes --]

Hello list,

I've installed newest boost into /usr/local - it's a custom installation and not via emerge/portage.

Today, after upgrading system, I've found that I need to use

emerge --update --newuse --deep --with-bdeps=y @world

to rebuild some dependencies.

In the process of recompiling I first noticed this strange thing:
checking for Boost headers version >= 1.36.0... yes
checking for Boost's header version... 1_55

Portage installed boost is 1.52, my custom installed one is 1.55.

Then after a few seconds I saw this:
x86_64-pc-linux-gnu-g++ -DPACKAGE_NAME=\"libixion\" -DPACKAGE_TARNAME=\"libixion\" -
DPACKAGE_VERSION=\"0.5.0\" -DPACKAGE_STRING=\"libixion\ 0.5.0\" -DPACKAGE_BUGREPORT=\"\" 
-DPACKAGE_URL=\"\" -DPACKAGE=\"libixion\" -DVERSION=\"0.5.0\" -DSTDC_HEADERS=1 -
DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -
DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -
DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_STDLIB_H=1 -
DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -
DHAVE_GETTIMEOFDAY=1 -DHAVE_BOOST=1 -DHAVE_BOOST_UNORDERED_MAP_HPP=1 -
DHAVE_MDDS_RECTANGLE_SET_HPP=1 -DHAVE_MDDS_MIXED_TYPE_MATRIX_HPP=1 -
DHAVE_MDDS_MULTI_TYPE_VECTOR_TRAIT_HPP=1 -DHAVE_BOOST_SYSTEM_ERROR_CODE_HPP=1 -
DHAVE_BOOST_THREAD_HPP=1 -DHAVE_BOOST_PROGRAM_OPTIONS_HPP=1 -I. -I../include -
I../lib/libixion/libixion.la -D_REENTRANT -DMDDS_HASH_CONTAINER_BOOST -
D__IXION_BUILDING_DLL -g -Os -fvisibility=hidden  -O2 -pipe -march=native -c -o ixion_sorter-
sort_input_parser.o `test -f 'sort_input_parser.cpp' || echo './'`sort_input_parser.cpp
/bin/sh ../libtool --tag=CXX   --mode=link x86_64-pc-linux-gnu-g++  -O2 -pipe -march=native  -Wl,-
O1 -Wl,--as-needed -o ixion-parser ixion_parser-ixion_parser.o ixion_parser-model_parser.o 
libixion/libixion-0.6.la -lboost_thread-mt -lboost_system-mt -pthread -lboost_program_options-mt 
libtool: link: x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -Wl,-O1 -Wl,--as-needed -o 
.libs/ixion-parser ixion_parser-ixion_parser.o ixion_parser-model_parser.o -pthread  
libixion/.libs/libixion-0.6.so -lboost_thread-mt -lboost_system-mt -lboost_program_options-mt -
pthread
libixion/.libs/libixion-0.6.so: undefined reference to `boost::thread::start_thread_noexcept()'
libixion/.libs/libixion-0.6.so: undefined reference to `boost::thread::join_noexcept()'
collect2: error: ld returned 1 exit status
make[2]: *** [ixion-parser] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/var/tmp/portage/dev-libs/libixion-0.5.0/work/libixion-0.5.0/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/dev-libs/libixion-0.5.0/work/libixion-0.5.0/src'
make: *** [all-recursive] Error 1
 * ERROR: dev-libs/libixion-0.5.0::gentoo failed (compile phase):


...so it failed because it tried to use my custom boost... I think.

To be sure that this is because of this I moved /usr/local/lib and /usr/local/include to /root and 
another compilation of this library went fine.
After doing so I runned revdep-rebuild and it had to recompile libkolabxml because it was linked to 
boost in /usr/local/lib.

So here is my question:
If libreoffice does need boost to compile, and I compiled libreoffice after I installed boost to 
/usr/local, then why it was able to use correct version of boost (from /usr not /usr/local)?

Libreoffice is just an example - there are many other programs that depend on boost, and the 
boost.thread library is very popular one.

libkolabxml at version 1.0.1
libixion at version 0.5.0

Should I create a bug for these two libraries or this is expected behaviour?

-- 
Kacper Kopczyński

[-- Attachment #2: Type: text/html, Size: 11212 bytes --]

Re: [gentoo-user] custom boost in /usr/local = problem with libkolabxml, libixion

[Nikita Tropin]

[-- Attachment #1: Type: text/plain, Size: 4416 bytes --]

Hi!
Suppose, this is because different programs and libs by default use
different installation paths. And libixion uses /usr/local by default as I
can understand by it's configure script. I think this is depends on
developer of each particular lib/prog.
Best regards.


On Sat, Mar 1, 2014 at 1:23 PM, Kacper Kopczyński <capsel@v-matrix.org>wrote:

>  Hello list,
>
>
>
> I've installed newest boost into /usr/local - it's a custom installation
> and not via emerge/portage.
>
>
>
> Today, after upgrading system, I've found that I need to use
>
>
>
> emerge --update --newuse --deep --with-bdeps=y @world
>
>
>
> to rebuild some dependencies.
>
>
>
> In the process of recompiling I first noticed this strange thing:
>
> checking for Boost headers version >= 1.36.0... yes
>
> checking for Boost's header version... 1_55
>
>
>
> Portage installed boost is 1.52, my custom installed one is 1.55.
>
>
>
> Then after a few seconds I saw this:
>
> x86_64-pc-linux-gnu-g++ -DPACKAGE_NAME=\"libixion\"
> -DPACKAGE_TARNAME=\"libixion\" -DPACKAGE_VERSION=\"0.5.0\"
> -DPACKAGE_STRING=\"libixion\ 0.5.0\" -DPACKAGE_BUGREPORT=\"\"
> -DPACKAGE_URL=\"\" -DPACKAGE=\"libixion\" -DVERSION=\"0.5.0\"
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
> -DHAVE_STDLIB_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE__BOOL=1
> -DHAVE_STDBOOL_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BOOST=1
> -DHAVE_BOOST_UNORDERED_MAP_HPP=1 -DHAVE_MDDS_RECTANGLE_SET_HPP=1
> -DHAVE_MDDS_MIXED_TYPE_MATRIX_HPP=1
> -DHAVE_MDDS_MULTI_TYPE_VECTOR_TRAIT_HPP=1
> -DHAVE_BOOST_SYSTEM_ERROR_CODE_HPP=1 -DHAVE_BOOST_THREAD_HPP=1
> -DHAVE_BOOST_PROGRAM_OPTIONS_HPP=1 -I. -I../include -I../lib/libixion/
> libixion.la -D_REENTRANT -DMDDS_HASH_CONTAINER_BOOST
> -D__IXION_BUILDING_DLL -g -Os -fvisibility=hidden -O2 -pipe -march=native
> -c -o ixion_sorter-sort_input_parser.o `test -f 'sort_input_parser.cpp' ||
> echo './'`sort_input_parser.cpp
>
> /bin/sh ../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -O2 -pipe
> -march=native -Wl,-O1 -Wl,--as-needed -o ixion-parser
> ixion_parser-ixion_parser.o ixion_parser-model_parser.o libixion/
> libixion-0.6.la -lboost_thread-mt -lboost_system-mt -pthread
> -lboost_program_options-mt
>
> libtool: link: x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -Wl,-O1
> -Wl,--as-needed -o .libs/ixion-parser ixion_parser-ixion_parser.o
> ixion_parser-model_parser.o -pthread libixion/.libs/libixion-0.6.so-lboost_thread-mt -lboost_system-mt -lboost_program_options-mt -pthread
>
> libixion/.libs/libixion-0.6.so: undefined reference to
> `boost::thread::start_thread_noexcept()'
>
> libixion/.libs/libixion-0.6.so: undefined reference to
> `boost::thread::join_noexcept()'
>
> collect2: error: ld returned 1 exit status
>
> make[2]: *** [ixion-parser] Error 1
>
> make[2]: *** Waiting for unfinished jobs....
>
> make[2]: Leaving directory
> `/var/tmp/portage/dev-libs/libixion-0.5.0/work/libixion-0.5.0/src'
>
> make[1]: *** [all-recursive] Error 1
>
> make[1]: Leaving directory
> `/var/tmp/portage/dev-libs/libixion-0.5.0/work/libixion-0.5.0/src'
>
> make: *** [all-recursive] Error 1
>
> * ERROR: dev-libs/libixion-0.5.0::gentoo failed (compile phase):
>
>
>
>
>
> ...so it failed because it tried to use my custom boost... I think.
>
>
>
> To be sure that this is because of this I moved /usr/local/lib and
> /usr/local/include to /root and another compilation of this library went
> fine.
>
> After doing so I runned revdep-rebuild and it had to recompile libkolabxml
> because it was linked to boost in /usr/local/lib.
>
>
>
> So here is my question:
>
> If libreoffice does need boost to compile, and I compiled libreoffice
> after I installed boost to /usr/local, then why it was able to use correct
> version of boost (from /usr not /usr/local)?
>
>
>
> Libreoffice is just an example - there are many other programs that depend
> on boost, and the boost.thread library is very popular one.
>
>
>
> libkolabxml at version 1.0.1
>
> libixion at version 0.5.0
>
>
>
> Should I create a bug for these two libraries or this is expected
> behaviour?
>
>
>
> --
>
> Kacper Kopczyński
>

[-- Attachment #2: Type: text/html, Size: 9717 bytes --]

Re: [gentoo-user] custom boost in /usr/local = problem with libkolabxml, libixion

[Samuli Suominen]

On 01/03/14 13:23, Kacper Kopczyński wrote:
>
> Hello list,
>
>  
>
> I've installed newest boost into /usr/local - it's a custom
> installation and not via emerge/portage.
>
>  
>
> Today, after upgrading system, I've found that I need to use
>
>  
>
> emerge --update --newuse --deep --with-bdeps=y @world
>
>  
>
> to rebuild some dependencies.
>
>  
>
> In the process of recompiling I first noticed this strange thing:
>
> checking for Boost headers version >= 1.36.0... yes
>
> checking for Boost's header version... 1_55
>
>  
>
> Portage installed boost is 1.52, my custom installed one is 1.55.
>
>  
>
> Then after a few seconds I saw this:
>
> x86_64-pc-linux-gnu-g++ -DPACKAGE_NAME=\"libixion\"
> -DPACKAGE_TARNAME=\"libixion\" -DPACKAGE_VERSION=\"0.5.0\"
> -DPACKAGE_STRING=\"libixion\ 0.5.0\" -DPACKAGE_BUGREPORT=\"\"
> -DPACKAGE_URL=\"\" -DPACKAGE=\"libixion\" -DVERSION=\"0.5.0\"
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
> -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
> -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
> -DHAVE_STDLIB_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE__BOOL=1
> -DHAVE_STDBOOL_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BOOST=1
> -DHAVE_BOOST_UNORDERED_MAP_HPP=1 -DHAVE_MDDS_RECTANGLE_SET_HPP=1
> -DHAVE_MDDS_MIXED_TYPE_MATRIX_HPP=1
> -DHAVE_MDDS_MULTI_TYPE_VECTOR_TRAIT_HPP=1
> -DHAVE_BOOST_SYSTEM_ERROR_CODE_HPP=1 -DHAVE_BOOST_THREAD_HPP=1
> -DHAVE_BOOST_PROGRAM_OPTIONS_HPP=1 -I. -I../include
> -I../lib/libixion/libixion.la -D_REENTRANT -DMDDS_HASH_CONTAINER_BOOST
> -D__IXION_BUILDING_DLL -g -Os -fvisibility=hidden -O2 -pipe
> -march=native -c -o ixion_sorter-sort_input_parser.o `test -f
> 'sort_input_parser.cpp' || echo './'`sort_input_parser.cpp
>
> /bin/sh ../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -O2
> -pipe -march=native -Wl,-O1 -Wl,--as-needed -o ixion-parser
> ixion_parser-ixion_parser.o ixion_parser-model_parser.o
> libixion/libixion-0.6.la -lboost_thread-mt -lboost_system-mt -pthread
> -lboost_program_options-mt
>
> libtool: link: x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -Wl,-O1
> -Wl,--as-needed -o .libs/ixion-parser ixion_parser-ixion_parser.o
> ixion_parser-model_parser.o -pthread libixion/.libs/libixion-0.6.so
> -lboost_thread-mt -lboost_system-mt -lboost_program_options-mt -pthread
>
> libixion/.libs/libixion-0.6.so: undefined reference to
> `boost::thread::start_thread_noexcept()'
>
> libixion/.libs/libixion-0.6.so: undefined reference to
> `boost::thread::join_noexcept()'
>
> collect2: error: ld returned 1 exit status
>
> make[2]: *** [ixion-parser] Error 1
>
> make[2]: *** Waiting for unfinished jobs....
>
> make[2]: Leaving directory
> `/var/tmp/portage/dev-libs/libixion-0.5.0/work/libixion-0.5.0/src'
>
> make[1]: *** [all-recursive] Error 1
>
> make[1]: Leaving directory
> `/var/tmp/portage/dev-libs/libixion-0.5.0/work/libixion-0.5.0/src'
>
> make: *** [all-recursive] Error 1
>
> * ERROR: dev-libs/libixion-0.5.0::gentoo failed (compile phase):
>
>  
>
>  
>
> ...so it failed because it tried to use my custom boost... I think.
>
>  
>
> To be sure that this is because of this I moved /usr/local/lib and
> /usr/local/include to /root and another compilation of this library
> went fine.
>
> After doing so I runned revdep-rebuild and it had to recompile
> libkolabxml because it was linked to boost in /usr/local/lib.
>
>  
>
> So here is my question:
>
> If libreoffice does need boost to compile, and I compiled libreoffice
> after I installed boost to /usr/local, then why it was able to use
> correct version of boost (from /usr not /usr/local)?
>
>  
>
> Libreoffice is just an example - there are many other programs that
> depend on boost, and the boost.thread library is very popular one.
>
>  
>
> libkolabxml at version 1.0.1
>
> libixion at version 0.5.0
>
>  
>
> Should I create a bug for these two libraries or this is expected
> behaviour?
>
>  
>
> -- 
>
> Kacper Kopczyński
>

There are multiple factors in play, some per package ./configure scripts
add -I/usr/local/include so that headers are picked up from there by
default,
if compiler alone doesn't have that in it's default search path already.
There are -L/usr/local/lib added by some, and /usr/local/lib in
/etc/ld.so.conf

What I'm really trying to say is that you can't install boost safely
into /usr/local/lib and include, but you should put it in it's own
directory outside of
compilers or ld.so's scope, like for example, /home/username/boost, and
then when you want something to use it, point the package to search it
from there
using package specific configure flags and environment variables like
LD_LIBRARY_PATH, PKG_CONFIG_PATH, and so forth

Bottom line is, It's not a bug you can file to Gentoo's bugzilla, it is
expected behavior

Re: [gentoo-user] custom boost in /usr/local = problem with libkolabxml, libixion

[Kacper Kopczyński]

[-- Attachment #1: Type: text/plain, Size: 5367 bytes --]

Dnia sobota, 1 marca 2014 14:57:23 Samuli Suominen pisze:
> On 01/03/14 13:23, Kacper Kopczyński wrote:
> > Hello list,
> > 
> > 
> > 
> > I've installed newest boost into /usr/local - it's a custom
> > installation and not via emerge/portage.
> > 
> > 
> > 
> > Today, after upgrading system, I've found that I need to use
> > 
> > 
> > 
> > emerge --update --newuse --deep --with-bdeps=y @world
> > 
> > 
> > 
> > to rebuild some dependencies.
> > 
> > 
> > 
> > In the process of recompiling I first noticed this strange thing:
> > 
> > checking for Boost headers version >= 1.36.0... yes
> > 
> > checking for Boost's header version... 1_55
> > 
> > 
> > 
> > Portage installed boost is 1.52, my custom installed one is 1.55.
> > 
> > 
> > 
> > Then after a few seconds I saw this:
> > 
> > x86_64-pc-linux-gnu-g++ -DPACKAGE_NAME=\"libixion\"
> > -DPACKAGE_TARNAME=\"libixion\" -DPACKAGE_VERSION=\"0.5.0\"
> > -DPACKAGE_STRING=\"libixion\ 0.5.0\" -DPACKAGE_BUGREPORT=\"\"
> > -DPACKAGE_URL=\"\" -DPACKAGE=\"libixion\" -DVERSION=\"0.5.0\"
> > -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
> > -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
> > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
> > -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
> > -DHAVE_STDLIB_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE__BOOL=1
> > -DHAVE_STDBOOL_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BOOST=1
> > -DHAVE_BOOST_UNORDERED_MAP_HPP=1 -DHAVE_MDDS_RECTANGLE_SET_HPP=1
> > -DHAVE_MDDS_MIXED_TYPE_MATRIX_HPP=1
> > -DHAVE_MDDS_MULTI_TYPE_VECTOR_TRAIT_HPP=1
> > -DHAVE_BOOST_SYSTEM_ERROR_CODE_HPP=1 -DHAVE_BOOST_THREAD_HPP=1
> > -DHAVE_BOOST_PROGRAM_OPTIONS_HPP=1 -I. -I../include
> > -I../lib/libixion/libixion.la -D_REENTRANT -DMDDS_HASH_CONTAINER_BOOST
> > -D__IXION_BUILDING_DLL -g -Os -fvisibility=hidden -O2 -pipe
> > -march=native -c -o ixion_sorter-sort_input_parser.o `test -f
> > 'sort_input_parser.cpp' || echo './'`sort_input_parser.cpp
> > 
> > /bin/sh ../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -O2
> > -pipe -march=native -Wl,-O1 -Wl,--as-needed -o ixion-parser
> > ixion_parser-ixion_parser.o ixion_parser-model_parser.o
> > libixion/libixion-0.6.la -lboost_thread-mt -lboost_system-mt -pthread
> > -lboost_program_options-mt
> > 
> > libtool: link: x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -Wl,-O1
> > -Wl,--as-needed -o .libs/ixion-parser ixion_parser-ixion_parser.o
> > ixion_parser-model_parser.o -pthread libixion/.libs/libixion-0.6.so
> > -lboost_thread-mt -lboost_system-mt -lboost_program_options-mt -pthread
> > 
> > libixion/.libs/libixion-0.6.so: undefined reference to
> > `boost::thread::start_thread_noexcept()'
> > 
> > libixion/.libs/libixion-0.6.so: undefined reference to
> > `boost::thread::join_noexcept()'
> > 
> > collect2: error: ld returned 1 exit status
> > 
> > make[2]: *** [ixion-parser] Error 1
> > 
> > make[2]: *** Waiting for unfinished jobs....
> > 
> > make[2]: Leaving directory
> > `/var/tmp/portage/dev-libs/libixion-0.5.0/work/libixion-0.5.0/src'
> > 
> > make[1]: *** [all-recursive] Error 1
> > 
> > make[1]: Leaving directory
> > `/var/tmp/portage/dev-libs/libixion-0.5.0/work/libixion-0.5.0/src'
> > 
> > make: *** [all-recursive] Error 1
> > 
> > * ERROR: dev-libs/libixion-0.5.0::gentoo failed (compile phase):
> > 
> > 
> > 
> > 
> > 
> > ...so it failed because it tried to use my custom boost... I think.
> > 
> > 
> > 
> > To be sure that this is because of this I moved /usr/local/lib and
> > /usr/local/include to /root and another compilation of this library
> > went fine.
> > 
> > After doing so I runned revdep-rebuild and it had to recompile
> > libkolabxml because it was linked to boost in /usr/local/lib.
> > 
> > 
> > 
> > So here is my question:
> > 
> > If libreoffice does need boost to compile, and I compiled libreoffice
> > after I installed boost to /usr/local, then why it was able to use
> > correct version of boost (from /usr not /usr/local)?
> > 
> > 
> > 
> > Libreoffice is just an example - there are many other programs that
> > depend on boost, and the boost.thread library is very popular one.
> > 
> > 
> > 
> > libkolabxml at version 1.0.1
> > 
> > libixion at version 0.5.0
> > 
> > 
> > 
> > Should I create a bug for these two libraries or this is expected
> > behaviour?
> > 
> > 
> > 
> > 
> > Kacper Kopczyński
> 
> There are multiple factors in play, some per package ./configure scripts
> add -I/usr/local/include so that headers are picked up from there by
> default,
> if compiler alone doesn't have that in it's default search path already.
> There are -L/usr/local/lib added by some, and /usr/local/lib in
> /etc/ld.so.conf
> 
> What I'm really trying to say is that you can't install boost safely
> into /usr/local/lib and include, but you should put it in it's own
> directory outside of
> compilers or ld.so's scope, like for example, /home/username/boost, and
> then when you want something to use it, point the package to search it
> from there
> using package specific configure flags and environment variables like
> LD_LIBRARY_PATH, PKG_CONFIG_PATH, and so forth
> 
> Bottom line is, It's not a bug you can file to Gentoo's bugzilla, it is
> expected behavior

[-- Attachment #2: Type: text/html, Size: 29662 bytes --]