Hi Jacob,
On Fri, 2004-08-27 at 18:22, Jacob Meuser wrote:
> it uses verbose output to figure out what the compiler will do, and
> then duplicates it ... but the compiler will still do it was doing,
> hence the errors from duplicated objects. I say "second guess"
> because it acts like it knows w
Hi Bob,
On Fri, 2004-08-27 at 17:53, Bob Friesenhahn wrote:
> I am glad to see that you responded to this since you were the one who
> made multi-lingual libtool possible. Thank you very much.
Thanks!
> It seems to me that if the C++ compiler is used to link, then C++
> exceptions will work.
Hi,
On Fri, 2004-08-27 at 17:25, Bob Friesenhahn wrote:
> On Fri, 27 Aug 2004, Jacob Meuser wrote:
> >>
> >> After a long time playing arround I solved my two problems as follow:
> >>
> >> 1.- Multiple Inclusion: comment out line 'postdeps="-lstdc++ -lm -lgcc_s
> >> -lgcc_s" ' from /usr/local/binl
b site
here:
http://www.gnu.org/software/libtool/contribute.html
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
___
l in your package to pull in the latest libtool M4
macros? Some of libtool's functionality is now at done at
`configure'-time, meaning that you have to pull in the latest libtool
M4 macros.
HTH,
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laborato
tributions.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail
oblem.
Yep, I applied Mo Dejong's patch. However, I'll resynch with the
libtool-1-4 patch just in case.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4
Hi Thomas,
On Thu, May 17, 2001 at 07:02:50PM +0200, Thomas Tanner wrote:
> On 17-May-2001 Ossama Othman wrote:
> > /bin/sh ../../libtool --mode=link gcc -Wall -Wmissing-prototypes
> > -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs
> > -g
lv -lresolv -lresolv")
and still retain the semantics of having more than one instance of the
library in the link command such as "-lgcc -lfoo -lgcc."
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvi
Hi,
Here's another libtool 1.4 bug report from a Debian user:
---
Is this a bug or a feature?
/bin/sh ../../libtool --mode=link gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wbad-function-cast -Wmissing-declarations -Wnested-externs -g
27;^AC_DEFUN\(A[MC]_PROG_LIBTOOL' aclocal.m4 >/dev/null 2>&1; then
which does not match this data:
>egrep '^AC_DEFUN\(\[A[MC]_PROG_LIBTOOL' aclocal.m4
AC_DEFUN([AC_PROG_LIBTOOL],
AC_DEFUN([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL])
because of the extra [.
-Ossama
--
Os
OTECTED]
Resent-From: "Etienne M. Gagnon" <[EMAIL PROTECTED]>
Orignal-Sender: egagnon
Resent-To: [EMAIL PROTECTED]
Resent-CC: Ossama Othman <[EMAIL PROTECTED]>
Resent-Date: Thu, 17 May 2001 06:03:45 GMT
Resent-Message-ID: <[EMAIL PROTECTED]>
Resent-Sender: [EMAIL PROTECTED]
X-De
Hi Alexandre,
On Tue, May 08, 2001 at 03:55:36PM -0300, Alexandre Oliva wrote:
> On May 8, 2001, Ossama Othman <[EMAIL PROTECTED]> wrote:
>
> > Right, but the problem is that is it prevents users who "know what
> > they're doing" from using gcc's &q
c tells
> libtool to *prefer* static libraries, not to *require* them.
Right, but the problem is that is it prevents users who "know what
they're doing" from using gcc's "-static" option. It seems to me that
libtool shouldn't do this sort of "filter
Hi,
Libtool drops the user supplied "-static" flag (e.g. in $LDFLAGS) from
the link command. Is this what we want? This behavior has been a
source of confusion for some users.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of Cali
+ support in the libtool multi-language branch work
for you? There may be no need to modify libtool, if so.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7
ntiation_per_object" to CXXFLAGS if they
need it, not libtool.
> For the cxx compiler (for DEC alpha, maybe Compaq now?) I had to do
The Compaq C++ compiler is also already supported in the
multi-language branch libtool.
I'd be interested in any feedback you might have regarding that
re fairly consistent across
all platforms it is supported on.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
__
ject files
to pull in the appropriate symbols, as I understand.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
__
ixed this problem, but I also ran into this problem
with one my own packages. I'll try to get this problem soon, if the
rest of the team doesn't have time.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A39
Hi,
Is there any reason why libtool convenience libraries use an
intermediate static library? Isn't it possible to just add the object
files directly to the link command? Are issues such as command line
length involved here?
Thanks,
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
c.so.1
> libstdc++.so.2.10.0 =>
> /public/packages/programming/gcc-2.95.2/lib/libstdc++.so.2.10.0
> libdl.so.1 =>/usr/lib/libdl.so.1
> /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
>
> Please note the second line.
Maybe I'm missing something
I just committed a fix for this to the ML-branch libtool. Thanks for
the report Bob!
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
__
additional libtool features.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
___
Libtool mailing list
[EM
\
# deplibs_check_method="pass_all" \
# file_magic_cmd="\${MAGIC}" \
# make/ltconfig -o libtool --cache-file=/dev/null --with-gcc
--build=powerpc-ibm-aix4.3.3.0 --add-tag=CXX make/ltcf-cxx.sh
powerpc-ibm-aix4.3.3.0
#
BTW, Robert thanks so much for working on the AIX port!
e? BTW, the above message is
coming from the automatic tagged configuration selection code I
mentioned in my last message.
Thanks,
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
certain that this feature was working a
few months ago.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
s
> out of the libtool CVS repo using -kv, so that they don't get further
> replaced when imported into other CVS trees, but nobody does that.
> Not even myself :-)
I removed the RCS ID tags in the ltcf-*.sh shell script fragments.
Let me know if there are any other problems. :-)
-Ossa
won't object.
BTW, it was probably me who added them in the first place. Blame it
on force of habit (ACE/TAO). :-)
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
#x27;t recall
the exact variable name(s).
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
ch should work with stable autoconf and
automake, in addition to the CVS versions. However, there may still
be a problem with using CVS autoconf. I'm not sure if the problem
was ever resolved.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. o
ile extension is) to the
compiler/linker. The `.lo' files contain information about where PIC and
non-PIC object files reside.
This change was necessary to properly support compilers that support C++
template repositories, for example.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
btool/
for additional information on what is going in the libtool world.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Hi Michael,
On Sun, Jun 11, 2000 at 02:33:36AM +0200, Michael Matz wrote:
> On Sat, 10 Jun 2000, Ossama Othman wrote:
> >
> > BTW, I finally got around to setting up two default GNU C++
> > configurations, one for when g++ uses GNU ld as its linker, and one
> > for t
support for KCC (KAI C++) on Linux, and some support for
KCC on OSF/1 (Digital UNIX/Compaq Tru64). This still needs some
improvement, however.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
;pass_all," which is why the static lib never gets
dropped during the ILD analysis loop. Does Solaris actually support
linking shared libs against static ones? If not, then it may be a
better idea to use the "file_magic" deplibs check method. Thoughts?
-Ossama
--
Ossama Othman <
. Does anyone see a problem with that?
Just one: time. :-)
I don't have the time to maintain another branch.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Hi Alexandre,
On Sat, Jun 03, 2000 at 05:52:19PM -0700, Alexandre Oliva wrote:
> On Jun 2, 2000, Ossama Othman <[EMAIL PROTECTED]> wrote:
>
> > I wanted to check with you about switching that branch to use CVS
> > autoconf and CVS automake.
>
> Unless there
e/coolo/prod/KDE/lib -lSM -lICE -lICE -lqt -lpng -lz
> /usr/lib/libjpeg.la -lXext -lX11 -lSM -lICE
> -L/usr/lib/gcc-lib/i386-linux/egcs-2.91.66 -L/usr/i386-linux/lib
> -lstdc++ -lm -lc -lgcc'
>
> Also quite perfect. I investigate further
Great! Thank you very much!
-Ossama
-
bs" variable passed to the ILD
analyser:
libs: -lm -L/usr/lib/gcc-lib/i386-linux/2.95.2 -lstdc++ -lm -lgcc -lc -lgcc
You're KDE test is of course much more exhaustive then this simple
test. Can you please give the new patch a try?
Thanks,
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Hi Stephan,
You're too quick. :-)
I'm testing a different patch which should be better, and incurs less
overhead during link-time, since it is run at config-time.
On Sun, Jun 04, 2000 at 01:12:53AM +0200, Stephan Kulow wrote:
> Ossama Othman wrote:
> > There was a slight
Hi,
There was a slight bug in the patch I just posted, but I think that
you get the idea of what it was supposed to do.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB
predeps_lib_path $postdeps"
fi
deplibs=
> Furthermore this wrong ordering is saved into the .la files and every
> other lib I want to link against them picks that up.
The above patch should fix the problem.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed
Hi Stephan,
On Fri, Jun 02, 2000 at 09:46:59PM +0200, Stephan Kulow wrote:
> Ossama Othman wrote:
> > Since many of you are using the libtool multi-language branch, I
> > wanted to check with you about switching that branch to use CVS
> > autoconf and CVS automake. I ha
uch a move then I may rethink the switch. Does
anyone have problems with such a change?
Thanks,
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Hi Kevin,
On Wed, May 31, 2000 at 12:46:34AM -0400, Kevin Atkinson wrote:
> On Tue, 30 May 2000, Ossama Othman wrote:
> > Thanks for the simple test. I just need to find a Solaris system with
> > a busted libstdc++ installation, i.e. one that built without
> > "-
> >>test.cc:
>
> #include
>
> void foo() {
>cout << "What!" << endl;
> }
Thanks!
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Hi Kevin,
On Tue, May 30, 2000 at 05:37:59PM -0400, Kevin Atkinson wrote:
> On Tue, 30 May 2000, Ossama Othman wrote:
> > goes through. This means that libtool should be dropping the static
> > libs from the dependency list. Do you get a warning message from
> > Libto
t portable!
Do you get any warning from libtool?
Thanks,
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
ibtool disables the internal library link commands that
the C++ compiler would normally perform automatically, and simply does
the linking itself. Why does it work for the C++ compiler?
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California
brary specific.
> This feature was discussed in previous emails at length...
I guess that I need to run through the archives again. :-)
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Hi Stephan,
On Sun, May 28, 2000 at 01:43:28PM +0200, Stephan Kulow wrote:
> Ossama Othman wrote:
> > Is this flaw specific to the ML branch, or does the HEAD branch suffer
> > from this flaw too?
> >
> I think it's ML specific as it explicitly adds libstdc++.
oes the HEAD branch suffer
from this flaw too?
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Hi Michael,
On Fri, May 26, 2000 at 12:51:01AM +0200, Michael Matz wrote:
> On Mon, 22 May 2000, Ossama Othman wrote:
> > Great! KDE would be a great smoke test for the multi-language branch
> > libtool.
>
> It's smoking already ;) Even with problem reports ;)
Gre
tdl. Your
archive_expsym_cmds patch has also been incorporated.
I'll try to move the general g++ configurations outside of the
platform-specific configurations soon.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8
ke some changes.
> Please advise, we will have to make the necessary changes
> anyway :)
Go for it!!! The less work I need to do, the better. :-)
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Hi Kevin,
On Thu, May 18, 2000 at 11:43:28PM -0400, Kevin Atkinson wrote:
> On Thu, 18 May 2000, Ossama Othman wrote:
> Sure. I don't know anything about libtool's internals but if you send me
> a patch I can try it out on several different platforms including Digital
>
Hi again,
Okay, I'm too tired to speak properly.
On Thu, May 18, 2000 at 07:46:23PM -0700, Ossama Othman wrote:
> Does this reasonable?
I meant "does this sound reasonable?"
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ.
willing to do what ever I
> can to help out. I will even be willing to write some code provided
> someone can point me in the right direction.
Donations are always welcome. :-)
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
l can create shared libraries for C but
> > > not for C++
> >
> > When libtool finds that a shared library depends on a library for
> > which no shared version is available, it decides not to create a
> > static library.
>
> This is a very different answer f
Hi Kevin,
On Tue, Apr 11, 2000 at 02:43:23AM -0400, Kevin Atkinson wrote:
> On Mon, 10 Apr 2000, Ossama Othman wrote:
> > Right. I don't have access to all of the platforms supported by libtool's
> > C library support so I wasn't able to configurations for
necessary modules and set up the data
> structure automatically so that the end user does NOT have to call
> LTDL_SET_PRELOADED_SYMBOLS().
I think that I'll let someone else handle this question. Bob, thanks for
helping out! I'm not too familiar with this feature of libtool yet.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
n here and give their
opinon.
HTH,
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
;
> That's a known problem, and the latest stable release of libtool says
> it does not fully support any language other than C. Work towards
> supporting other languages is being done by Ossama Othman in the
> multi-language branch of the libtool CVS tree. IIRC, this
> partic
ed. I'm working on this problem. Bob, I wonder
if this is the cause of your C++ exception problems. Are you passing
some sort of exception flag at link time?
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
hen
$show "$mkdir $objdir"
$run $mkdir $objdir
status=$?
if test $status -ne 0 && test ! -d $objdir; then
exit $status
fi
fi
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ.
rocks. Now I wait for Ossama to
> update the other branch, so I can test it with my real setup :)
Heavy is the burden of he who maintains a CVS branch. :-)
I'll merge Thomas' ILD updates into the multi-language branch later
today.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
and the code looks like this:
>
> if test ! -d $objdir; then
> $show "$mkdir $objdir"
> $run $mkdir $objdir
> status=$?
> if test $status -ne 0 && test ! -d $dir; then
> exit $status
> fi
> fi
>
:)
>
> OK. I've just commited my latest patch to CVS.
> It does now also support interdependent libraries.
> Please test it.
*sigh* I guess I'll have to update the multi-language branch, too. :-)
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Com
Hi Martin,
On Wed, Feb 16, 2000 at 03:06:06PM -0800, Ossama Othman wrote:
> it seems like it might be useful. I won't have to look at
> implementing such a feature for a while, however. Does anyone have
This should have been "I won't
and create automatically a libtool
> that supports all these languages?
Wow, good question. This is again something I didn't think about but
it seems like it might be useful. I won't have to look at
implementing such a feature for a while, however. Does anyone have
any thoughts on this?
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
an you give me more details of your fix,
specifically where did you make your fix?
Thanks,
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
ou pointed out.
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
73 matches
Mail list logo
