AWARD NOTIFICATION
WERKEN BIJ DE LOTTO, 41132, NL-1007 DB AMSTERDAM, THE NETHERLANDS. FROM: THE DESK OF THE DIRECTOR PROMOTIONS, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: WBL/67-B773524441 ATTN: AWARD NOTIFICATION; FINAL NOTICE We are pleased to inform you of the announcement today, 21ST OCTOBER. 2002, of winners of the WERKEN BIJ DE LOTTO/ INTERNATIONAL PROGRAMS held on 19TH MAY 2002. You / your company, attached to ticket number 013-2316-2002-477, with serial number A025-09 drew the lucky numbers 37-13-34-85-56-42, and consequently won in category C. You have therefore been approved for a lump sum pay out of US$1,500,000.00 in cash credited to file REF NO. REF: WBL/67-B773524441. This is from total prize money of US$22,500,000.00 shared among the fifteen international winners in the category C. All participants were selected through a computer ballot system drawn from 30,000 names from Australia, New Zealand, America, Asia, Europe,USA and North America as part our International Promotions Program, which is conducted annually. CONGRATULATIONS! Your fund is now deposited with a Finance and Security House and insured in your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes US$1.3 billion International lotto. To begin your claim, please contact your claims officer immediately: JANSEN DAVIS FOREIGN SERVICE MANAGER, EUROLITE BV, PHONE:31-619676795 TEL/FAX: 31 205241590 FAX: 31 205248221 EMAIL:[EMAIL PROTECTED] For due processing and remittance of your prize money to a designated account of your choice. Remember, you must contact your claims officer not later than OCTOBER 27th, 2002. After this date, all funds will be returned as unclaimed. All correspondences to Mr. Jansen Davis,either by fax or email, should have this email sent along with it and also, your email address to which this email is sent, should be clearly and boldly written in your response. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference number in every one of your correspondences with your officer. Furthermore, should there be any change of your address, do inform your claims officer as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions program. Sincerely, THE DIRECTOR PROMOTIONS, WERKEN BIJ DE LOTTO. www.werken-bij-delotto.net N.B. Any breach of confidentiality on the part of the winners will result to disqualification. Please do not reply this mail. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Proposed libtool patch for MinGW
Bob Friesenhahn [EMAIL PROTECTED] wrote in news:Pine.GSO.4.44.0210151350390.21156-20;scooby.simplesystems.org: The attached patch to FSF CVS libtool is intended to make libtool (mostly) behave as it does for Cygwin when executed with MinGW. It consists of contributions from Elizabeth Barham, and my own efforts. The DLLs are installed to $(libdir)/../bin as they currently are under Cygwin. Any change to this scheme should be common to both Cygwin MinGW unless there is a reason for behaving differently. This patch allows a shared library build of ImageMagick (using both C C++) to successfully build and install under MinGW using the MSYS shell environment. I have not tried to build libtool modules with it yet (should be interesting). I just want to write *congratulations* on this Bob, as I am recollecting our conversations early this year in which it was mentioned by you that this was a goal you wished to see accomplished (and which seemed to be a substantial way off from being do-able at that point). You really have my respect and admiration (for whatever that's worth) for the persistance and dedicated effort you've put into many phases of making this happen: pointing out problems you've had with msys, working on libtool, etc. You've set a great example of not just waiting around for somebody else to fix things, but wading right in with spanner and hammer and soldering iron and not giving up until you've got it all working. I am looking forward to building I~M~ soon on MSYS using DLLs. One question which is totally up to you to reply to if you feel you have time, is that I am not sure about a semantic meaning in your message. It may reflect my still-incomplete grasp of 'libtool', but ... what precisely do you mean by build libtool modules with it? What it is that you haven't got working yet that could be working, for I~M~?? You did mean at top, that I~M~'s modules were being built as shared libs (DLLs) now, right? Best Regards, Soren A ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Earnie Boyd [EMAIL PROTECTED] wrote in news:3DAC41A9.3070503;yahoo.com: Bob Friesenhahn wrote: If libtool was intended to be an extension of Autoconf/Automake, then it should certainly have been absorbed into Automake, and not exist as a stand-alone utility at all. Do you have examples of libtool use without autoconf and/or automake? Why does libtool.m4 get installed into share/aclocal/? AFAIK, libtool without autoconf/automake doesn't exist. Earnie. Echo. I don't dispute that Bob might be correct but TTBOMK this is not _common_ knowledge. After extensively messing around with building a libtool from GNU cvs within the last 3 weeks, I can say that I see no means by which libtool can readily be used anymore without Autoconf and Automake being involved. Because they've nuked ltconfig, libtool seems much less a stand-alone tool now. It seems as if the intention of the PTB is that libtool shall become a de-facto extension of Automake. I'd really like to know about examples of current libtool usage that exercize libtool independently (in the absense of) Automake. It should be noted that I emphasize the amount of time I spent getting a libtool built from cvs source because I approached the whole thing in order to try to learn as much as I possibly could about libtool all in one deliberate, thorough effort (something I've avoided doing for a long time). In the course of this I found myself *VERY* annoyed by the fact that the libtool manual at GNU.org is completely out of date WRT the present structure of libtool. Also, the Autobook which readers should probably be familiar with, that is hosted at RedHat.com, is also out of date WRT the use of libtool as part of the Autotools. Both documents talk about 'ltconfig' which no longer exists. So it's about as clear as mud that libtool can even be used at all anymore without Automake being involved. It seems like the original intention of libtool's author has been subverted in fact? If somebody reading this experiences a reactive impulse to the words annoyance and documentation and the reflex action of posting a well its Free software you aren't paying for it why don't you write better documentation and contribute it instead of griping kind of response, you can go take a flying leap AFAIAC. To be able to write documentation for something you have to first UNDERSTAND the thing and it seems impossible or nearly impossible to come to understand how 'libtool' now works (if you haven't been developing it all along) anymore. The manual for libtool actually made good reading and seemed splendidly clear, made me want to use the software. Then I discovered that the manual has nothing much to do with reality anymore, it describes software that no longer exists (that is no longer currently being used / developed). Somebody who has been developing libtool all along has GOT TO take on the job of updating the user documentation for that mess. It's gotten far too complex for some new person to wade in and try to explain it clearly. There's moaning needs, crying needs and then there's SCREAMING needs. Updated documentation for libtool is of the lattermost variety. All IMHO. Soren A -- What do Internet Mailing Lists and crowded neighborhoods have in common? Both will either drive you out or teach you how to ignore barking dogs. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Soren A [EMAIL PROTECTED] writes: Echo. I don't dispute that Bob might be correct but TTBOMK this is not _common_ knowledge. After extensively messing around with building a libtool from GNU cvs within the last 3 weeks, I can say that I see no means by which libtool can readily be used anymore without Autoconf and Automake being involved. I can't comment on using it without Autoconf, but INN uses libtool and doesn't use Automake. That's not particularly difficult to do, at least for the simple cases. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
On Mon, 21 Oct 2002, Soren A wrote: Do you have examples of libtool use without autoconf and/or automake? Why does libtool.m4 get installed into share/aclocal/? AFAIK, libtool without autoconf/automake doesn't exist. Echo. I don't dispute that Bob might be correct but TTBOMK this is not _common_ knowledge. After extensively messing around with building a libtool from GNU cvs within the last 3 weeks, I can say that I see no means by which libtool can readily be used anymore without Autoconf and Automake being involved. Because they've nuked ltconfig, libtool seems This means that you are missing a major point about libtool, and one that was considered to be vital by the original libtool author (Gordon Matzigkeit). The user can download the libtool package, do a 'configure', 'make', and 'make install', and then use libtool just as described in the libtool user manual. Sure, the libtool package itself uses Autoconf/Automake, but once it is installed, libtool is just a utility like any other utility. PTB is that libtool shall become a de-facto extension of Automake. I'd really like to know about examples of current libtool usage that exercize libtool independently (in the absense of) Automake. The FreeType library and libjpeg both use libtool without Automake. The FreeType folks even go to the extent of using something besides `make' (JAM). its Free software you aren't paying for it why don't you write better documentation and contribute it instead of griping kind of response, you can go take a flying leap AFAIAC. To be able to write documentation for something you have to first UNDERSTAND the thing and it seems impossible or nearly impossible to come to understand how 'libtool' now works (if you haven't been developing it all along) anymore. The manual for libtool actually made good reading and seemed splendidly clear, made me want to use the software. Then I discovered that the manual has nothing much to do with reality anymore, it describes software that no longer exists (that is no longer currently being used / developed). If there is a deficiency, then please submit a patch to correct it, or at least report the *specific* deficiency so it can be fixed. Somebody who has been developing libtool all along has GOT TO take on the job of updating the user documentation for that mess. It's gotten far too complex for some new person to wade in and try to explain it clearly. There's moaning needs, crying needs and then there's SCREAMING needs. Updated documentation for libtool is of the lattermost variety. I refer to the libtool documentation often, and it has rarely led me astray. By the way, CVS libtool now works under MinGW, so you should be much happier about it. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
