************* eManager Notification ************** Junkmail Notify
Source mailbox: "[EMAIL PROTECTED]" Destination mailbox(es): "[EMAIL PROTECTED]" Policy: Javascript(doctorate (phd)) Action: Delete ******************* End of message *******************
--- Begin Message ---Send Libtool mailing list submissions to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Libtool digest..." Today's Topics: 1. [zzSPAM] Junkmail-Notify (Javascript(doctorate (phd) diploma)) ([EMAIL PROTECTED]) 2. Re: Shared library support in Interix? (Todd Vierling) 3. Re: C linkage problem when C++ library is used. (Albert Chin) 4. Re: C linkage problem when C++ library is used. (Braden McDaniel) 5. Re: C linkage problem when C++ library is used. (Bob Friesenhahn) 6. Re: C linkage problem when C++ library is used. (Patrick Welche) ---------------------------------------------------------------------- Message: 1 Date: Thu, 15 Apr 2004 11:02:18 -0700 From: [EMAIL PROTECTED] Subject: [zzSPAM] Junkmail-Notify (Javascript(doctorate (phd) diploma)) To: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" ************* eManager Notification ************** Junkmail Notify Source mailbox: "[EMAIL PROTECTED]" Destination mailbox(es): "[EMAIL PROTECTED]" Policy: Javascript(doctorate (phd) diploma) Action: Delete ******************* End of message ******************* -------------- next part -------------- An embedded message was scrubbed... From: [EMAIL PROTECTED] Subject: Libtool Digest, Vol 17, Issue 11 Date: no date Size: 13919 Url: http://mail.gnu.org/pipermail/libtool/attachments/20040415/d3ef5530/attachment.mht ------------------------------ Message: 2 Date: Thu, 15 Apr 2004 14:20:22 -0400 (EDT) From: Todd Vierling <[EMAIL PROTECTED]> Subject: Re: Shared library support in Interix? To: Tristan Fillmore <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 15 Apr 2004, Tristan Fillmore 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? Grrr. It seems that mailman doesn't like me. I believe it didn't allow through the messages I sent because I had this address set to no mail delivery. (I typically do this with mailman so I can have a tagged address receive the mail for pre-sorting with procmail.) I'll send it again shortly if it doesn't show up soon. I'm rather hoping it ended up in the moderator's approval queue and will be forwarded from there.... -- -- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ------------------------------ Message: 3 Date: Fri, 16 Apr 2004 14:21:11 -0500 From: Albert Chin <[EMAIL PROTECTED]> Subject: Re: C linkage problem when C++ library is used. To: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii On Thu, Apr 15, 2004 at 11:10:20AM -0500, Bob Friesenhahn wrote: > 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. Shouldn't the developer be responsible for using the C++ compiler rather than the C compiler? Why should libtool solve this? Without libtool, the developer should be using the C++ compiler to link anyway. -- albert chin ([EMAIL PROTECTED]) ------------------------------ Message: 4 Date: Thu, 15 Apr 2004 15:41:35 -0400 From: Braden McDaniel <[EMAIL PROTECTED]> Subject: Re: C linkage problem when C++ library is used. To: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii; format=flowed Albert Chin wrote: > On Thu, Apr 15, 2004 at 11:10:20AM -0500, Bob Friesenhahn wrote: > >>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. > > > Shouldn't the developer be responsible for using the C++ compiler > rather than the C compiler? Why should libtool solve this? Without > libtool, the developer should be using the C++ compiler to link > anyway. Perhaps this is an automake problem? That is, I don't think it uses CXXLINK--or even generates the variable--in the Makefile.in if it only sees C sources in the Makefile.am. Perhaps there needs to be some way to tell automake, "use the C++ linker for this." Braden ------------------------------ Message: 5 Date: Thu, 15 Apr 2004 14:43:57 -0500 (CDT) From: Bob Friesenhahn <[EMAIL PROTECTED]> Subject: Re: C linkage problem when C++ library is used. To: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 16 Apr 2004, Albert Chin wrote: > On Thu, Apr 15, 2004 at 11:10:20AM -0500, Bob Friesenhahn wrote: > > 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. > > Shouldn't the developer be responsible for using the C++ compiler > rather than the C compiler? Why should libtool solve this? Without > libtool, the developer should be using the C++ compiler to link > anyway. The "developer" is not necessarily aware of all the library dependencies since she may not be responsible for the maintenance of these libraries, or how they are configured. Perhaps in some cases a C-based widget library is used, while in other cases a C++-based widget library is used. Another unfortunate issue is that when the developer provides a .c file to Automake, Automake will automatically apply the rules necessary to compile and link a C source file. However, if a C++ library is used which was built using libtool, then libtool should be aware that C++ is now in the picture and thus C++ linkage is needed. Without this support in libtool, whether an application links, or successfully runs after linking is platform dependent. Bob ====================================== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ------------------------------ Message: 6 Date: Thu, 15 Apr 2004 21:00:10 +0100 From: Patrick Welche <[EMAIL PROTECTED]> Subject: Re: C linkage problem when C++ library is used. To: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii On Fri, Apr 16, 2004 at 02:21:11PM -0500, Albert Chin wrote: > On Thu, Apr 15, 2004 at 11:10:20AM -0500, Bob Friesenhahn wrote: > > 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. > > Shouldn't the developer be responsible for using the C++ compiler > rather than the C compiler? Why should libtool solve this? Without > libtool, the developer should be using the C++ compiler to link > anyway. Imagine the scenario in which a software package may optionally depend on libraries to extend its capabilities. Everyone is merrily using the C compiler, until the day it turns out that one of those optional libraries is written in C++, then everything suddenly must be linked with C++? Is it a goal for libtool to be able to scrape together object files compiled from multiple languages together into one executable? (--tag=FORTRAN -lfortlib --tag=C++ -lsomecxxlib ?) Cheers, Patrick ------------------------------ _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool End of Libtool Digest, Vol 17, Issue 12 ***************************************
--- End Message ---
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
