level symbols but link into the higher level interface.
Thanks in advance. It would really help me out.
---
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
Normal programs will link
to one and pspell modules and possibly other spell checkers will link to
the other.
> On Sun, 19 Mar 2000, Kevin Atkinson wrote:
> > For one of my projects (pspell, http://pspell.sourceforge.net) I want to
> > have to different interfaces into the same l
On 20 Mar 2000, Alexandre Oliva wrote:
> On Mar 19, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > I want to have to [two?] different interfaces into the same library.
Yes 2.
>
> You can't do that in a single library, in general. It's a matter o
On 20 Mar 2000, Alexandre Oliva wrote:
> On Mar 20, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > The current version of libtool's does not support linking to other
> > libtool's libraries. Does the current CVS version?
>
> Yep, sorry, forgot
to do the final linking.
Or maybe I am going about this the wrong way.......
---
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
On 28 Mar 2000, Alexandre Oliva wrote:
> On Mar 28, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > How do I make the multi-lang libtool use c++ to link c++ shared libraries
> > so that the c++ libraries are linked in.
>
> IIRC, you'd have to arran
On 28 Mar 2000, Alexandre Oliva wrote:
> On Mar 28, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > On 28 Mar 2000, Alexandre Oliva wrote:
>
> > I tried that and it STILL insists on using gcc to make the shared
> > libraries.
>
> Do you mean your
On Wed, 29 Mar 2000, Kevin Atkinson wrote:
> On 28 Mar 2000, Alexandre Oliva wrote:
>
> > On Mar 28, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> >
> > > On 28 Mar 2000, Alexandre Oliva wrote:
> >
> > > I tried that and it STILL insists
On 29 Mar 2000, Alexandre Oliva wrote:
> On Mar 29, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > AC_LIBTOOL_CXX
> > AM_PROG_LIBTOOL
>
> You must swap these two lines. AM_PROG_LIBTOOL creates libtool,
> AC_LIBTOOL_CXX requires AM_PROG_LIBTOOL, t
he necessary modules and set up the data
structure automatically so that the end user does NOT have to call
LTDL_SET_PRELOADED_SYMBOLS().
Thanks in advance. Any advice you can give me would really help me out
with my Pspell (http://pspell.sourceforge.net) project.
---
Kevin Atkinson
[E
features and just some how
make sure all the right libraries get linked in and just avoid using
global variables which require initilization...
Please give me some guidance here.
-- Forwarded message --
Date: Tue, 4 Apr 2000 17:40:01 -0400 (EDT)
From: Kevin Atkinson <[EM
libraries are NOT
compiled as static libraries (and often not compiled with pic
support (which means they can't get linked into the shared modules) but
they some how need to get access to the c++ libraries when loaded
---
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
On Mon, 10 Apr 2000, Bob Friesenhahn wrote:
> On Mon, 10 Apr 2000, Kevin Atkinson wrote:
> > About a week ago I posted this massage to the libtool mailing but I have
> > yet to receive any replies.
>
> Don't feel too bad. I have posted questions to the libtool list
On Mon, 10 Apr 2000, Kevin Atkinson wrote:
> On Mon, 10 Apr 2000, Bob Friesenhahn wrote:
>
> > Regarding your Problem 2, the way the library I maintain (ImageMagick,
> > http://www.imagemagick.org) does it, each module exposes unique
> > symbols using a pre-defined n
On Mon, 10 Apr 2000, Ossama Othman wrote:
> Hi Kevin,
>
> On Mon, Apr 10, 2000 at 10:22:54PM -0400, Kevin Atkinson wrote:
> >
> > About a week ago I posted this massage to the libtool mailing but I have
> > yet to receive any replies.
> >
> > I could REA
On Tue, 11 Apr 2000, Michael Bletzinger wrote:
> Kevin Atkinson wrote:
> > Because libstdc++ is compiled ONLY as a static library. When I tried
> > creating a C++ shared library it tried to put the static library into the
> > shared library which failed miserably as
On Tue, 11 Apr 2000, Ossama Othman wrote:
> 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
> >
On 11 Apr 2000, Alexandre Oliva wrote:
> On Apr 11, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> >> You're linking C++ libraries to a C program? That seems a bit odd. Did I
> >> misunderstand you?
>
> > Why? I have a library that is writt
piled when ever a new spell checker is
added, however.
Maybe I could do both.
Pspell can be found at http://pspell.sourceforge.net/.
---
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
;t pull cin, cout and cerr, nor any
> other global variables.
What about global variables without contractors?
---
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
On 11 Apr 2000, Alexandre Oliva wrote:
> On Apr 10, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > About a week ago I posted this massage to the libtool mailing but I have
> > yet to receive any replies.
>
> Sorry. I'm drowning in e-mail :-(
>
>
ell-config --libs`.
*** FEATURE REQUEST
The only problem is how to get this necessary information. I guess I could
scan libpspell.la and libspell-modules.la for the information but it would
be really nice if libtool would be able to this for me. Something link
libtool --mode=link-flags -lpspell -lpspell-modules
would be really great.
So how about it? How difficult would it be to add that to libtool?
---
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
On 13 Apr 2000, Alexandre Oliva wrote:
> On Apr 12, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > On 12 Apr 2000, Alexandre Oliva wrote:
> >> On Apr 12, 2000, Michael Bletzinger <[EMAIL PROTECTED]> wrote:
> >>
> >> > Another optio
On 13 Apr 2000, Alexandre Oliva wrote:
> On Apr 13, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > The basic idea is NOT to use the preload feature of libtool but instead
> > build up the data structure myself.
>
> Wait a minute. If you're not dlo
On 13 Apr 2000, Alexandre Oliva wrote:
> On Apr 13, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > Could you elaborate. When shared libraries are used simply linking with
> > -lpspell should work as all the dependences will automatically be tracked
> >
On 14 Apr 2000, Alexandre Oliva wrote:
> On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > If the rpath is not needed or the equivalent will simply listing out the
> > necessary libraries work on most, or the most common systems?
>
> If a libra
On 14 Apr 2000, Alexandre Oliva wrote:
> On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > On 14 Apr 2000, Alexandre Oliva wrote:
> >> On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> >>
> >> > If the rpath is no
On 14 Apr 2000, Alexandre Oliva wrote:
> On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > So will listing out ALL the required libraries, provided that they are in
> > the library search path (ie no rpath nonsense) work on most system in both
> &
On 14 Apr 2000, Alexandre Oliva wrote:
> My fear is that others might start to depend on this feature, which
> might solve the problem for them, but not for people who happen to
> install libraries in places other than /usr or /usr/local, like me.
> In fact, I've always advocated against these *-
On 14 Apr 2000, Alexandre Oliva wrote:
> On Apr 14, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
>
> > Doesn't either setting LD_LIBRARY_PATH (or the equivalent variable for
> > your particular system) or adding the weird location to /etc/ld.so.conf
> &g
On Fri, 14 Apr 2000, Bob Friesenhahn wrote:
> On Fri, 14 Apr 2000, Kevin Atkinson wrote:
> > Doesn't either setting LD_LIBRARY_PATH (or the equivalent variable for
> > your particular system) or adding the weird location to /etc/ld.so.conf
> > (or the equivalent file
e since free software must be held to a
> higher standard of quality.
And what exactly is wrong with this approach. How it it not acceptable for
free software. Are you trying to say that free software packages should
ALWAYS be compiled for a precise system setup?
---
Kevin Atkinson
[EMAIL
On Fri, 14 Apr 2000, Bob Friesenhahn wrote:
> On Fri, 14 Apr 2000, Kevin Atkinson wrote:
>
> > On Fri, 14 Apr 2000, Bob Friesenhahn wrote:
> >
> > > Commercial programs typically include a shell script which sets
> > > LD_LIBRARY_PATH (and other var
. I will even be willing to write some code provided
someone can point me in the right direction.
Thanks in advance.
--
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
ns are always welcome. :-)
Well if you point me in the right direction I may just give you one
--
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
you need to pass
special options too it this native linker is bound to be the same as the
linker used for C programs. So then can't C++ libtool get the necessarily
options to pass (like the rpath stuff) from the C part of libtool. Or am
I missing something?
---
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
On Fri, 26 May 2000, Michael Matz wrote:
> On Thu, 25 May 2000, Kevin Atkinson wrote:
> >
> > Maybe I am missing something here but can't you just let g++ handle all
> > the C++ issues. If G++ does call the native linker and you need to pass
> > special opti
On Sun, 28 May 2000, Stephan Kulow wrote:
> Ossama Othman wrote:
> >
> > Hi Stephan,
> >
> > On Sat, May 27, 2000 at 10:10:44AM +0200, Stephan Kulow wrote:
> > > Kevin Atkinson wrote:
> > > >
> > > > Hopefully since KDE will be
On Sun, 28 May 2000, Kevin Atkinson wrote:
> On Sun, 28 May 2000, Stephan Kulow wrote:
>
> > I think it's ML specific as it explicitly adds libstdc++.a. HEAD branch
> > checks
> > for -lstdc++ if it's static and drops it from the linker call
>
> Unles
king static libraries into shared
libraries could also cause problems when two different shared libraries
have slightly different versions of the same static library.
--
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
/gcc-lib/sparc-sun-solaris2.6/2.95.1/libstdc++.a(filebuf.o)
ld: fatal: relocations remain against allocatable but non-writable
sections
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `libtest.la'
This is using the latest libtool ml checked
>>Makefile.am:
AUTOMAKE_OPTIONS = foreign
lib_LTLIBRARIES = libtest.la
libtest_la_SOURCES = test.cc
>>configure.in:
AC_INIT(test.cc)
AM_INIT_AUTOMAKE(test, 1.0)
AC_PROG_CXX
AC_LANG_CPLUSPLUS
AM_PROG_LIBTOOL
AC_LIBTOOL_CXX
AC_OUTPUT(Makefile)
>>test.cc:
#include
void foo() {
cout <<
rsion I get all sorts of warning over obsolete
variables, but don't want to change them as that will loose all hope with
working with the released version. I remember trying the released version
and had some problems with automake making the file .C as the
executable
--
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
On 3 Jun 2000, Alexandre Oliva wrote:
> On May 30, 2000, Ossama Othman <[EMAIL PROTECTED]> wrote:
>
> > On Wed, May 31, 2000 at 12:46:34AM -0400, Kevin Atkinson wrote:
>
> >> ltconfig: `./ltcf-gcj.sh' does not exist
>
> >> Not that big of a deal
following order which included listing libpspell twice:
pspell pspell-modules pspell_aspell aspell pspell pspell_ispell
Does anyone know of a good solution to this problem?
Everything works fine when shared libraries are used, but then again when
shared libraries are used I don't need to per
wisrably
It there a way to forse the so called "file_magic" method to avoid
putting static libraries into shared one wven if the linker will accept
it?
---
Kevin Atkinson
[EMAIL PROTECTED]
http://metalab.unc.edu/kevina/
On Sat, 10 Jun 2000, Ossama Othman wrote:
> Hi,
>
> On Sat, Jun 10, 2000 at 07:45:43PM -0400, Kevin Atkinson wrote:
> > Well since the ML branch was giving me s many problems I switched to
> > the HEAD brach for the time being becuase I wan't to get a re
Hat 7.0 and all of them give the same error.
Thanks.
---
Kevin Atkinson
kevina at users sourceforge net
http://metalab.unc.edu/kevina/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Tue, 28 Nov 2000, Kevin Atkinson wrote:
>
> I just updated to the latest CVS version of libtool and I noticed two
> problems.
>
> 1) Even though I defined LT_NON_POSIX_NAMESPACE I still can't get lt_ptr_t
> to work. After looking at the header file I d
gt; However, IIRC, it is valid to have the implicit name overridden by
> another definition of the name, which is what the `typedef' does.
So are you saying that you are not going to fix it. It does NOT appear
to be valid C++ code, thus when the header file is used in C++ programs it
preve
On 28 Nov 2000, Alexandre Oliva wrote:
> On Nov 28, 2000, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> > It does NOT appear
> > to be valid C++ code
>
> I've just managed to compile:
>
> typedef struct foo foo;
Yes that will compile but
typedef stru
`typedef struct lt_dlhandle_struct lt_dlhandle'?
I will assume you ment.
typedef struct lt_dlhandle_struct * lt_dlhandle;
--
Kevin Atkinson
kevina at users sourceforge net
http://metalab.unc.edu/kevina/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
rd
> > > or something?
> >
> > I prefer `something' :-)
> >
> > How about `typedef struct lt_dlhandle_struct lt_dlhandle'?
>
> Done!
Thanks. It works find now.
>
--
Kevin Atkinson
kevina at users sourceforge net
http://metalab.unc.edu/kev
://pspell.soucreforge.net). So far I have only been able to get this
working fully on Linux and have not herd from anyone success on other
platforms.
Thanks in advance.
PS: I did talk to you guys earlier about some of these issues a while back
in case you remember.
---
Kevin Atkinson
kevina at
On Mon, 22 Jan 2001, Kevin Atkinson wrote:
> I am trying to get the dramatic loading of C++ libraries to work on Solaris
> but I am running into problems with the fact that shared C++ libraries are
> not provided on many systems because Gcc does not enable them by
> default. Is th
On Mon, 22 Jan 2001, Lars J. Aas wrote:
> On Mon, Jan 22, 2001 at 12:57:33PM -0500, Kevin Atkinson wrote:
> : I should also add that I am using the multi-lib branch of libtool.
>
> multi-language, perhaps?
Yes that's what I meant sorry.
---
Kevin Atkinson
kevina at users sou
fails try creating one with -mimpure-text and see if that works
---
Kevin Atkinson
kevina at users sourceforge net
http://metalab.unc.edu/kevina/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
so that I can dynamically load a dll at run time so that Pspell will work
under Win32.
Thanks in advance.
--
Kevin Atkinson
kevina at users sourceforge net
http://www.ibiblio.org/kevina/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org
Have all these changes been merged in the multi-language branch? I
noticed that this branch still using a ltconfig.
--
Kevin Atkinson
kevina at users sourceforge net
http://www.ibiblio.org/kevina/
___
Libtool mailing list
[EMAIL PROTECTED]
http
On Sun, 1 Apr 2001, Gary V. Vaughan wrote:
> On Friday 30 March 2001 3:54 am, Kevin Atkinson wrote:
> > I was wondering what the status is for supporting C++ on Win32 in the
> > multi-language branch of libtool.
>
> The g++ support for win32 should not be any worse t
60 matches
Mail list logo
