similar to: [LLVMdev] Recent Libtool Changes

Dear Nick, We've figured out what is going on with your "Hello World" pass and have implemented a temporary solution. Basically, our build rules in Makefile.common built shared objects with the Solaris linker (via libtool). While it built the shared library, the library did not call C++ constructors of global variables. This, in turn, caused the pass registration to fail.

Yep, it sounds like a good solution, and it works for me - thanks! -mike On Mon, 10 Jan 2005 20:40:34 -0800, Reid Spencer <reid at x10sys.com> wrote: > Michael, > > I've implemented a LOADABLE_MODULE feature in the makefiles: > > http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050110/023147.html > > The approach taken is almost what you described

Hi John, Please see below, too >From: John Criswell <criswell at cs.uiuc.edu> >Date: Tue, 27 Jul 2004 14:57:02 -0500 > >Henrik Bach wrote: >>Hi, > >Please see below. > >> >>I get this error: >>------------------ >>ToolRunner.cpp:396: error: `SHLIBEXT' undeclared (first use this function) >>ToolRunner.cpp:396: error: (Each

Michael, I've implemented a LOADABLE_MODULE feature in the makefiles: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050110/023147.html The approach taken is almost what you described below. However, I want to retain the distinction between a "regular" shared library and one that can be dlopened. So, if you specify SHARED_LIBRARY=1 you get a regular shared library

The short: Linking to libspeex.a when generating a .so using libtool results in a non-portability warning. This is due to PIC code and non-PIC code intermingling. How can I go about fixing this whilst still using an installed libspeex present on the user's system? The long: I am using autoconf + libtool to generate a codec plugin for speex (sipXmediaLib), and I'm trying to eliminate

Solved. Short version: You don't need to change DynamicLinker.cpp at all. dlopen() should just work, except that the defaults for libtool are to produce the wrong kind of shared object. On OS X, libtool needs to be passed the -module option to create dlopen-able objects: % diff Makefile.rules.old Makefile.rules 326c326 < Link := $(LIBTOOL) --mode=link $(CXX) --- > Link

I've encountered a new problem building gluster-2.0.1 that I did not have with gluster-2.0.0rc8. This is on a mandriva-2008.1-x86_64 system. ../../libtool: line 466: CDPATH: command not found ../../libtool: line 1144: func_opt_split: command not found 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 an older

I'm forwarding this bug resolution because it has a pretty wide impact on LLVM developers. This bug (451) has been resolved (well, works for me anyway). If you have reconfigured your build tree since October 4th, you need to reconfigure again. The bug produced shared objects that don't have a .so extension. Reconfiguring will fix this problem. The notes below show what was needed to

I'm trying to build an executable for a program I wrote. The compilation steps go well, but the linking step fails with a libtool "version mismatch" error. My linking command has this prefix: /path/to/R/bin/R CMD LINK gcc -g -std=gnu99 ... etc. The error looks like this: libtool: Version mismatch error. This is libtool 2.2, but the libtool: definition of this LT_INIT comes from

I don't know if this is the right solution, but you can use -I with aclocal to point right at .m4 files: aclocal -I <libtool directory>/share/aclocal --- Brady Patterson <brady@spaceship.com> wrote: > > Hi. > > I want to add some code to flac and am having trouble building it out > of cvs. > I've had several problems, most of which were pretty easy to work

Hi. I want to add some code to flac and am having trouble building it out of cvs. I've had several problems, most of which were pretty easy to work around or had already been discussed here. But this one has me stumped (though I am admittedly new to autoconf, automake, and libtool). Here's the problem. autoconf does not see any definition for AC_PROG_LIBTOOL. There is such a

Hi, looking on the build scripts, I noticed on configure.ac ## <FIXME> ## Completely disable using libtool for building shlibs until libtool ## fully supports Fortran and C++. ## AC_ARG_WITH([libtool], ## [AS_HELP_STRING([--with-libtool],[use libtool for building shared libraries @ <:@yes@:>@])], ## [use_libtool="${withval}"], ## [use_libtool=yes]) ##

We're planning to contribute an LLVM version of Apple's libtool utility. To quote its man page, "Libtool with -static is intended to replace ar(5) and ranlib". In other words, libtool is the preferred tool to create archives for Apple platforms, and it also has good defaults for that platform (e.g. automatically creating a table of contents with the right format). It provides a

CentOS Errata and Security Advisory CESA-2009:1646 libtool security update for CentOS 3 x86_64: https://rhn.redhat.com/errata/RHSA-2009-1646.html The following updated file has been uploaded and is currently syncing to the mirrors: x86_64: updates/x86_64/RPMS/libtool-1.4.3-7.x86_64.rpm updates/x86_64/RPMS/libtool-libs-1.4.3-7.i386.rpm updates/x86_64/RPMS/libtool-libs-1.4.3-7.x86_64.rpm source:

CentOS Errata and Security Advisory CESA-2009:1646 libtool security update for CentOS 4 x86_64: https://rhn.redhat.com/errata/RHSA-2009-1646.html The following updated file has been uploaded and is currently syncing to the mirrors: x86_64: updates/x86_64/RPMS/libtool-1.5.6-5.el4_8.x86_64.rpm updates/x86_64/RPMS/libtool-libs-1.5.6-5.el4_8.i386.rpm

CentOS Errata and Bugfix Advisory 2016:0202 Upstream details at : https://rhn.redhat.com/errata/RHBA-2016-0202.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 06bf1abdca762654c9637cfe682968f9fa2ba0cf0bffe64759ae51e78ba57afe libtool-2.4.2-21.el7_2.x86_64.rpm

CentOS Errata and Bugfix Advisory 2017:0910 Upstream details at : https://rhn.redhat.com/errata/RHBA-2017-0910.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 6d7cace54f42b84d4cedeab9cc464a2dd97d8b448f463818dc1d3e36d754844f libtool-2.4.2-22.el7_3.x86_64.rpm

Hello all, I have spent the last week going through the configure/configure.ac file, basically line-by-line. I am finding things related to AIX that have not been working well (i.e., cleanly) for 32-bit builds and are a "root-cause" for 64-bit builds to finish cleanly. Trying to keep this short - you can also just skip to end to see my question! With regard to AIX, there is a lot

Hi all, Has there been any progress with libtools DTrace USDT support http://www.mail-archive.com/libtool at gnu.org/msg10587.html thanks ----- Original Message ----- >From Charles Koester <charles.koester at oracle.com> Date Mon, 23 Nov 2009 17:01:17 -0800 To Marina Fisher <marina.fisher at sun.com> Subject DTrace & libtool "best practices" Greetings,

I'm not sure if this is related to me updating to gcc 4.6.0 or not, but in the gnulib/lib directory I get an error which comes down to the following libtool command running: $ ../../libtool --tag=CC --mode=compile gcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -g -O2 -MT c-ctype.lo -MD -MP -MF .deps/c-ctype.Tpo -c -o c-ctype.lo c-ctype.c ../../libtool: line 2075: c-ctype.c: command not