Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Subject: RE: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4BD8E.8F07DC4D" Content-class: urn:content-classes:message Date: Fri, 29 Oct 2004 10:09:03 +0200 Message-ID: <90459864DAD67D43BDD3D517DEFC2F7D029F31@axon.Axentia.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: From: "Peter Ekberg" To: Note-from-DJ: This may be spam ------_=_NextPart_001_01C4BD8E.8F07DC4D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Chuck wrote: > It seems like a design decision was made, that IF in a given project > there are ANY libtool libs, then libtool will "know" about it > by having > build_libtool_libs set to "yes". And thus, every executable is > *assumed* to be linked against those libs, and will therefore have a > wrapper and be linked against those shared libs. I have this feeling also. The right thing to do would perhaps be to not generate the wrapper in the first place, but that feels more complex than your proposal below... > Except in your case, you have ONE executable that is NOT > linked against > any shared libs...and the wrapper-check fails. >=20 > Maybe the right answer here is to change the check so that instead of >=20 > # Check the variables that should have been set. > test -z "$notinst_deplibs" && \ > func_fatal_error "invalid libtool wrapper script > \`$wrapper'"=20 >=20 > it checks for some other magic instead (which would need to > be added to > the "make a wrapper" code) >=20 > # Check the variables that should have been set. > test -z "$generated_by_libtool_version" && \ > func_fatal_error "invalid libtool wrapper script > \`$wrapper'"=20 >=20 > where the "make a wrapper" code ensures that the following assignment > appears in the wrapper=20 >=20 > ORIG> if test "$libtool_install_magic" =3D "%%%MAGIC variable%%%"; then > ORIG> # install mode needs the following variables: > ORIG> notinst_deplibs=3D.... > NEW > generated_by_libtool_version=3D$macro_version > ORIG> else >=20 >=20 > Our check wouldn't care about the actual VALUE of > $generated_by_libtool_version -- only that it was, in fact, set to > SOMETHING.=20 >=20 >=20 > Can't flesh this out anymore right now, but you get the idea... Yup, clear enough, here's a patch that does as you outlined. It even works :-). Thanks a bunch! Only one Cygwin related problem left on my list for libtool-1.9f, and that is linking a libtool shared lib against /usr/lib/w32api/libdxguid.a which is not recognized as an import lib (and probably isn't one either, I don't know). But it works to link a dll against it if I make it pass the import check by brute force... Any hints for that one? Cheers, Peter ------_=_NextPart_001_01C4BD8E.8F07DC4D Content-Type: application/octet-stream; name="install-nodeps-wrapper.patch" Content-Transfer-Encoding: base64 Content-Description: install-nodeps-wrapper.patch Content-Disposition: attachment; filename="install-nodeps-wrapper.patch" LS0tIGxpYnRvb2wtMS45Zi9jb25maWcvbHRtYWluLm00c2gub3JpZwkyMDA0 LTEwLTIyIDE5OjE5OjMzLjAwMDAwMDAwMCArMDIwMAorKysgbGlidG9vbC0x LjlmL2NvbmZpZy9sdG1haW4ubTRzaAkyMDA0LTEwLTI5IDA5OjI1OjA0LjY5 MDA5MTIwMCArMDIwMApAQCAtMTk1NSwxMSArMTk1NSwxMSBAQAogCSAgKi8q IHwgKlxcKikgLiAke3dyYXBwZXJkb3R9IDs7CiAJICAqKSAuIC4vJHt3cmFw cGVyZG90fSA7OwogCSAgZXNhYwogCiAJICAjIENoZWNrIHRoZSB2YXJpYWJs ZXMgdGhhdCBzaG91bGQgaGF2ZSBiZWVuIHNldC4KLQkgIHRlc3QgLXogIiRu b3RpbnN0X2RlcGxpYnMiICYmIFwKKwkgIHRlc3QgLXogIiRnZW5lcmF0ZWRf YnlfbGlidG9vbF92ZXJzaW9uIiAmJiBcCiAJICAgIGZ1bmNfZmF0YWxfZXJy b3IgImludmFsaWQgbGlidG9vbCB3cmFwcGVyIHNjcmlwdCBcYCR3cmFwcGVy JyIKIAogCSAgZmluYWxpemU9eWVzCiAJICBmb3IgbGliIGluICRub3RpbnN0 X2RlcGxpYnM7IGRvCiAJICAgICMgQ2hlY2sgdG8gc2VlIHRoYXQgZWFjaCBs aWJyYXJ5IGlzIGluc3RhbGxlZC4KQEAgLTU5OTEsMTEgKzU5OTEsMTIgQEAK IAogcmVsaW5rX2NvbW1hbmQ9XCIkcmVsaW5rX2NvbW1hbmRcIgogCiAjIFRo aXMgZW52aXJvbm1lbnQgdmFyaWFibGUgZGV0ZXJtaW5lcyBvdXIgb3BlcmF0 aW9uIG1vZGUuCiBpZiB0ZXN0IFwiXCRsaWJ0b29sX2luc3RhbGxfbWFnaWNc IiA9IFwiJG1hZ2ljXCI7IHRoZW4KLSAgIyBpbnN0YWxsIG1vZGUgbmVlZHMg dGhlIGZvbGxvd2luZyB2YXJpYWJsZToKKyAgIyBpbnN0YWxsIG1vZGUgbmVl ZHMgdGhlIGZvbGxvd2luZyB2YXJpYWJsZXM6CisgIGdlbmVyYXRlZF9ieV9s aWJ0b29sX3ZlcnNpb249JyRtYWNyb192ZXJzaW9uJwogICBub3RpbnN0X2Rl cGxpYnM9JyRub3RpbnN0X2RlcGxpYnMnCiBlbHNlCiAgICMgV2hlbiB3ZSBh cmUgc291cmNlZCBpbiBleGVjdXRlIG1vZGUsIFwkZmlsZSBhbmQgXCRFQ0hP IGFyZSBhbHJlYWR5IHNldC4KICAgaWYgdGVzdCBcIlwkbGlidG9vbF9leGVj dXRlX21hZ2ljXCIgIT0gXCIkbWFnaWNcIjsgdGhlbgogICAgIEVDSE89XCIk cWVjaG9cIgo= ------_=_NextPart_001_01C4BD8E.8F07DC4D Content-Type: text/plain; charset=us-ascii -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ------_=_NextPart_001_01C4BD8E.8F07DC4D--