On Sun, Nov 28, 2010 at 12:39 PM, John R. Cary wrote:
> On 11/28/10 10:25 AM, Ralf Wildenhues wrote:
>>
>> Hello John,
>>
>> * John R. Cary wrote on Sun, Nov 28, 2010 at 03:02:48PM CET:
>>>
>>> I am tring to link with libtool using the compiler
>>> wrappers on a Cray and with pgi.
>>>
>>> At final
On Tue, Jun 8, 2010 at 11:03 AM, Peter Rosin wrote:
> Den 2010-06-08 15:40 skrev Christopher Hulbert:
>>
>> On Tue, Jun 8, 2010 at 9:24 AM, Peter Rosin wrote:
>>>
>>> I've had enough frustration here, methinks.
>>
>> Sorry for my contributio
On Tue, Jun 8, 2010 at 9:24 AM, Peter Rosin wrote:
> Hi Christopher!
>
> Den 2010-06-08 15:06 skrev Christopher Hulbert:
>>
>> On Tue, Jun 8, 2010 at 7:40 AM, Gary V. Vaughan wrote:
>>>
>>> I think it important to merge pr-msvc-support into master one wa
On Tue, Jun 8, 2010 at 7:40 AM, Gary V. Vaughan wrote:
> Hi Chris,
>
> Forgive my jumping in again here...
No problem, at least the subject is being talked about.
>
> On 8 Jun 2010, at 17:47, Christopher Hulbert wrote:
>> On Tue, Jun 8, 2010 at 4:22 AM, Peter Rosin wrote:
On Tue, Jun 8, 2010 at 4:22 AM, Peter Rosin wrote:
> Hi Gary!
>
> Den 2010-06-08 09:34 skrev Gary V. Vaughan:
>>
>> [[Adding Libtool List]]
>>
>> On 8 Jun 2010, at 08:42, Charles Wilson wrote:
>>>
>>> Which is why I don't think even the Peter's long-ready MSVC patches, nor
>>> my pile of pending p
I am working on a patch for my windows branch of libtool that will
allow me to embed manifest files in the DLLs. I have been manually
embedding them for a while now using "mt -manifest libfoo.dll.manifest
-outputresource:libfoo.dll;#2". Growing tired of that and the
occasional error if I forget to
On Tue, May 19, 2009 at 6:24 PM, Ralf Wildenhues wrote:
> Hi Christopher,
>
> * Christopher Hulbert wrote on Tue, May 19, 2009 at 06:38:10PM CEST:
>> Would it be acceptable to add the -objectlist option in compile mode.
>> If passed in compile mode, the .lo file compiled
Would it be acceptable to add the -objectlist option in compile mode.
If passed in compile mode, the .lo file compiled should be appended to
the file for use with -objectlist at link time. The reason I am
wondering is I have updated to automake 1.11 to check out the new
quieter output. Unfortunatel
I am working on the search for libraries in func_mode_link to get it
to find DLL import libraries on the search path (this is around line
4824 of ltmain.m4sh). The shlib_search_path is built on shlibpath_var
which is set to PATH on cygwin. My setup happens to have a PATH with
spaces in the director
I would like to perform configure tests trying to link a program (in
order to test for libraries) using libtool since that is what my
libraries and programs use anyways. So, based on AC_TRY_LINK and
AC_LINK_IFELSE, I've come up with the macro below which works for C. I
would like to extend it for t
On Wed, May 13, 2009 at 2:11 PM, Ralf Wildenhues wrote:
> Hello Christopher,
>
> * Christopher Hulbert wrote on Wed, May 13, 2009 at 01:14:47PM CEST:
>> 1. What's the future of that branch? Is it ever likely to merge into
>> master to become part of a libtool release
Until now, I have been using for the most part the PGI compilers on
Windows which conveniently use most of the same flags/command style as
its Linux compilers (e.g. -L -l). I am now also trying to use the
Intel compilers which use the MSVC format on Windows (e.g. -link
-libpath:). I have been looki
On Thu, Mar 26, 2009 at 3:06 PM, Ralf Wildenhues wrote:
> * Ethan Mallove wrote on Thu, Mar 26, 2009 at 04:17:11PM CET:
>> On Sat, Mar/21/2009 11:47:42AM, Ralf Wildenhues wrote:
>> > * Ralf Wildenhues wrote on Sat, Mar 21, 2009 at 11:41:20AM CET:
>> > > Thanks for the bug report. A workaround sho
I have a package with a few libraries where some of the libraries
depend on the others. I specify the dependent libraries in LIBADD as
$(top_builddir)/liba/liba.la. In the dependency_libs of the .la in the
build directory, the paths are expanded in a UNIX fashion. On cygwin,
this causes minor issue
On Fri, Jun 13, 2008 at 11:55 AM, Peter O'Gorman <[EMAIL PROTECTED]> wrote:
> Christopher Hulbert wrote:
>
>> GIT version still reports that the ifort linker does not support
>> shared libraries. The config.log is attached.
>
> Hi Chris,
>
> Your confi
On Thu, Jun 12, 2008 at 7:42 PM, Bob Friesenhahn
<[EMAIL PROTECTED]> wrote:
> On Thu, 12 Jun 2008, Christopher Hulbert wrote:
>
>> In libtool 2.2.2, building shared libraries using Intel fortran
>> compilers seem to be disabled (although the icc compiler appears to
On Thu, Jun 12, 2008 at 7:42 PM, Bob Friesenhahn
<[EMAIL PROTECTED]> wrote:
> On Thu, 12 Jun 2008, Christopher Hulbert wrote:
>
>> In libtool 2.2.2, building shared libraries using Intel fortran
>> compilers seem to be disabled (although the icc compiler appears to
In libtool 2.2.2, building shared libraries using Intel fortran
compilers seem to be disabled (although the icc compiler appears to
say yes). Thus, mixed language shared libraries or purely fortran
shared libraries can't be built. I have the intel 10.1 compilers. As a
quick way to get shared librar
On Fri, May 9, 2008 at 9:20 AM, Bob Friesenhahn
<[EMAIL PROTECTED]> wrote:
> On Fri, 9 May 2008, Steve Edwards wrote:
>>
>> I've been using libtool quite happily for some time but have just started
>> looking at packaging libraries for x86_64 systems. I'm trying to find out
>> what the recommended
On 8/27/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello Christopher,
>
> * Christopher Hulbert wrote on Mon, Aug 27, 2007 at 03:39:21PM CEST:
> > I'm starting to think about how to compile/link for the cell processor
> > using the autotools. My first thought
I'm starting to think about how to compile/link for the cell processor
using the autotools. My first thought was to configure for the PowerPC
processor, then override the C compiler for the SPU source files, but
that doesn't work. The only way I can see right now is multiple
configures or independe
On 4/3/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
Hello Christopher,
* Christopher Hulbert wrote on Tue, Apr 03, 2007 at 08:36:02PM CEST:
> The attached patch allows compilers without unistd.h to generate
> executables on windows 32 and 64-bit. This may not be the desired
> v
The attached patch allows compilers without unistd.h to generate
executables on windows 32 and 64-bit. This may not be the desired
version since it will be active on at least the MINGW host. On the
other hand, MINGW will support the code so it may not be a big deal.
Note: The relevant hunks of th
On 1/18/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
* Christopher Hulbert wrote on Thu, Jan 18, 2007 at 01:18:07PM CET:
> On 1/17/07, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> >On Wed, 17 Jan 2007, Christopher Hulbert wrote:
> >
> >> It seems that lib
On 1/17/07, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
On Wed, 17 Jan 2007, Christopher Hulbert wrote:
> It seems that libtool is set up to strip unrecognized flags unless
> using something like -Wc,flag. Can anyone give me a brief answer as
> to why? I often find myself going t
It seems that libtool is set up to strip unrecognized flags unless
using something like -Wc,flag. Can anyone give me a brief answer as
to why? I often find myself going through hoops to get flags past
libtool. I often can't use -Wc,flag because that gets passed directly
to the compiler since auto
On 1/8/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
Hello Christopher,
Thanks for the report.
* Christopher Hulbert wrote on Fri, Jan 05, 2007 at 04:10:18PM CET:
> Libtool uses MS's lib program when not using gcc in windows. On msys
> "lib /out:.libs/liba.lib"
Libtool uses MS's lib program when not using gcc in windows. On msys
"lib /out:.libs/liba.lib" is translated to "lib
C:\msys1.0\OUT;.libs\liba.lib". I'm not sure when lib (or windows)
started accepting "-" for options, but "lib -out" fixes the problem on
Windows XP. Would there be any objection to
On 12/14/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
* Christopher Hulbert wrote on Thu, Dec 14, 2006 at 08:11:20PM CET:
> On 12/14/06, Bob Rossi <[EMAIL PROTECTED]> wrote:
> >
> >> > *** Warning: This system can not link to static lib archive
> >
On 12/14/06, Bob Rossi <[EMAIL PROTECTED]> wrote:
On Thu, Dec 14, 2006 at 07:11:08PM +0100, Ralf Wildenhues wrote:
> > What exactly can I do about the libtool warning messages?
>
> These?
Yup,
> > *** Warning: This system can not link to static lib archive
/home/bobbybrasko/log4cxx/apr-util/
On 11/14/06, Benoit Sigoure <[EMAIL PROTECTED]> wrote:
Quoting Christopher Hulbert <[EMAIL PROTECTED]>:
>> My idea was to write a perl script and to invoke make
>> SHELL=my_shell.pl. That
>> script would rewrite the command properly so that it works withi
On 11/14/06, Benoit Sigoure <[EMAIL PROTECTED]> wrote:
Quoting Christopher Hulbert <[EMAIL PROTECTED]>:
>
>>
>> My idea was to write a perl script and to invoke make
>> SHELL=my_shell.pl. That
>> script would rewrite the command properly so that it wo
On 11/14/06, Benoit Sigoure <[EMAIL PROTECTED]> wrote:
Hello folks.
I'm developing Qt-based applications. The build system is controlled by the
autotools rather than by Qmake.
I'm porting our projects on Windows. We're using an automated build system
(buildbot.sf.net) to build every commit on L
On 6/13/06, Christopher Hulbert <[EMAIL PROTECTED]> wrote:
[snip]
Also, I had sent a patch in a while ago about making DLL's with the
PGI compilers (-Mmakedll flag) that I guess never made it in. I
remember having problems running the tests. I guess at some point
I'll try
It's been a long time since I've tried the PGI compilers with the
autotools. I usually get frustrated and go a way for a while.
Anyways, I ran into a problem I don't remember having before [updating
the CVS source]. When with_gcc is not set to yes, libtool is
replacing library files, -la with a.
On 2/22/06, Ed Hartnett <[EMAIL PROTECTED]> wrote:
>
> Howdy all!
>
> I got the latest libtool from the CVS and installed it. Now when I
> build my library, I get the following error:
>
> libtool: Version mismatch error. This is libtool 2.1a, but the
> libtool: definition of this LT_INIT comes fro
> Hi Christopher,
>
> * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 04:10:20PM CET:
> >
> > Lets say I build library liba as both static and shared (thus I have
> > liba.a and liba.so or liba.lib and liba.dll). I later want to build
> > libb.so or libb.dll against the in
applies to. Any thoughts on the matter?
On 2/15/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> [ off-list ]
>
> Hi Christopher,
>
> * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 02:24:10PM CET:
> > On 2/15/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>
On 2/15/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hi Christopher,
>
> * Christopher Hulbert wrote on Wed, Feb 15, 2006 at 12:28:59PM CET:
> > On 2/15/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > >
> > > Here's a set of rules.
> &
On 2/15/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hi Christopher,
>
> * Christopher Hulbert wrote on Tue, Feb 14, 2006 at 11:08:28PM CET:
> > I have a number of directories most of which I ONLY want to build
> > shared libraries from. There are a cou
I have a number of directories most of which I ONLY want to build
shared libraries from. There are a couple that I ONLY want static
libraries. Is there a way to turn on/off shared/static libraries. I
saw -static which would work IF both build_old_libs=yes. Is there any
way to have -static set b
On 2/10/06, Christopher Hulbert <[EMAIL PROTECTED]> wrote:
> archive_cmds="\$CC -o \$lib \$libobjs \$compiler_flags \\\`echo
> \\\"\$deplibs\\\" | \$SED -e 's/ -lc\$//'\\\` -link -dll~linknames="
>
>
> What is the -link and -dll doing? This m
archive_cmds="\$CC -o \$lib \$libobjs \$compiler_flags \\\`echo
\\\"\$deplibs\\\" | \$SED -e 's/ -lc\$//'\\\` -link -dll~linknames="
What is the -link and -dll doing? This messes up my linking with the
PGI C compiler as it can't find liblink.a.
libtool 1.5.22
_
I'm trying to pass some options to the linker using -Wl,opt1,opt2,
Libtool is not placing the -Wl, in front of each argument because in
the generated libtool script, wl="". If I manually replace that with
wl="-Wl," it prepends arguments with it as expected.
bash-3.00$ uname -a
CYGWIN_NT-5.1
Is there a reason that libtool doesn't pass PIC flags during the link
of shared libraries? And if it's passed as -fpic to the libtool
command, libtool strips it out. The way to get it through is use
-Wc,-fpic in my LDFLAGS, but then pgcc complains that -f is invalid
without -shared when building
> On another note, why does libtool add an entire static archive (.a) if
> it wasn't created with libtool? I did an nm on a convenience library
> and it had a .a stuck in there and nm complained that it didn't know
> what file type that was. It was also missing the symbols from inside
> that arch
On 12/2/05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hi Christopher,
>
> * Christopher Hulbert wrote on Fri, Dec 02, 2005 at 01:29:52PM CET:
> > On 12/2/05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>
> > No I don't think it&#x
On 12/2/05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
Hi Christopher,* Christopher Hulbert wrote on Fri, Dec 02, 2005 at 12:48:13PM CET:> That's what I get for not following Rule #1 (Make sure you are using the> latest version). 1.5.20 seemed to fix it.
Good to know.> The oth
that? perhaps an
AC_FC_LIBRARY_LDFLAGS_PIC type macro? I realize this is more of
an autoconf question, but hoping you could help out.On 12/2/05, Ralf Wildenhues <[EMAIL PROTECTED]
> wrote:Hi Christopher,* Christopher Hulbert wrote on Fri, Dec 02, 2005 at 03:41:41AM CET:
> I have a som
I have a some fortran code compiled by libtool into a static
(convenience archive). Later I compile a C source file into a
shared library linking against the fortran library. Since
automake/libtool have no knowledge that the objects are from fortran, I
add in the necessary fortran libraries. The
50 matches
Mail list logo
