libtool

nginx+ftp搭建图片服务器修改nginx 配置文件中root路径403错误

给你一囗甜甜゛ 提交于 2019-11-30 11:27:52
关于参考《 nginx+ftp搭建图片服务器 》【https://my.oschina.net/iyinghui/blog/750459】遇到问题总结: 问题1: 在安装nginx的时候如果提示make命令不认识错误 解决方案: 先安装make命令: yum -y install gcc automake autoconf libtool make 问题2: 在修改了nginx默认路径的时候在访问nginx提示403错误。 文章具体位置: 解决方案: 在nginx配置文件最上面一行被注释掉的 如果没有修改最上面一行: 修改成root用户后,重新加载nginx配置文件。 OK。可以正常访问了 注:别使用root用户。最好给nginx创建一个单独的用户 来源: oschina 链接: https://my.oschina.net/u/930697/blog/791080

How can an autotools user specify a combination of static & dynamic linking?

牧云@^-^@ 提交于 2019-11-30 09:04:27
I'm building a program with autoconf, automake, and libtool. My work requires that I statically link (most) libraries. This hasn't been a problem in the past because I could statically link everything with -all-static . Now it's a problem because I have to use a library which is only dynamic; it was given to us by a thirdparty, and we don't have the source. Of course, -all-static now causes the build to fail. Is it possible to tell libtool to statically link everything, except for this one library? Is it possible to have libtool do any combination of static and dynamic linking, or is it all or

“Hidden symbol `atexit' is referenced by DSO” when using libtool with gcov

蹲街弑〆低调 提交于 2019-11-30 02:15:55
问题 I have a C++ project that uses the GNU Autotools for its build scripts and libtool for linking. Recently I have added code coverage instrumentation with gcov, by ensuring that GCOV_CFLAGS="-fprofile-arcs -ftest-coverage" GCOV_LDFLAGS="-fprofile-arcs -ftest-coverage" ..get included in my CFLAGS and LDFLAGS respectively. On OS X 10.7.4 using g++-4.2 (installed by homebrew), everything works fine. On Ubuntu 12.04 using g++ 4.6.3, libtool fails to link one of my tests: /bin/bash ./libtool --tag

installed libtool but libtoolize not found

做~自己de王妃 提交于 2019-11-29 20:26:15
im trying to build libxml2 from source on my mac. so i have autoconf libtool and automake installed using mac ports autoconf and automake seem to be working fine as expected. i try running autogen.sh first. libtoolize --version unfortunately gives -bash: libtoolize: command not found i try running (again) sudo port install libtool ---> Cleaning libtool ---> Scanning binaries for linking errors: 100.0% ---> No broken files found. i try locate libtool and it seems to be installed fine /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/libtool /Applications

installed libtool but libtoolize not found

☆樱花仙子☆ 提交于 2019-11-28 16:28:45
问题 im trying to build libxml2 from source on my mac. so i have autoconf libtool and automake installed using mac ports autoconf and automake seem to be working fine as expected. i try running autogen.sh first. libtoolize --version unfortunately gives -bash: libtoolize: command not found i try running (again) sudo port install libtool ---> Cleaning libtool ---> Scanning binaries for linking errors: 100.0% ---> No broken files found. i try locate libtool and it seems to be installed fine

libtool version mismatch error

久未见 提交于 2019-11-28 03:14:41
When building my application with kdevelop 3.5 on Ubuntu 10.04, I get the following errors: libtool: Version mismatch error. This is libtool 2.2.6 Debian-2.2.6a-4, but the libtool: definition of this LT_INIT comes from libtool 2.2.6b. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 Debian-2.2.6a-4 libtool: and run autoconf again. make[2]: *** [wktools4] Error 63 make[2]: Target `all' not remade because of errors. make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 *** Exited with status: 2 *** Where can I get the needed version of libtool, or how can I recreate

Autotools build fails due to subdir-objects option in AM_INIT_AUTOMAKE

☆樱花仙子☆ 提交于 2019-11-28 01:20:29
I'm currently working on a C++ project which relies on recursive automake for building. I want to build a shared library and the Makefile.am in the src directory of the library looks like # ... # Library name lib_LTLIBRARIES = libadapter-@MY_API_VERSION@.la # Sources libadapter_@MY_API_VERSION@_la_SOURCES = \ $(top_builddir)/src/sourceA.cpp \ $(top_builddir)/src/sourceB.cpp # ... Since version 1.14, automake issues a warning when the subdir-objects option is not specified in AM_INIT_AUTOMAKE in configure.ac . However, adding the subdir-objects option seems to break the build process with make

libtool version mismatch error

一笑奈何 提交于 2019-11-27 19:14:18
问题 When building my application with kdevelop 3.5 on Ubuntu 10.04, I get the following errors: libtool: Version mismatch error. This is libtool 2.2.6 Debian-2.2.6a-4, but the libtool: definition of this LT_INIT comes from libtool 2.2.6b. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6 Debian-2.2.6a-4 libtool: and run autoconf again. make[2]: *** [wktools4] Error 63 make[2]: Target `all' not remade because of errors. make[1]: *** [all-recursive] Error 1 make: *** [all]

What are libtool's .la file for?

旧城冷巷雨未停 提交于 2019-11-27 10:02:02
What are libtool's .la files for? How are they used with a shared object? Artyom It is a textual file that includes a description of the library. It allows libtool to create platform-independent names. For example, libfoo goes to: Under Linux: /lib/libfoo.so # Symlink to shared object /lib/libfoo.so.1 # Symlink to shared object /lib/libfoo.so.1.0.1 # Shared object /lib/libfoo.a # Static library /lib/libfoo.la # 'libtool' library Under Cygwin : /lib/libfoo.dll.a # Import library /lib/libfoo.a # Static library /lib/libfoo.la # libtool library /bin/cygfoo_1.dll # DLL Under Windows MinGW: /lib

Autotools build fails due to subdir-objects option in AM_INIT_AUTOMAKE

谁说胖子不能爱 提交于 2019-11-26 21:53:33
问题 I'm currently working on a C++ project which relies on recursive automake for building. I want to build a shared library and the Makefile.am in the src directory of the library looks like # ... # Library name lib_LTLIBRARIES = libadapter-@MY_API_VERSION@.la # Sources libadapter_@MY_API_VERSION@_la_SOURCES = \ $(top_builddir)/src/sourceA.cpp \ $(top_builddir)/src/sourceB.cpp # ... Since version 1.14, automake issues a warning when the subdir-objects option is not specified in AM_INIT_AUTOMAKE