From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114444 invoked by alias); 5 Feb 2018 17:45:01 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 114255 invoked by uid 89); 5 Feb 2018 17:45:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:3892597, H*f:sk:3892597, Best X-HELO: mail-wm0-f45.google.com Received: from mail-wm0-f45.google.com (HELO mail-wm0-f45.google.com) (74.125.82.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 05 Feb 2018 17:44:58 +0000 Received: by mail-wm0-f45.google.com with SMTP id 141so27405554wme.3 for ; Mon, 05 Feb 2018 09:44:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:from:message-id; bh=dydBdnmViyWVTVjtL3U0XVn4BicZ4rzwP4L8i6xxQR8=; b=ET2HvdFpJfWO0PXZYd3VSXntJRlVHp1Y8M+mzhRhJ4YUoob785kb2/8pgf0ZwyrOzb XecjDyJInESPVICSvkr7cIhCFm7QMnrWkbOU60noOE5xfJ9EFvvfS2LhZBbu1MRu5Izo 4QT/Gyhi4jR4PuRydsfUe28eT8fNTBYS/O+LM0QkWj7RyLZHpAz7yKFjg81b/xsxCl32 zBSJrwJgjXDuf0f8xi9rqDrrapUuo2YhMNpYNAs7UcIuIjNOPIq4y34zqfzB7HqAah+8 3oIAVsu/qEVUFtU7hbNtx+I+iJKoq1e1MuCWi4fdwVSSNynG3tQQxihkps3IpCRGSdjI nHtw== X-Gm-Message-State: APf1xPBgO+zv3cqXm34iPiRqSNiPcRIVltSCsmVlfyYvMDgxc7T9v2hl 1LEwB8AoMXCpHs/Ho829dvov4R0B X-Google-Smtp-Source: AH8x2250wA/lucNKWZCcVUxINMuwlLV3J/zfsHUIV1tS+VvPbTP0ydbmezEauZrDiQ5y/AtaXAPd1Q== X-Received: by 10.28.86.131 with SMTP id k125mr82855wmb.83.1517852695739; Mon, 05 Feb 2018 09:44:55 -0800 (PST) Received: from android-97b5c0ce9bfced28.fritz.box (p2E530D94.dip0.t-ipconnect.de. [46.83.13.148]) by smtp.gmail.com with ESMTPSA id a6sm12904623wri.10.2018.02.05.09.44.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Feb 2018 09:44:54 -0800 (PST) Date: Mon, 05 Feb 2018 17:45:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <38925973.88kXsFSiyi@twilight> References: <38925973.88kXsFSiyi@twilight> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Resolving LTO symbols for static library boundary To: gcc@gcc.gnu.org,Allan Sandfeld Jensen ,jh@suse.cz From: Richard Biener Message-ID: <68CCCBEA-05E1-4C80-B06C-9068FD1DD912@gmail.com> X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00033.txt.bz2 On February 5, 2018 12:26:58 PM GMT+01:00, Allan Sandfeld Jensen wrote: >Hello GCC > >In trying to make it possible to use LTO for distro-builds of Qt, I >have again=20 >hit the problem of static libraries. In Qt in general we for LTO rely >on a=20 >library boundary, where LTO gets resolved when generating the library >but no=20 >LTO-symbols are exported in the shared library. This ensure the library >has a=20 >well defined binary compatible interface and gets LTO optimizations >within=20 >each library. For some private libraries we use static libraries >however,=20 >because we don't need binary compatibility, but though we don't need BC > >between Qt versions, the libraries should still be linkable with >different gcc=20 >versions (and with different compilers). However when LTO is enabled >the=20 >static libraries will contain definitions that depend on a single gcc >version=20 >making it unsuitable for distribution. > >One solution is to enable fat-lto object files for static libraries but >that=20 >is both a waste of space and compile time, and disables any LTO >optimization=20 >within the library. Ideally I would like to have the static library do >LTO=20 >optimizations internally just like a shared library, but then exported >as=20 >static library. > >I suspect this is more of gcc task than ar/ld task, as it basically >boils down=20 >to gcc doing for a static library what it does for shared library, but >maybe=20 >export the result as a single combined .o file, that can then be ar'ed >into a=20 >compatible static library. > >Is this possible? Hmm. I think you could partially link the static archive contents into a si= ngle relocatable object. Or we could add a mode where you do a 1to1 LTO lin= k of the objects and stop at the ltrans object files. You could stuff those= into an archive again.=20 I'm not sure how far Honza got partial LTO linking to work?=20 Richard.=20 >Best regards >'Allan Jensen