1 |
Hi! |
2 |
Suppose, this is because different programs and libs by default use |
3 |
different installation paths. And libixion uses /usr/local by default as I |
4 |
can understand by it's configure script. I think this is depends on |
5 |
developer of each particular lib/prog. |
6 |
Best regards. |
7 |
|
8 |
|
9 |
On Sat, Mar 1, 2014 at 1:23 PM, Kacper Kopczyński <capsel@××××××××.org>wrote: |
10 |
|
11 |
> Hello list, |
12 |
> |
13 |
> |
14 |
> |
15 |
> I've installed newest boost into /usr/local - it's a custom installation |
16 |
> and not via emerge/portage. |
17 |
> |
18 |
> |
19 |
> |
20 |
> Today, after upgrading system, I've found that I need to use |
21 |
> |
22 |
> |
23 |
> |
24 |
> emerge --update --newuse --deep --with-bdeps=y @world |
25 |
> |
26 |
> |
27 |
> |
28 |
> to rebuild some dependencies. |
29 |
> |
30 |
> |
31 |
> |
32 |
> In the process of recompiling I first noticed this strange thing: |
33 |
> |
34 |
> checking for Boost headers version >= 1.36.0... yes |
35 |
> |
36 |
> checking for Boost's header version... 1_55 |
37 |
> |
38 |
> |
39 |
> |
40 |
> Portage installed boost is 1.52, my custom installed one is 1.55. |
41 |
> |
42 |
> |
43 |
> |
44 |
> Then after a few seconds I saw this: |
45 |
> |
46 |
> x86_64-pc-linux-gnu-g++ -DPACKAGE_NAME=\"libixion\" |
47 |
> -DPACKAGE_TARNAME=\"libixion\" -DPACKAGE_VERSION=\"0.5.0\" |
48 |
> -DPACKAGE_STRING=\"libixion\ 0.5.0\" -DPACKAGE_BUGREPORT=\"\" |
49 |
> -DPACKAGE_URL=\"\" -DPACKAGE=\"libixion\" -DVERSION=\"0.5.0\" |
50 |
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 |
51 |
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 |
52 |
> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" |
53 |
> -DHAVE_STDLIB_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE__BOOL=1 |
54 |
> -DHAVE_STDBOOL_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BOOST=1 |
55 |
> -DHAVE_BOOST_UNORDERED_MAP_HPP=1 -DHAVE_MDDS_RECTANGLE_SET_HPP=1 |
56 |
> -DHAVE_MDDS_MIXED_TYPE_MATRIX_HPP=1 |
57 |
> -DHAVE_MDDS_MULTI_TYPE_VECTOR_TRAIT_HPP=1 |
58 |
> -DHAVE_BOOST_SYSTEM_ERROR_CODE_HPP=1 -DHAVE_BOOST_THREAD_HPP=1 |
59 |
> -DHAVE_BOOST_PROGRAM_OPTIONS_HPP=1 -I. -I../include -I../lib/libixion/ |
60 |
> libixion.la -D_REENTRANT -DMDDS_HASH_CONTAINER_BOOST |
61 |
> -D__IXION_BUILDING_DLL -g -Os -fvisibility=hidden -O2 -pipe -march=native |
62 |
> -c -o ixion_sorter-sort_input_parser.o `test -f 'sort_input_parser.cpp' || |
63 |
> echo './'`sort_input_parser.cpp |
64 |
> |
65 |
> /bin/sh ../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -O2 -pipe |
66 |
> -march=native -Wl,-O1 -Wl,--as-needed -o ixion-parser |
67 |
> ixion_parser-ixion_parser.o ixion_parser-model_parser.o libixion/ |
68 |
> libixion-0.6.la -lboost_thread-mt -lboost_system-mt -pthread |
69 |
> -lboost_program_options-mt |
70 |
> |
71 |
> libtool: link: x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native -Wl,-O1 |
72 |
> -Wl,--as-needed -o .libs/ixion-parser ixion_parser-ixion_parser.o |
73 |
> ixion_parser-model_parser.o -pthread libixion/.libs/libixion-0.6.so-lboost_thread-mt -lboost_system-mt -lboost_program_options-mt -pthread |
74 |
> |
75 |
> libixion/.libs/libixion-0.6.so: undefined reference to |
76 |
> `boost::thread::start_thread_noexcept()' |
77 |
> |
78 |
> libixion/.libs/libixion-0.6.so: undefined reference to |
79 |
> `boost::thread::join_noexcept()' |
80 |
> |
81 |
> collect2: error: ld returned 1 exit status |
82 |
> |
83 |
> make[2]: *** [ixion-parser] Error 1 |
84 |
> |
85 |
> make[2]: *** Waiting for unfinished jobs.... |
86 |
> |
87 |
> make[2]: Leaving directory |
88 |
> `/var/tmp/portage/dev-libs/libixion-0.5.0/work/libixion-0.5.0/src' |
89 |
> |
90 |
> make[1]: *** [all-recursive] Error 1 |
91 |
> |
92 |
> make[1]: Leaving directory |
93 |
> `/var/tmp/portage/dev-libs/libixion-0.5.0/work/libixion-0.5.0/src' |
94 |
> |
95 |
> make: *** [all-recursive] Error 1 |
96 |
> |
97 |
> * ERROR: dev-libs/libixion-0.5.0::gentoo failed (compile phase): |
98 |
> |
99 |
> |
100 |
> |
101 |
> |
102 |
> |
103 |
> ...so it failed because it tried to use my custom boost... I think. |
104 |
> |
105 |
> |
106 |
> |
107 |
> To be sure that this is because of this I moved /usr/local/lib and |
108 |
> /usr/local/include to /root and another compilation of this library went |
109 |
> fine. |
110 |
> |
111 |
> After doing so I runned revdep-rebuild and it had to recompile libkolabxml |
112 |
> because it was linked to boost in /usr/local/lib. |
113 |
> |
114 |
> |
115 |
> |
116 |
> So here is my question: |
117 |
> |
118 |
> If libreoffice does need boost to compile, and I compiled libreoffice |
119 |
> after I installed boost to /usr/local, then why it was able to use correct |
120 |
> version of boost (from /usr not /usr/local)? |
121 |
> |
122 |
> |
123 |
> |
124 |
> Libreoffice is just an example - there are many other programs that depend |
125 |
> on boost, and the boost.thread library is very popular one. |
126 |
> |
127 |
> |
128 |
> |
129 |
> libkolabxml at version 1.0.1 |
130 |
> |
131 |
> libixion at version 0.5.0 |
132 |
> |
133 |
> |
134 |
> |
135 |
> Should I create a bug for these two libraries or this is expected |
136 |
> behaviour? |
137 |
> |
138 |
> |
139 |
> |
140 |
> -- |
141 |
> |
142 |
> Kacper Kopczyński |
143 |
> |