From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id c2175cef for ; Mon, 31 Dec 2018 17:51:27 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 7499BAF364; Tue, 1 Jan 2019 03:51:26 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 34648AF363; Tue, 1 Jan 2019 03:51:10 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="rMWwfJ3r"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id C5D45AF363; Tue, 1 Jan 2019 03:51:08 +1000 (AEST) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by minnie.tuhs.org (Postfix) with ESMTPS id 1418A94140 for ; Tue, 1 Jan 2019 03:51:08 +1000 (AEST) Received: by mail-lj1-f177.google.com with SMTP id c19-v6so24022634lja.5 for ; Mon, 31 Dec 2018 09:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Igs4OKts2adlwiK4EVMbUsbaJ5S0VekY+Pj1tHdw7Jk=; b=rMWwfJ3rY95ZVhc5nlzd8zQZylyYEFGduFhqIhxaIZQyUgpSMp2TdgQHBcvtXxjrbv M0kPWAzaHRJv2kM3z2wGmE7EA/fghjMM2bqEHxh21qQNH3OBZ0JtQ6TGEuVC1HyoKncg M9wQNI36iTRrno3LxxqRxqdwjPcZiHqLwfTGl10gly8HwdQIlSAn3tIO1emFZKn+R36G TDd/Okha43HYY/EO+HB23HL4dZQc52PkuIT83T+Qy7/06S0z9wiqKxbDUjYNenhcjy6S zwbxhN9TZiciyO80uOOzitvOXW+iIF5vvOy0zNT2CUe9vjbFgsMORU3oSRDTIDxoKHa5 0JQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Igs4OKts2adlwiK4EVMbUsbaJ5S0VekY+Pj1tHdw7Jk=; b=IyBY5RvOscN1KE9ic4zAfA36QDM4oInQfnQDiGyUoHrNCqHKPpd+vpXB8Ycfx9hv/W OGFpzRidBylDyEHcg6ZYCL3MEcXuDFSH3nCPHgXUvbhBTVIEBgbUyOCVaIGv9c0SOp45 FgijxWbpXDnoihVz4UPov0NfMsyWsxx4VHYvcqmEjS6XAcmuSWL9rRnW2s2YbdhFvqoi 6KjPxR4EVH/t6M8kxn2747Ojebtx2aFiR3RyFGJO+KKD8sKiEr30tBpiCcefEVbg+YzD ZHgsCynA+U6pG2otytL434NUdDqJjGhmF1rhgK6exEYae+sx4h1rMiGi/p50RqWbstIO tmqg== X-Gm-Message-State: AJcUukc92oVGFgheFoxfR4Q6Q8RQjMgEEGnBMvHT9KZ9KozNBZpXqiGv rncnFNcGkbKNC4Q/ukvIuLdAA3TpSaEiB2m8Wts= X-Google-Smtp-Source: ALg8bN4rdFSTJC05HrJZAwgSUOz1kgS47gcCEejwAyvTMbCAxozWiyMnNXs9y0CK8GXPY9GghqlFyWjGy+7P7MeciCE= X-Received: by 2002:a2e:8156:: with SMTP id t22-v6mr1180263ljg.32.1546278666287; Mon, 31 Dec 2018 09:51:06 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a2e:3a11:0:0:0:0:0 with HTTP; Mon, 31 Dec 2018 09:51:05 -0800 (PST) In-Reply-To: <401865440.113885.1546214417318.JavaMail.tomcat@india-live-be01> References: <20181229010900.19F6218C074@mercury.lcs.mit.edu> <401865440.113885.1546214417318.JavaMail.tomcat@india-live-be01> From: Paul Winalski Date: Mon, 31 Dec 2018 12:51:05 -0500 Message-ID: To: Donald ODona Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] Deleted lib1 and lib2 in v6, recoverable? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs@minnie.tuhs.org, Noel Chiappa Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 12/30/18, Donald ODona wrote: > > > At 30 Dec 2018 18:35:22 +0000 (+00:00) from Paul Winalski > : >> >> Sometimes one runs into a situation where a module loaded from lib1.a >> has an undefined symbol that causes a module from lib2.a to be loaded, >> and that module in turn has an undefined symbol that is defined in >> lib1.a. In that case, you have to cause the linker to scan lib1.a >> twice: >> >> ld main.o lib1.a lib2.a lib1.a >> > thats not true, because the M$ and borland linkers of the 80ths under > MSDOS(sic!) already processed indexed libraries. Therefore the multiple > inclusion of libraries wans'nt needed. > No, you still need multiple inclusion in that situation. Consider this situation: main.o has an undefined reference to s1 m1.o in lib1.a defines s1 and has an undefined reference to s2 m3.o in lib1.a defines s3 m2.o in lib2.a defines s2 and has an undefined reference to s3 The command line is: ld main.o lib1.a lib2.a The linker makes one or more passes over the index of lib1.a until no more symbols are resolved. The linker loads m1.o. It does not load m3.o because m3.o doesn't resolve any outstanding undefined references. The linker still has s2 undefined. It now makes one or more passes over the index of lib2.a until no more symbols are resolved. In the process it loads m2.o to resolve s2 and adds s3 to the list of unresolved symbols. After lib2.a is processed, s3 is still undefined, and ld has nothing left to process. ld will issue an "unresolved symbol" error message for s3. You need to specify lib1.a a second time to cause ld to scan it again. -Paul W.