libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[zzSPAM] Javascript Junkmail-Notify (Javascript(pain meds))


From: zzHQMAIL1
Subject: [zzSPAM] Javascript Junkmail-Notify (Javascript(pain meds))
Date: Fri, 30 Apr 2004 01:12:41 -0700

************* eManager Notification **************

Javascript Junkmail Notify

Source mailbox: "address@hidden"
Destination mailbox(es): "address@hidden"
Policy: Javascript(pain meds)
Action: Delete

******************* End of message *******************
--- Begin Message --- Subject: Libtool Digest, Vol 17, Issue 22
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. [zzSPAM] Javascript Junkmail-Notify (Javascript(pain meds))
      (address@hidden)
   2. Re: building libtool libraries for multiple ABIs (Tim Mooney)
   3. Re: building libtool libraries for multiple ABIs (Albert Chin)
   4. Visit our Internet pharmacy, buy V?agra and many other meds.
      (Angel Arroyo)
   5. Re: libtoolize and AC_CONFIG_SUBDIRS (Gary V.Vaughan)


----------------------------------------------------------------------

Message: 1
Date: Thu, 29 Apr 2004 12:57:19 -0700
From: address@hidden
Subject: [zzSPAM] Javascript Junkmail-Notify (Javascript(pain meds))
To: <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

************* eManager Notification **************

Javascript Junkmail Notify

Source mailbox: "address@hidden"
Destination mailbox(es): "address@hidden"
Policy: Javascript(pain meds)
Action: Delete

******************* End of message *******************
-------------- next part --------------
An embedded message was scrubbed...
From: address@hidden
Subject: Libtool Digest, Vol 17, Issue 21
Date: no date
Size: 17957
Url: 
http://mail.gnu.org/pipermail/libtool/attachments/20040429/199e76e8/attachment.mht

------------------------------

Message: 2
Date: Thu, 29 Apr 2004 15:55:20 -0500 (CDT)
From: Tim Mooney <address@hidden>
Subject: Re: building libtool libraries for multiple ABIs
To: address@hidden
Message-ID:
        <address@hidden>
Content-Type: TEXT/PLAIN; charset=US-ASCII

In regard to: Re: building libtool libraries for multiple ABIs, Albert Chin...:

>On Tue, Apr 27, 2004 at 04:58:54PM -0500, Tim Mooney wrote:
>>
>> If you want to build and install a local package (take for example GSL,
>> the GNU Scientific Library) that builds a library via libtool, what are
>> people doing to have the library built for each ABI that a platform may
>> support?  Has anyone found a better method than configuring the package,
>> building and installing once, then reconfiguring with CFLAGS and LDFLAGS
>> set for a different ABI and overridding the library directory, and
>> building and installing again?  This can become a pretty tiresome
>> process, especially if you also package your local software (such as
>> with RPM) and install the package.
>>
>> How are other people dealing with this issue?
>
>What other solution is there than rebuilding?

I haven't found one, but I was hoping someone else had.  I guess the
question I have is, "Is this something that some future version of libtool
should support naturally and automatically?".  Libtool is already building
two kinds of libraries (archive and shared) with two kinds of object files
(non-PIC and PIC) on platforms where those distinctions exist.  Should
another "factor" be added, so that libtool will (optionally) build those
two kinds of libraries for N (where N is commonly 2) kinds of ABIs, on a
platform that supports multiple ABIs?

> When we build software,
>we build most packages to a _separate_ directory. So, for GSL, we have
>something like /opt/libgsl13 and /opt/libgsl14. When we build 64-bit
>versions of these, we build as usual but set
>--libdir=/opt/libgsl13/lib/64.

Exactly what I figured I would have to do, but if (and it's a big if) it
were decided that libtool should support multiple ABIs, it would seem that
libtool could handle that bit automatically, and you could again go back
to a simple

        configure --prefix=/opt/libgsl14 --exec-prefix=/opt/libgsl14
        make
        make install


Anyway, I appreciate your comments.  You've verified for me that there's
probably not some magically easy way to do this that I'm just not seeing.

Tim
-- 
Tim Mooney                              address@hidden
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164




------------------------------

Message: 3
Date: Thu, 29 Apr 2004 17:40:10 -0500
From: Albert Chin <address@hidden>
Subject: Re: building libtool libraries for multiple ABIs
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii

On Thu, Apr 29, 2004 at 03:55:20PM -0500, Tim Mooney wrote:
> I haven't found one, but I was hoping someone else had.  I guess the
> question I have is, "Is this something that some future version of libtool
> should support naturally and automatically?".  Libtool is already building
> two kinds of libraries (archive and shared) with two kinds of object files
> (non-PIC and PIC) on platforms where those distinctions exist.  Should
> another "factor" be added, so that libtool will (optionally) build those
> two kinds of libraries for N (where N is commonly 2) kinds of ABIs, on a
> platform that supports multiple ABIs?

I don't think libtool should support this. What if you wanted to build
a 64-bit version of libpng which depends on libz? How do you specify
the path to the 64-bit libz? libtool cannot fully support what you
want.

I'm in favor of keeping things simple as they are now.

-- 
albert chin (address@hidden)




------------------------------

Message: 4
Date: Thu, 29 Apr 2004 23:29:09 -0600
From: "Angel Arroyo" <address@hidden>
Subject: Visit our Internet pharmacy, buy V?agra and many other meds.
To: address@hidden, address@hidden, address@hidden,
        address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"

An HTML attachment was scrubbed...
URL: 
http://mail.gnu.org/pipermail/libtool/attachments/20040429/71a0f816/attachment.htm

------------------------------

Message: 5
Date: Fri, 30 Apr 2004 08:49:07 +0100
From: Gary V.Vaughan <address@hidden>
Subject: Re: libtoolize and AC_CONFIG_SUBDIRS
To: Braden McDaniel <address@hidden>
Cc: address@hidden, address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Braden,

On 29 Apr 2004, at 19:35, Braden McDaniel wrote:
> Some issues related to use of CVS libtool with AC_CONFIG_SUBDIRS:
>
>   1. libtoolize doesn't appear to recurse into AC_CONFIG_SUBDIRS. 
> Should
>      it? Or is this autoreconf's job?

Autoreconf's job.

>   2. I cannot get CVS autoreconf to work at all with CVS libtool.
>      Perhaps this is a Known Issue; but I haven't seen it mentioned.

I have CVS autoconf from a few weeks ago installed and autoreconf works
for me.  I'll cvs up and recheck.

>   3. If I execute libtoolize in the subpackage root directory, it seems
>      to "know" that AC_CONFIG_AUX_DIR should be "..". I don't 
> explicitly
>      use the AC_CONFIG_AUX_DIR macro anywhere, so I'm guessing
>      libtoolize does some sniffing. Perhaps it should do something
>      similar for AC_CONFIG_MACRO_DIR? (That is, use the main package's
>      AC_CONFIG_MACRO_DIR if none is set in the subpackage's
>      configure.ac.)

That is autoconf simply tracking back up the tree looking for install-sh
if AC_CONFIG_AUX_DIR is not set in the subpackage.  Libtool doesn't do
anything special for either.

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 (Darwin)

iD8DBQFAkgT3FRMICSmD1gYRAg2WAJkBjc93Cx813/97uimorBTiTpECcACbBGe/
7gziI9WhPBYQNC/IztRhid8=
=Il57
-----END PGP SIGNATURE-----





------------------------------

_______________________________________________
Libtool mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/libtool


End of Libtool Digest, Vol 17, Issue 22
***************************************

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]