/docs/MyDocs

To get this branch, use:
bzr branch http://darksoft.org/webbzr/docs/MyDocs

« back to all changes in this revision

Viewing changes to SCM/packaging/general/linking/linking.txt

  • Committer: Suren A. Chilingaryan
  • Date: 2017-04-03 02:45:17 UTC
  • Revision ID: csa@suren.me-20170403024517-dwzj0z0k1cmhxm7u
Restructuring, OpenShift, Ansible, Git

Show diffs side-by-side

added added

removed removed

Lines of Context:
SCM/packaging/general/linking/linking.txt
 
1
 - Pure C libraries can cause g++ version incompabilities in C++ applications
 
2
 if linked using libtool. The following is hapening: libtool is looking for 
 
3
 .la file of C library and finds it's dependencies from there. But the 
 
4
 dependencies in .la files are summed (the dependencies of some library .la 
 
5
 file is just summed up dependencies from .la files from all librariries it
 
6
 is linked with). So, if some library is written in C++ but provides C 
 
7
 interface, it could force inclusion of libstdc++. So, if this library 
 
8
 is compiled with gcc3 the libstc++ from gcc3 will be included into the 
 
9
 link list and gcc4 will use it instead of default. And lot of problems
 
10
 will come!
 
11
 Example: Sometimes aspell is linked with libstdc++, it is linked with LibRCC,
 
12
 so any application linking librcc will depend on gcc3 forced by libstdc++.
 
13
 
 
14
 
 
15
 - The following error:
 
16
  /bin/rm: cannot remove libtoolT: No such file or directory 
 
17
 
 
18
 It is due to both the Libtool macros and the configure.in
 
19
 defining $RM, and configure.in uses
 
20
  AC_PATH_PROG(RM, rm, $FALSE)
 
21
 whereas the Libtool macros expect "rm -f".  
 
22
 One fix could be to:
 
23
  AC_PATH_PROG(RM, rm, $FALSE)
 
24
  RM="$RM -f"
 
25