I think I was getting a bit off track before. Some cut down bad
behaviour can be seen, I think, from a file "foo" containing the
following
blah blah \\\` blah blah
and run a script
if test -n "$ZSH_VERSION"; then emulate sh; fi
eval "bar=\\\"\`cat foo\`\\\""
cat < \ gets done. Don't know if t
On Apr 17, 2001, Chris Leishman <[EMAIL PROTECTED]> wrote:
> *** Warning: This library needs some functionality provided by
> extra/libextra.a.
> Unfortunately I can't get the application to load the libshared.a file
> as a dynamic module (not unsurprising). Even if I specify -dlopen on
> the c
On Apr 16, 2001, Christopher Lintz <[EMAIL PROTECTED]> wrote:
>handle = dlopen("/home/cjl/.libs/foo.so.0", RTLD_LAZY );
[...]
>if ((fptr = (int (*) () )dlsym(RTLD_DEFAULT, "foo")) != NULL)
make it `handle'
--
Alexandre Oliva Enjoy Guara
On Apr 16, 2001, Russ Allbery <[EMAIL PROTECTED]> wrote:
> Some vague memory also tells me that this is how shared library versioning
> is done (with differently named shared objects).
Yep, this matches my understanding of the way shared libraries work on
AIX.
--
Alexandre Oliva Enjoy Guaran
Hi,
I've been playing with the latest alpha release of libtool and have come
across this issue.
When linking a shared library (for a dynamically loaded module), the
project I'm working on uses code from a subdirectory that has been
compiled into an archive library (.a).
So the link line is so
Gary V Vaughan <[EMAIL PROTECTED]> writes:
> Hi Dan,
> Don't forget to at least Cc: one of the lists... I might be struck by
> lightning before I get chance to reply ;-)
Piggybacking off of Gary's response
> On Monday 16 April 2001 11:05 pm, [EMAIL PROTECTED] wrote:
>> - When building lib
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
>
> Oh dear. I thought zsh was sane enough to do the right thing when
> argv[0] == /bin/sh =(O| I take it that it is zsh builtin echo that
> is the culprit here. Does /bin/echo work correctly?
No, gives the same. And my own program doing a printf i
Hi Dan,
Don't forget to at least Cc: one of the lists... I might be struck by
lightning before I get chance to reply ;-)
On Monday 16 April 2001 11:05 pm, [EMAIL PROTECTED] wrote:
> Yes I ran into this problem while trying to build libtool itself.
> Sorry about the confusion.
>
> Anyway, on a h
On Monday 16 April 2001 11:31 pm, Boyd Lynn Gerber wrote:
> On 17 Apr 2001, Kevin Ryde wrote:
> > cc and gcc on sco know not to add -lc, so the test there looks like it
> > would probably be right, except that archive_cmds is setup to use $LD,
> > so it doesn't come into play.
> >
> > Maybe archiv
On Monday 16 April 2001 11:56 pm, Kevin Ryde wrote:
> I wrote:
> > so maybe it's sed.
>
> Or maybe not.
>
> eval "bar=\\\"\` echo \"\$quote\" \`\\\""
> echo $bar
>
> in bash gives what I assume is the expected result
>
> "s/\([\\"\\`$]\)/\\\1/g"
>
> whereas on Darwin
>
> "s/\([
I wrote:
> so maybe it's sed.
Or maybe not.
eval "bar=\\\"\` echo \"\$quote\" \`\\\""
echo $bar
in bash gives what I assume is the expected result
"s/\([\\"\\`$]\)/\\\1/g"
whereas on Darwin
"s/\([\\"\\`$]\)/\1/g"
Actually Darwin /bin/sh looks like it's zsh (should ha
On 17 Apr 2001, Kevin Ryde wrote:
> cc and gcc on sco know not to add -lc, so the test there looks like it
> would probably be right, except that archive_cmds is setup to use $LD,
> so it doesn't come into play.
>
> Maybe archive_cmds should switch to using $CC, though I wouldn't know
> if that mi
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
>
> It looks like the echo command found by libtool is removing some of the
> backslashes that it is supposed to leave behind.
Yep.
> And this is what I get:
>
> $ echo $bar
> "\\\`"
Yep, on i386 debian or freebsd.
> I guess you will get:
>
> On Friday 13 April 2001 2:22 am, Kevin Ryde wrote:
> >
> > Without wanting to repeat myself, I posted libtool-patches in January
> > about SCO 5 and -lc on shared libraries, but the problem still exists
> > in 1.3d and the current cvs.
>
> > Something like below (re-diffed for current libtool
I would greatly appreciate any help that will get
me past this problem. I have tried Libtool and gcc directly on Solaris
2.6 to try and build a shared library that can be called by
dlopen()... This is the exact error I get:
ld.so.1: dlopen: fatal: foo: can't find
symbol
Here is the exa
Hi Jacob,
On Friday 13 April 2001 4:31 pm, jacob berkman wrote:
> i've tried using this patch against the branch-1-3 branch of cvs
> libtool, and it seems to work on hp-ux 11.00.
>
> by "seems to work" i mean that sawfish/librep build and run, whereas
> they did not with libtool 1.3.4 or 1.3.5.
On Friday 13 April 2001 2:22 am, Kevin Ryde wrote:
>
> Without wanting to repeat myself, I posted libtool-patches in January
> about SCO 5 and -lc on shared libraries, but the problem still exists
> in 1.3d and the current cvs.
Yeah, sorry about that. I lost my mail archive (along with the mes
On Friday 13 April 2001 4:57 pm, Guido Draheim wrote:
> I did lately try out the newest cvs version of the autotools, and
> I was amazed that libtool can not create dlls with it.
It creates dlls fine for me.
> I had been
> using the libtool-version from the libsdl.org project, and it did
> work
Hi Dan,
On Thursday 12 April 2001 5:42 pm, [EMAIL PROTECTED] wrote:
> I just sucked down a fresh copy of the HEAD branch from cvs.
>
> libtool/ltdl.m4 contains the following line:
> AC_CHECK_FUNCS(memcpy bcopy, break)
Uh-huh.
> But there is nothing in libtool/configure.in nor
> libtool/libltdl
Hello again Dan,
Okay seems might I got the wrong end of the stick -- I didn't realise that
you were referring to building libtool. If you were talking about your own
project that is making use of libltdl, then one solution is for you to add
AC_LIB_LTDL to your configure.in, and copy ltdl.m4
On Thursday 12 April 2001 12:56 pm, Alexandre Oliva wrote:
> - create some way to tell libtool ``look, this -L flag is to be used
> only when building this particular library, it's not needed for any of
> its dependencies after the library is installed.'' This might be
> accomplished by specifyin
Hi Skip!
On Thursday 12 April 2001 1:20 pm, Skip Montanaro wrote:
> I'm starting to use the glib/gtk 1.3.3 from Python 2.1 on my Mandrake Linux
> 7.1 system using James Henstridge's pygtk wrappers. I have a very simple
> Python script that bombs with a number of these messages:
>
> Cannot l
Hi Kevin,
It looks like the echo command found by libtool is removing some of the
backslashes that it is supposed to leave behind. Here is what it boils down
to:
$ echo=echo
$ foo='`'
$ quote='s/\([\\"\\`$]\)/\\\1/g'
$ double_quote='s/\([\\"\\`]\)/\\\1/g'
$ delay='s/
23 matches
Mail list logo
