Random files are generated wth .loT file type.
Are there any known reasons for this behaviour?
martin welsh
___
https://lists.gnu.org/mailman/listinfo/libtool
On 06/07/15 23:18, Simon Richter wrote:
Hi,
On 06.07.2015 20:17, martin wrote:
Random files are generated wth .loT file type.
Files ending in T are temporary files that are generated because some
compilers do not delete the output file on failure. These are renamed to
the same name without
Please unsubscribe.
___
https://lists.gnu.org/mailman/listinfo/libtool
Hello,
I'm currently using libtool 1.3c (feb 3 2000) and love the --prefer-pic
feature.
I'd really appreciate if there was a macro that could be used in our
configure.in to specify that we'd prefer pic, or not, or both. (Just
like the AC_ENABLE_?? AC_DISABLE_?? macros)
Can anyone with the expertise clarify the situation, please?
Thanks!
Martin
--
__
Okiok Data ltd.| Spécialiste des solutions de sécurité
d'entreprise
Tel. : (450) 681.1681 |
http://www.okiok
Alexandre Oliva wrote:
>
> On Feb 15, 2000, Martin Proulx <[EMAIL PROTECTED]> wrote:
>
> > This choice prevents me from compiling correctly with libtool on
> > solaris.
>
> > I have to build a c++ shared library that uses exception.
>
> Libtool doe
Alexandre Oliva wrote:
>
> On Feb 15, 2000, Martin Proulx <[EMAIL PROTECTED]> wrote:
>
> C++ support is under development in the multi-language-branch of the
> libtool CVS tree. Feel free to give it a try, and please report any
> problems you find.
>
>
Ossama Othman wrote:
>
> Hi Martin,
>
>
> > The only glitch is that the c++ tag deplibs_check_method was set to
> > "unknown".
> >
> > I manually modified it to "pass_all" (to match the C one, and I then had
> > a perfectly work
Ossama Othman wrote:
>
> Hi Martin,
>
>
> BTW, are you using the AC_LIBTOOL_CXX macro, or are you appending
> manually? It looks like you're appending manually. I bet that's why
> the deplibs_check_method wasn't set properly for you. Sorry, I didn't
;require_version" and the c++ configurations, for at least the GNU
compiler?
Thanks!
Martin
--
__
Okiok Data ltd.| Spécialiste des solutions de sécurité
d'entreprise
Tel. : (450) 681.1681 |
http:/
mailing list archives visible. May take a little
longer, unless someone beats me to it...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999 + martin
iD8DBQE541P3Vw+hz3xBJfQRAlxKAJ90Qc/EKCcCZ9SCzudovA1ZRZSzkwCfa59e
N52cSGUn0HA3dMNfTTG0vD0
for instance -unique-dependency-libs ?
Here's a patch for this:
diff
--
Martin Baulig
[EMAIL PROTECTED] (private)
[EMAIL PROTECTED] (work)
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On May 20, 2001, Martin Baulig <[EMAIL PROTECTED]> wrote:
>
> > If you have a "complicated" dependency setup, this will slow down linking
> > in a very extreme way (it is more than 5 times slower for me) beca
bb.la; if it appears only once it both of them, only the last one
> should prevail.
Well, that's what didn't work for me. I'll debug it later on.
--
Martin Baulig
[EMAIL PROTECTED] (private)
[EMAIL PROTECTED] (work)
___
Libtool mailing
ration or build environment result in
> minimal re-configury. Etc; I could go on in great detail about the
> idea but I won't right now.
Sounds good, maybe we should search a better place to discuss these.
> On to your complaints.
> Martin> I think the great misunderstandin
ile and heimdal.
No, I have not found a solution to this problem. Our current approach
when building RPMS is to build the package twice, the second time with
the package partially installed. Not very good.
Regards,
Martin
--
[ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1
ans.edu/~pauljohn/software
I tried rebuilding the ogle RPM with your new version of libtool
(libtool-20011121-1pj), and got the errors shown in the attached file.
There are still things like
libtool: install: warning: `../ogle/libmsgevents.la' has not been
installed in `/usr/lib/ogle'
inux fs]$ rpm -q autoconf
> autoconf-2.52-1pj
Ok. Now I have:
automake-1.5-1
autoconf-2.52-4
(both from redhat rawhide).
After changing my configure.in to conform with the new autoconf, I tried
to rebuild the source, package it and build the RPM. Still the same error.
I really hope some libtool
ce code and the source rpms, please
find them at http://www.dtek.chalmers.se/~dvd/
Regards,
Martin
--
[ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ]
Opinions expressed above are mine, and not those of my future employees.
SIGBORE: Signature boring err
o much. I'll try this -- it looks like a good solution.
>
> That appeared to work perfectly -- thanks again.
Worked for me too when building RPMS!
Regards,
Martin
--
[ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ]
Opinions expressed ab
2001-12-07 14:58:14-0800, [EMAIL PROTECTED] ->
> ==> "mn" == Martin Norbäck <[EMAIL PROTECTED]> writes:
>
> >> > Agreed -- the same is true with Debian -- minimizing the
> >> Debian diff > is a good idea, all other things being equal
Hello,
I am trying to compile libtool so I can install another package which requires
it. I have successfully compiled M4, Automake, Autoconf and installed in
/usr/gnu.
When I try to do the same for libtool, I receive errors.
I have tried the following:
./configure --prefix=/usr/gnu
/usr/css/bin
Hello,
I am trying to
compile libtool so I can install another package which requires it. I
have successfully compiled M4, Automake, Autoconf and installed in
/usr/gnu.
When I try to do the same for libtool, I receive errors.
I have tried the following:
./configure --prefix=/usr/gnu
/usr/css/bi
Friesenhahn
To: Jeff Martin
Cc: "libtool@gnu.org"
Sent: Sunday, August 19, 2012 10:59 AM
Subject: Re: HELP: libtool 2.4.2 not compiling on Solaris 10u10 Sparc
On Sun, 19 Aug 2012, Jeff Martin wrote:
> Hello,
> I am trying to
> compile libtool so I can install another package which re
Update.
Really not sure why, but I started a new session and now the compile is working.
So perhaps it was something with my session. I'll probably never know exactly
but I am just glad its working now.
Thanks,
jeff
- Original Message -
From: Bob Friesenhahn
To: Jeff Marti
var and so that it's implicitly deduced to be int
nm_test_var().
Thanks,
Martin
On 1/7/20 9:47 PM, Nick Bowler wrote:
On 1/7/20, Martin Liška wrote:
nm -B detection fails to be detected with -flto and -fno-common CFLAGS:
configure:6307: checking command to parse /usr/bin/nm -B output from gcc
object
[...]
configure:6536: gcc -o conftest -O2 -Wall -D_FORTIFY_SOURCE=2
On 1/7/20 10:07 PM, Bob Friesenhahn wrote:
On Tue, 7 Jan 2020, Nick Bowler wrote:
On 1/7/20, Martin Liška wrote:
nm -B detection fails to be detected with -flto and -fno-common CFLAGS:
I don't know what vintage this documentation is (the copyright says it is from 2020 so it
seems
On 1/7/20 10:40 PM, Nick Bowler wrote:
On 1/7/20, Bob Friesenhahn wrote:
On Tue, 7 Jan 2020, Nick Bowler wrote:
On 1/7/20, Martin Liška wrote:
nm -B detection fails to be detected with -flto and -fno-common CFLAGS:
I don't know what vintage this documentation is (the copyright says
On 1/8/20 10:16 AM, Martin Liška wrote:
On 1/7/20 9:47 PM, Nick Bowler wrote:
On 1/7/20, Martin Liška wrote:
nm -B detection fails to be detected with -flto and -fno-common CFLAGS:
configure:6307: checking command to parse /usr/bin/nm -B output from gcc
object
[...]
configure:6536: gcc -o
conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Darwin laptop.lan 8.2.0 Darwin Kernel Version 8.2.0: Fri Jun 24
17:46:54 PDT 2005; root:xnu-792.2.4.obj~3/RELEASE_PPC Power Macintosh
powerpc
--
Martin Paljak
[EMAIL PROTECTED]
http://martin.pal
to link libhttp and its
makefile.am as well as the other libtool link command debug.
Thanks,
m.
--
Martin Paljak
[EMAIL PROTECTED]
http://martin.paljak.pri.ee/
+372.5156495 - phone
debugs.tar.gz
Description: GNU Zip compressed data
libhttp.la
Description: Binary data
__
I forgot to mention that it woks fine on debian unstable (libtool
1.5.6 and autoconf 2.59)
m.
On 9/9/05, Martin Paljak <[EMAIL PROTECTED]> wrote:
> Hi,
> On 9/9/05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > Thanks for reporting this.
> >
> > Please post
uto tools is a
GoodThing and maybe libtool helps to do 'one big static binary' with
ease...
where can i get libtool 2.0 or further information ?
--
Martin Paljak
[EMAIL PROTECTED]
http://martin.paljak.pri.ee/
+372.5156495 - phone
libqt.la
Description: Binary data
_
file provided by trolltech folks ? Or can i hack the
libqt.la file to make it work ?
Thanks,
m.
--
Martin Paljak
[EMAIL PROTECTED]
http://martin.paljak.pri.ee/
+372.5156495 - phone
___
http://lists.gnu.org/mailman/listinfo/libtool
re
releasing 1.5.23. This may have some impact on Interix 2.x, but as 3.5
is now available for free and 3.0 should work as before, it shouldn't
matter that much.
Thank you very much
Martin
___
http://lists.gnu.org/mailman/listinfo/libtool
before releasing
1.5.23. This may have some impact on Interix 2.x, but as 3.5 is now available
for free and 3.0 should work as before, it shouldn't matter that much.
Thank you very much
Martin
___
http://lists.gnu.org/mailman/listinfo/libtool
rris (from the ethereal project) pointed me to libtool too report this.
According to what I found in ltmain.sh, ethereal is using libtool 1.4.2.
Please let me know, if you need additional info on this.
Thanks
Martin
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
used. When not used,
link passes without problems but later when library invokes new
operator, core dump occurs.
Are there any suggestions regarding these issues?
Thanks
Martin
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.
e: not found
: warning: cannot infer operation mode from `xlC'
: you must specify a MODE
Try ` --help' for more information.
make: 1254-004 The error code from the last command is 1.
This is on line 338:
progname=`$echo "$0" | ${SED} 's%^.*/%%'`
The problem is wit
I've installed CVS libtool to wrong directory so aclocal used different
libtool.m4. My mistake, now everything works fine.
Thank you for your help.
Martin
Ossama Othman wrote:
> Hi,
>
> On Mon, Oct 07, 2002 at 07:01:04PM +0200, Martin Frydl wrote:
>
>>progname=
make) 1.7.2
gettext (GNU gettext) 0.11.5
Tru64Unix/OSF1 5.1A
--
Martin Mokrejs <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics <http://mips.gsf.de>
GSF - National Research Center for Environment
On Sat, 7 Dec 2002, Martin MOKREJŠ wrote:
Hi,
thank you for quick responses. The reason I want to have new libtool is,
that I'm facing problems compiling gtk+ on my machine. I was told I've hit
libtool bug:
/bin/bash ../libtool --mode=link cc -O2 -arch ev6 -I/software/@sys/usr/inclu
ld,-soname \
-Qoption,ld,libshr.so.0 -o .libs/libshr.so.0.0.0
When I remove -nostdlib and -lc from command line, exe runs without
problems.
Am I doing something wrong? I've passed CC=icc CXX=icpc to configure.
I'm using CVS version of libtool.
Thanks
Martin
iccexctest.tgz
Albert Chin wrote:
On Mon, Jan 06, 2003 at 05:29:04PM +0100, Martin Frydl wrote:
I've found problem when throwing exception from shared library when
compiled with icc on Linux. I've attached a test case. The source of
this problem is probably linking against c library. Libtool
moved -nostdlib).
The built with gcc and Sun's CC was also successful, but this is
definitelly not a correct solution.
Martin
Robert Boehne wrote:
Albert,
I think it may be that an Autoconf macro is re-setting this
later on. I seem to get "archive_cmds_need_lc=yes" in nearly
ev
e autoconf 2.57, automake 1.7.1 and CVS libtool:
ltmain.sh (GNU libtool) 1.4e (1.1210 2003/03/25 23:53:38)
-- Martin
References:
http://mail.gnu.org/archive/html/libtool/2002-05/msg00054.html
http://mail.gnu.org/archive/html/automake/2002-09/msg00148.html
___
libtool and automake are
installed. libtoolize takes one from libtool, not automake
- libtool needs to be patched to support options supplied in CC or CXX
variables
Martin
--- share/libtool/config.guess Thu Sep 11 20:42:41 2003
+++ config.guessThu Sep 11 20:48:01 2003
@@ -62
Boehne, Robert wrote:
Martin,
Even on a 64-bit capable machine, aCC defaults to 32-bit libraries.
Having config.guess return hppa2.0w does not change the output that
is produced, aCC will produce whatever you tell it to (32-bit by default).
When you're running a configure script you want t
ols.
This is not bad per se, but very annoying when used with make -s and
libtool --silent as it prints a lot of false error messages.
Could libtool please redirect nm stderr to /dev/null or take other
actions to suppress the warning.
Or perhaps use objdump which us
ools input depending on
autotools versions and features...
I'm not subscribed to this list, but I hope this mail gets accepted
anyway, and I'll try to keep track of the archives.
Greetings,
Martin von Gagern
signature.asc
Descript
51 matches
Mail list logo
