In regard to: Re: Sun Studio: STL libraries, Dan Lacher said (at 4:57pm on...:
Even with what Tim has pointed out I am seeing the contrary with the
following:
o Open MPI src base
o Sun Studio 12
o libtool 2.1b (just downloaded the latest)
After autogen has finished the aclocal.m4 ends up
In regard to: Re: Sun Studio: STL libraries, Peter O'Gorman said (at 5:05pm...:
I still maintain that it would be OK to have libtool automatically add
`-library=Crun', since that is generally needed whether you're using
-library=stlport4 or -library=Cstd, but it's OK to not include that. We
jus
In regard to: Re: Sun Studio: STL libraries, Peter O'Gorman said (at 5:25pm...:
Peter O'Gorman wrote:
Tim Mooney wrote:
In regard to: Re: Sun Studio: STL libraries, Dan Lacher said (at 4:57pm
on...:
Even with what Tim has pointed out I am seeing the contrary with the
following:
In regard to: Re: Sun Studio: STL libraries, Tim Mooney said (at 6:05pm on...:
In regard to: Re: Sun Studio: STL libraries, Peter O'Gorman said (at
5:25pm...:
Tim, you say we still need to have -library=Crun for the stlport4 case?
More than likely, yes. The stlport4 incompatibili
u use
CXXFLAGS="-library=%none -library=no%libC"
Does libtool still thwart your efforts?
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
Nor
I'm getting an "UNEXPECTED PASS" on test 30 of the new test suite
on my UnixWare 7.1.4 box.
A testlog generated with "gmake check-local TESTSUITEFLAGS='-d -x 30'" is
attached.
I don't seem to understand the new test suite well
On Fri, 8 Feb 2008, Ralf Wildenhues wrote:
> * Tim Rice wrote on Fri, Feb 08, 2008 at 03:00:05AM CET:
> > I'm getting an "UNEXPECTED PASS" on test 30 of the new test suite
> > on my UnixWare 7.1.4 box.
>
> Thanks for the bug report. I've installed
On Sun, 10 Feb 2008, Ralf Wildenhues wrote:
> [ cutting libtool-patches ]
>
> Hi Tim,
>
> * Tim Rice wrote on Sun, Feb 10, 2008 at 12:05:33AM CET:
> > Now only 54, 55 and of course 64 (because 54 & 55 fail) fail on
> > UnixWare 7.1.4. There is still some work
CVS HEAD pulled Fri Feb 8 17:52:22 PST 2008
Solaris 10 w/ SunStudio 11
I'm seeing failures in 64 bit mode I don't see in 32 bit mode with
compiler options that woked for me in both 32 & 64 on branch-1.5.
testsuite.log-64.gz attached.
--
Tim Rice
Hi Ralf,
On Mon, 11 Feb 2008, Ralf Wildenhues wrote:
> * Tim Rice wrote on Mon, Feb 11, 2008 at 06:23:59AM CET:
> > CVS HEAD pulled Fri Feb 8 17:52:22 PST 2008
> > Solaris 10 w/ SunStudio 11
> >
> > I'm seeing failures in 64 bit mode I don't see in 32 bi
kages
that are primarily C (but link against C++ libraries/objects) to know that
they need to "switch to" C++ for linking in their C project?
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC
In regard to: Re: linking a C program with a C++ library on Solaris, Bob...:
On Mon, 25 Feb 2008, Tim Mooney wrote:
On Solaris, if you are linking against any C++ objects, you must use the
C++ compiler to link. I don't know if that's common to other platforms
or not, as I don
In regard to: Re: linking a C program with a C++ library on Solaris, Ralf...:
Hello Bob, Tim,
* Bob Friesenhahn wrote on Tue, Feb 26, 2008 at 03:11:44AM CET:
On Mon, 25 Feb 2008, Tim Mooney wrote:
I don't see anything in 2.1b's info files or README or NEWS for updating
a project
stdeps,$1)='-library=Cstd -library=Crun'
to
_LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun -lm'
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701)
In regard to: Re: libtool C++ link bug with -lm functions with Sun Workshop...:
On Wed, 19 Mar 2008, Tim Mooney wrote:
That means that doing something like
AC_INIT(lttest, 0.60.5)
AC_CONFIG_SRCDIR(configure.ac)
AC_PROG_CXX
AC_LANG([C++])
AC_CHECK_FUNCS(sqrt)
AC_OUTPUT
will always detect
In regard to: Re: libtool C++ link bug with -lm functions with Sun Workshop...:
On Wed, Mar 19, 2008 at 07:03:38PM -0500, Tim Mooney wrote:
I think I have discovered a bug in libtool's link behavior with the
Sun Workshop C++ compiler when creating a C++ library that requires libm.
I obs
* [all-recursive] Error 1
By visual inspection, it doesn't look like the relevant code in libtool.m4
that automatically adds `-library=Cstd -library=Crun' has changed in any
significant manner since 1.5.2X.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Te
eeded, and those direct dependencies can cause headaches during
upgrades?
Tim
--
Tim Mooney [EMAIL PROTECTED]
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State Univers
Is there a miniumum version of m4 to build/test libtool-2.2.6 and later?
Thanks.
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
local/lib/64, rather than the version 1.1 libfoo.la that was just
installed in e.g. /tmp/build/bar/usr/local/lib/64.
Tim
--
Tim Mooney moo...@dogbert.cc.ndsu.nodak.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building
Hi Ralf,
On Sat, 21 Feb 2009, Ralf Wildenhues wrote:
> Hi Tim,
>
> * Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET:
> >
> > I'm trying to understand the cmdline_wrap.at test.
> > I've added this patch to fix the 2 template tests that were failing
&g
I noticed that the SCOABSPATH bits are in aclocal.m4 on 2.2.6 and
was wondering how they got there since the corresponding changes
to libltdl/m4/libtool.m4 were intentionally not forward ported from
the 1.5 branch.
--
Tim RiceMultitalents(707) 887-1469
t
Hi Ralf,
On Wed, 25 Feb 2009, Ralf Wildenhues wrote:
: Hi Tim,
:
: * Tim Rice wrote on Mon, Feb 23, 2009 at 10:47:49PM CET:
: > On Sat, 21 Feb 2009, Ralf Wildenhues wrote:
: > > * Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET:
: > > >
: > > > I
ep -n "^reload_cmds=" libtool
123:reload_cmds="\$LD\$reload_flag -o \$output\$reload_objs"
t...@server01-unixware 134% grep -n "CONFIG: CXX" libtool
9097:# ### BEGIN LIBTOOL TAG CONFIG: CXX
9245:# ### END LIBTOOL TAG CONFIG: CXX
.
--
Tim Rice
-prefix-dir option was
added, which I believe happened early in the 1.5.x series.
Tim
--
Tim Mooney moo...@dogbert.cc.ndsu.nodak.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
No
0b40 T mpeg4_write
That doesn't illustrate the use of libtool, but it does illustrate what
the text you've quoted is talking about.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, I
.yes || echo -install_name
>$rpath/$soname) $verstring'
I can understand the change for quotes, but why the change from x$module
and xyes to .$module and .yes? Is that really necessary? What about
other parts of libtool that use x$var = x. If possible, keeping it
consistent would be
In regard to: Re: gettext libintl.la dependency_libs problem, Albert Chin...:
>On Thu, Jan 02, 2003 at 07:07:42PM -0600, Albert Chin wrote:
>> On Thu, Jan 02, 2003 at 06:30:58PM -0600, Tim Mooney wrote:
>> > I'm on the libtool list, but not the bug-gnu-gettext list. I have
ncy_libs.
That patch does alleviate the problem -- when I rebuild glib 2.2.0's
configure machinery to use the patched libtool 1.4.3, -R/some/path is no
longer passed to the platform linker. Whether it's the optimum fix,
I don't know.
Tim
--
Tim Mooney
should be translating -R when it sees it to whatever is
appropriate for the current compiler and/or linker, when libtool later
links something with `lib.la'.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 2
ns of a library available on
a platform).
What I don't get is the rationale for using both styles. Can anyone
enlighten me regarding this issue?
Thanks!
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voi
to worry about.
1.4.3 has been working relatively well for me, for the majority of
packages I've built with it. I use BuildRoot installs exclusively.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IA
yle linkers?
I actually like and have made great use of the "executables pick up
the RPATH entries for libraries they link against". It can be very handy.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Roo
will likely encourage you to use that version instead. If you try libtool
1.5 and encounter the same problem, send another message to the libtool
list with information similar to what you provided in your original message.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Informatio
In regard to: Re: LD_RUN_PATH not adding paths when building with shared...:
>On Thu, Aug 28, 2003 at 05:36:50PM -0500, Tim Mooney wrote:
>
>> Are you assuming LD_RUN_PATH is something that's honored on IRIX because
>> you've seen it honored on other platforms (e.g. S
27;t specify it itself, the only way I'm aware of is
via the `-rpath' option of ld. The linker will include the RPATH from
libraries in the binary it generates, though, so you wouldn't need -rpath
when linking your binary if libgcc_s.so.N internally specified an RPATH
f
10.x, but real 64 bit objects and shared libraries weren't available
until 11.x, in which case the default extension should likely be .so .
Anyone care to comment?
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
R
In regard to: RE: Incorrect library suffix on newer HP-UX (.sl vs .so),...:
>
>Tim,
>
>hpux under pa-risc (even 64-bit) still uses the .sl extension even where
>64-bit ELF libraries are concerned. Only under the Intel architecture
>does it use the .so filename. If you want
sed to ld, and ld doesn't understand
that option.
I haven't had a chance to look much at the problem, but thought I would
report it. Please let me know if I can provide additional information.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services
her the place where it's under a "case" for `-L', or it's
the place where you have
newlib_search_path="$newlib_search_path $ladir"
Do some testing, and report back what you find. Better yet, test with
libtool 1.5.2.
Tim
--
Tim Mooney
r or not that works, what happens if you instead do:
CC='cc -64 -Wl,-64'
CXX='CC -64 -Wl,-64'
CXXFLAGS='-LANG:std'
LDFLAGS='-64'
Do either of these work around the problem successfully?
Ideally libtool should be passing the link flags unmolested, bu
In regard to: Re: hardcode_into_libs and Tru64 UNIX, Peter O'Gorman said...:
Tim Mooney wrote:
Anyone know if the reversion to hardcode_into_libs=no was an intentional
change, and if so what the reasoning was?
I have no idea, and a quick ChangeLog grep was not enlightening. If you feel
uilding and installing once, then reconfiguring with CFLAGS and LDFLAGS
set for a different ABI and overridding the library directory, and
building and installing again? This can become a pretty tiresome
process, especially if you also package your local software (such as
with RPM) and install the
In regard to: Re: building libtool libraries for multiple ABIs, Albert Chin...:
>On Tue, Apr 27, 2004 at 04:58:54PM -0500, Tim Mooney wrote:
>>
>> If you want to build and install a local package (take for example GSL,
>> the GNU Scientific Library) that builds a library
t the
only relevant hit in the list archive search is Albert's request to
make it yes for Tru64 et. al.:
http://mail.gnu.org/archive/html/libtool/2001-12/msg00032.html
Anyone know if the reversion to hardcode_into_libs=no was an intentional
change, and if so what the reasoning was?
Th
ol.m4 and ltdl.m4? If you do,
try removing all of those things, and do a fresh un-tar, configure, make
(with GNU make), and see what happens.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building
In regard to: Re: hardcode_into_libs and Tru64 UNIX, Tim Mooney said (at...:
In regard to: Re: hardcode_into_libs and Tru64 UNIX, Peter O'Gorman said...:
Tim Mooney wrote:
Anyone know if the reversion to hardcode_into_libs=no was an intentional
change, and if so what the reasoning was?
I ha
? Isn't this essentially the same issue that the multi-ABI
commercial UNIXes have?
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building (701) 231-8541 (Fax)
North Dakota State Un
ns should be is less clear, especially since there will be
differences in what's available for different platforms and OSes.
Tim
--
Tim Mooney [EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building
ehavior. I had been considering an environment variable that libtool
would check and parse, but if other optional behavior control is going to
be via command-line flags, it would seem best if my patch piggybacked on
that work.
Comments and suggestions welcome,
Tim
--
Tim Mooney
> libtool is taking 30-40s to execute on my 366MHz iBook running Mac OS X,
> compared with approx. 2s on my 166MHz x86 running Linux, and I'm pretty
> sure it was even quicker still on my iBook when *that* was running Linux,
> so:
>
> Is it just me & mine, or is there some reason libtool is very
There is a problem with the way autoconf 2.50 (as well as current
CVS HEAD) schedules AC_PROG_CXX and AC_PROG_CXXCPP if both are
AC_REQUIRE'd.
libtool.m4 has
AC_DEFUN([_LT_AC_LANG_CXX],
[AC_REQUIRE([AC_PROG_CXX])
AC_REQUIRE([AC_PROG_CXXCPP])
])# _LT_AC_LANG_CXX
but autoconf generates a configur
> My reflex reaction is to say that this probably isn't supported
> by libtool, but then I have very little practical cross compilation
> know-how.
My first thought that was this is really GCC's job - its specs file
tells it what start/end files to link with. So if it's a "real"
cross-compilat
On Fri, 2001-10-05 at 07:14, Ian Peters wrote:
> Unfortunately, with libtool 1.4.x, I get this instead (after a much,
> much longer time):
>
> gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o
> [snip]
> installer-ui.o -Wl,-Bstatic -rdynamic -rdynamic -rdynamic -rdynamic
>
> > I'd say a bug, since options libtool doesn't handle itself are moved
> > around when they shouldn't be.
>
> Suck, that was what I was afraid of. Any workarounds?
None, I'm afraid. From a quick glance, it seems libtool (well,
ltmain.sh)
collects compiler/linker options in one list, and obje
> >> > it is probably still worth mentioning in the autoconf manual's
> >> > section on portable shell programming.
> >>
> >> Yes, that makes sense.
>
> Tim> I'll whip up something tomorrow.
>
> Hi Tim! ;)
Hi Akim!
As you w
Something like this, perhaps?
2001-10-21 Tim Van Holder <[EMAIL PROTECTED]>
* doc/autoconf.texi: Mention the issue of bash 2.05's
`set' builtin.
Index: doc/autoconf.texi
===
RCS file: /
> >>>>> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes:
>
> Tim> Something like this, perhaps?
>
> For sure!
>
OK - installed (this may be resolved in bash 2.06; if so, I'll try to
remember to amend this entry accordingly).
__
I asked about this a whil ago, but since I didn't receive any
comments, I'm asking again.
bash's behaviour with regards to the 'set' builtin has changed
in 2.05:
> 3. New Features in Bash
>
> b. When `set' is called without options, it prints function
> defintions in a way that allows the
> Why is this broken?
I was only relaying a problem someone else reported; it seemed odd
to me, but without 2.05 lying around, I couldn't test it.
> It's true that you can't parse the latter line with other shells.
> So perhaps what you're saying is that, if you use Bash 2.05 to
> run 'configure
Ralf Wildenhues wrote:
>> - [LIBTOOL] by default, the compilers require that files come last on
>> the command line, and many versions of libtool (including the one
>> included with GMP) break this rule when configure has determined -c
>> and -o can both be used (it puts the -o last). To work
_value_table(int base)"
method that returns the correct table (determining ASCII vs EBCDIC at
runtime).
With these changes (limits in mpf/t-get_d.c, and EBCDIC-friendly
mp_dv_tab.c), the test results change to
- top-level: 9/9 tests passed
- mpn:9/10 tests passed
- mpz: 53/56 test
Ralf Wildenhues wrote:
> * Tim Van Holder wrote on Fri, Jul 13, 2007 at 04:11:43PM CEST:
>> Ralf Wildenhues wrote:
>>>> - [LIBTOOL] by default, the compilers require that files come last on
>>>> the command line, and many versions of libtool (including the on
Ralf Wildenhues wrote:
> * Tim Van Holder wrote on Tue, Jul 17, 2007 at 08:57:56AM CEST:
> [...]
>> Both compiles and links are affected.
>>
>> For the linking, automake puts the -o at the end itself, so it is
>> at least partially to blame. Then again, libtool do
On Wed, 2002-02-13 at 03:01, Ted Irons wrote:
> We are using cygwin (1.3.9) with fltk-1.1 on a
> Windows NT machine.
>
> Our C++ package uses autoconf, automake, and
> libtool to maintain the build system.
> CXXFLAGS contains -DWIN32.
> LDFLAGS contains -no-undefined and -mwindows.
> configure.ac
> On Tue, 2002-04-02 at 08:45, Grzegorz Jakacki wrote:
> >
> > Hi,
> >
> > Why is there so much spam on [EMAIL PROTECTED]? Is there
> anybody blocking
> > spammers?
>
> Mailman allows filtering of messages only on headers, so a lot of spam
> gets through. Since traffic on [EMAIL PROTECTED] is
em not to match a backslash if it is not doubled.
Also, since this is probably an 'is_absolute' check, it should really be
[\\/]* | ?:[\\/]* ) (cfr the File System Conventions chapter in
the autoconf manual's portability section).
--
Tim Van Holder <[EMAIL PROTECTED]>
d
to use 'aclocal -I m4' or something similar so that aclocal will find
and use the libtool macros.
--
Tim Van Holder <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
ersion).
> >>ls
> AUTHORS commitdepdemoltdl.m4 mkstamp tagdemo
> bootstrapconfig.guess docltmain.c NEWS tests
^
Run this script, and it will do what's needed to produce configure.
$ ./bootstrap
or
$ sh bootstr
Bill Jones wrote:
So the basic question is how do I specify a static import library with a
*.lib extension to be used by libtool for resolving the symbols provided
by a non-libtool DLL when building a dependent DLL with libtool?
The trivial solution is of course to make a copy of the third-party
Bob Friesenhahn wrote:
On Wed, 14 Apr 2004, Earnie Boyd wrote:
>
So all that is needed is for libtool to accept .lib as an extension
and for libtool to (possibly naively) assume that if a similarly-named
DLL exists that the .lib file is a DLL link library?
Yes and no. For one thing, there is no r
101 - 171 of 171 matches
Mail list logo
