--- Begin Message ---
|
Subject: |
Libtool Digest, Vol 17, Issue 11 |
Send Libtool mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.gnu.org/mailman/listinfo/libtool
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Libtool digest..."
Today's Topics:
1. Se buscan Distribuidores franquicia Telefonia Movil --->>
Valido en Todo el Mundo (1Cellnet)
2. Re: Shared library support in Interix? (Tristan Fillmore)
3. UNIVERSITY DIPLOMA (Madelyn Oakes)
4. Re: MinGW link against an MS Windows import library
(Tim Van Holder)
5. Permanently increase the size of your manhood (Maggie Dawkins)
6. Re: MinGW link against an MS Windows import library (Bill Jones)
7. Re: Question on libltdl & autobook & freebsd (Gary V. Vaughan)
8. C linkage problem when C++ library is used. (Bob Friesenhahn)
9. Re: Shared library support in Interix? (Tristan Fillmore)
----------------------------------------------------------------------
Message: 1
Date: Wed, 14 Apr 2004 21:05:44 +0200
From: "1Cellnet" <address@hidden>
Subject: Se buscan Distribuidores franquicia Telefonia Movil --->>
Valido en Todo el Mundo
To: "address@hidden" <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Your Email Client does not support MIME encoding. Please upgrade to
MIME-enabled Email Client (almost every modern Email Client is MIME-capable).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.gnu.org/pipermail/libtool/attachments/20040414/6660f988/attachment.htm
------------------------------
Message: 2
Date: Wed, 14 Apr 2004 14:48:23 -0700
From: Tristan Fillmore <address@hidden>
Subject: Re: Shared library support in Interix?
To: "Gary V.Vaughan" <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain
On Tue, 2004-04-13 at 06:28, Gary V.Vaughan wrote:
> Libtool maintenance notes are in the Maintaining node of the texinfo
> docs.
> Contribution guidelines are on the web:
>
> http://www.gnu.org/software/libtool/contribute.html
Thanks, these look like good starting points.
Tristan
------------------------------
Message: 3
Date: Thu, 15 Apr 2004 09:07:55 +0600
From: "Madelyn Oakes" <address@hidden>
Subject: UNIVERSITY DIPLOMA
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
GET YOUR UNIVERSITY DIPLOMA
Do you want a prosperous future, increased earning power more money and the
respect of all?
Call this number: 1-917- 591- 5067 (24 hours)
There are no required tests, classes, books, or interviews!
Get a Bachelors, Masters, MBA, and Doctorate (PhD) diploma!
Receive the benefits and admiration that comes with a diploma!
No one is turned down!
Call Today 1-917- 591- 5067 (7 days a week)
Confidentiality assured!
------------------------------
Message: 4
Date: Thu, 15 Apr 2004 08:33:32 +0200
From: Tim Van Holder <address@hidden>
Subject: Re: MinGW link against an MS Windows import library
To: Bob Friesenhahn <address@hidden>
Cc: Earnie Boyd <address@hidden>, address@hidden, Bill
Jones <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii; format=flowed
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 requirement for the build
machine to actually have a copy of the DLL; also, the DLL can be located
anywhere (not even necessarily in the PATH) - it just needs to be
findable when the resulting linked application is run.
The Microsoft import libraries (e.g. kernel32.lib) are recognizable
(all entries in the .lib file list 'KERNEL32.DLL' as name), but those
are provided as .a by MingW, so that's not much of a help either (and
I'm fairly certain non-MS import libraries don't have the same
'feature').
------------------------------
Message: 5
Date: Thu, 15 Apr 2004 22:07:57 +0600
From: "Maggie Dawkins" <address@hidden>
Subject: Permanently increase the size of your manhood
To: "Libtool" <address@hidden>
Message-ID: <address@hidden@yahoo.com>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
http://mail.gnu.org/pipermail/libtool/attachments/20040415/28aaf68e/attachment.html
------------------------------
Message: 6
Date: Thu, 15 Apr 2004 09:43:03 -0400
From: Bill Jones <address@hidden>
Subject: Re: MinGW link against an MS Windows import library
To: libtool <address@hidden>
Cc: Tim Van Holder <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii; format=flowed
I don't think that linking directly against a DLL under Windows is a
good idea (or even possible). From
http://blogs.msdn.com/oldnewthing/archive/2004/01/12/57833.aspx it would
appear that the LIB file should be used to account for any "decorations"
added to the exports.
wtj
Earnie Boyd wrote:
> Tim Van Holder wrote:
>
>> 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 .lib
>> file with a .a extension (the file format is identical anyway).
>> Alternatively, you may be able to create a fresh .a from the DLL using
>> 'dllwrap --implib <dllname> -o <libname>', but it's likely that that
>> won't have all the necessary symbols.
>
>
> Or just use the dll itself in the link. Note if the library references
> C++ objects, then you are going to be hard pressed for an easy
> solution. See www.mingw.org and it's list archives for more information.
>
> Earnie
>
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Bill Jones address@hidden
Mail Stop 125 Data Analysis and Imaging Branch
15 Langley Boulevard Systems Engineering Competency
NASA Langley Research Center Building 1268, Room 1038
Hampton, VA 23681-2199 Phone +1 757 864-5318
Fax +1 757 864-7635
http://geolab.larc.nasa.gov
------------------------------
Message: 7
Date: Thu, 15 Apr 2004 16:48:19 +0100
From: "Gary V. Vaughan" <address@hidden>
Subject: Re: Question on libltdl & autobook & freebsd
To: Jay West <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii; format=flowed
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jay West wrote:
| FreeBSD 4.9
| libtool 1.5
| automake 1.75
| autoconf 2.57
|
| I'm new to autoconf & friends. I'm going through the autobook and reading
| how all things are supposed to work. So far I've got my project GNUized
| pretty much and most of it I think I have a basic handle on. However, now
| I'm moving into a section of my project which I'd like to use libltdl with.
| On freeBSD, libtool is apparently configured by default to not install
| libltdl. It appears to build it, but not install the libltdl library and
| ltdl.h into /usr/local/lib and /usr/local/include. Side question - does
| anyone know why this is turned off by default? No big deal, just curious.
This is probably the bug that was fixed in libtool 1.5.6.
| I am having trouble getting a source that wants to use "lt_dlopen" to
| compile. I did a libtoolize -ltdl, added the snippets to configure.in that
| the autobook says are the right incantations, but it's still not finding
| them when I go to build it. I want to try to figure this out on my own, but
| I'd like someone to nudge me down one of two paths...
|
| When the main source program wanting to use lt_dlopen attempts to link
| against libltdlc (convenience library built in my development directory in
| libltdl directory), should it be looking in my own libltdl directory (the
| one created by libtoolize -ltdl) for that library, or using what is
| installed (supposed to be anyways) in /usr/local/lib? I would think it
| should be looking in my libltdl directory, not on the system, so that when
| someone gets my distribution they don't have to have libtool/libltdl
| installed on their system as a prerequisite. The examples given in the
| autobook all show calling libtool directly instead of with automake. I
| searched the mailing list archives for this list for "libltdl with automake"
| and didn't get anything germane. If it's supposed to be linking against the
| stuff in my libltdl library, then I have to use things like
| ../../libltdl/libltdlc. and ../../libltdl/ltdl.h in my source (#include) and
| makefiles, which just strikes me as I'm doing something wrong and missing
| something.
|
| Can anyone advise me?
Yes, if you `libtoolize --ltdl', it is so your project can use the in-tree
libltdl.
Your problem perhaps stems from your misuse of convenience libraries.
libltdlc.la (and all convenience libraries) is designed to be linked into
another library (into which its objects are copied). If you are linking into
a program, either create a static only libltdl.la and link against that, or
install your copy of libltdl into a package specific libdir.
You should have something like this in your libltdl using source's Makefile.am:
~ AM_CPPFLAGS = -I$(top_builddir)/libtldl -I$(top_srcdir)/libltdl
~ <executablename>_LDADD = -lltdl
Your other sources can then #include "ltdl.h".
HTH,
Gary.
- --
Gary V. Vaughan ())_. address@hidden,gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAfq7DFRMICSmD1gYRAgtKAKDAIxqlXQjxu5+8g1CNIKTrOOjzpACdGMT5
PJnxIv61TrYbP3Ia315sbHs=
=+ECO
-----END PGP SIGNATURE-----
------------------------------
Message: 8
Date: Thu, 15 Apr 2004 11:10:20 -0500 (CDT)
From: Bob Friesenhahn <address@hidden>
Subject: C linkage problem when C++ library is used.
To: address@hidden
Message-ID:
<address@hidden>
Content-Type: TEXT/PLAIN; charset=US-ASCII
If a program which is based on C language depends on a library which
is implemented in C++, the C++ compiler should be used to link the
program. Otherwise C++ static initialization may not work right, or
linking may fail entirely. Libtool doesn't currently offer any
provision to do that.
The installed .la file for a C++ library does not indicate the
implementation language, or what linker should be used. When the C++
library was built using modern GCC then libstdc++.la is listed as a
library dependency so at some clue may be gleaned from that fact.
It seems to me that this is a fundamental flaw in muti-lingual libtool
as it exists today.
Bob
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen
------------------------------
Message: 9
Date: Thu, 15 Apr 2004 10:50:41 -0700
From: Tristan Fillmore <address@hidden>
Subject: Re: Shared library support in Interix?
To: Todd Vierling <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain
On Thu, 2004-04-15 at 07:49, Todd Vierling wrote:
> There is a patch now on the libtool-patches list which implements Interix 3
> support. I created this in order to support libtool on Interix inside
> NetBSD's pkgsrc packaging system.
Great! But, maybe I'm dense but I'm having trouble finding it. I tried
searching the libtool-patches archive for "interix or interix3". Could
you tell me what I should be looking for, or forward me the patch?
Thanks,
Tristan
------------------------------
_______________________________________________
Libtool mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/libtool
End of Libtool Digest, Vol 17, Issue 11
***************************************
--- End Message ---