From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BD317CDE00B for ; Fri, 26 Jun 2026 01:30:57 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 438CD10E2C5; Fri, 26 Jun 2026 01:30:57 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="mMgvjrrt"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) by gabe.freedesktop.org (Postfix) with ESMTPS id 72FB510E2C5 for ; Fri, 26 Jun 2026 01:30:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782437427; x=1813973427; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=W+qccgZ8jGLG5LfULNZtg6KfIn6IjUbdF9QoIgxY250=; b=mMgvjrrtH/Cs/ReN8UoA5Od3JeKWWhH5GnFT7eG6nPfWDB5Per3F8JYm kO91drS1w7CHoXwmbi3OtjrYvoAMUn6RLeXvGtQwadUSFlsqPcFU80oTB dTe9VtahkiPFCnYcqyvFSFgp0g/gDgwILcWqgXyNNZgr9kPsyUW6XO8AC f6MtETRTqtITnT3mNg9W7IB3vTiXTFhN/+wUIRtmz4mEFJOzY7owscd7u Hxun4/TjJwz+gGKt61i44CcplpA1jt9UdIJVtjm5xG8cu4AyR+dnUPR1X f38tN7YQwaawevtt8J24v01rYRWHijcOqU0M+lCk4T2KRNqc3rv3GXMuZ w==; X-CSE-ConnectionGUID: uNG8YUjLTPqTziy2L2833A== X-CSE-MsgGUID: vQoDEFZzQB6hMZmunC8E5g== X-IronPort-AV: E=McAfee;i="6800,10657,11828"; a="83432479" X-IronPort-AV: E=Sophos;i="6.24,225,1774335600"; d="scan'208";a="83432479" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jun 2026 18:30:27 -0700 X-CSE-ConnectionGUID: A+EvPMeeSg6Iu0UNZHCLag== X-CSE-MsgGUID: RA9aLi39TDexVf9fLdzW5w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,225,1774335600"; d="scan'208";a="250806662" Received: from imurzin-mobl.amr.corp.intel.com (HELO adixit-MOBL3.intel.com) ([10.125.128.71]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jun 2026 18:30:26 -0700 Date: Thu, 25 Jun 2026 18:30:26 -0700 Message-ID: <877bnmozpp.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: "Sebastian Brzezinka" Cc: , , , Subject: Re: [PATCH i-g-t 00/25] tools: remove unnecessary shared library In-Reply-To: References: <878q83q4od.wl-ashutosh.dixit@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: igt-dev@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development mailing list for IGT GPU Tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" On Thu, 25 Jun 2026 01:47:13 -0700, Sebastian Brzezinka wrote: > Hi Sebastian, > On Wed Jun 24, 2026 at 6:33 PM CEST, Ashutosh Dixit wrote: > > On Wed, 24 Jun 2026 01:47:07 -0700, Sebastian Brzezinka wrote: > >> > >> Standalone tools linked libigt.so as a side effect, pulling in cairo, > >> pixman and libX11 even without framebuffer use. > >> > >> Following intel_gpu_top's approach, each tool now links only the static > >> sub-libraries it needs. Five new ones are introduced: > >> > >> lib_igt_tools_stub, lib_igt_drm_stub, lib_igt_halffloat, > >> lib_i915_decode, lib_igt_reg_tools. > > > > So I am trying to figure out what is the "real" reason for doing this. > The motivation for this was explained in 2019, freedesktop bug > #110249, by Eero Tamminen: > > "It's annoying to need to install these redundant dependencies on > e.g. headless media transcoding server if one just wants to use > intel_gpu_top to monitor GPU utilization." > > Chris Wilson fixed intel_gpu_top back then and said "One down, the rest > left to an adventurous sole." This series finishes that job. Tools should > only link what they actually use. That's basic. intel_stepping does > not need Cairo. intel_backlight does not need ALSA. Yet today they > both pull in 30+ libraries through libigt.so. This series fixes that. > I shouldn't have to explain why a tool that reads a register shouldn't > depend on a graphics rendering library. > > > If tomorrow the tool uses a function which is not present in the tiny > > library but in the big library, what are we going to do? So, isn't it > > better to link against one big library, rather than tiny libraries? > > > If a tool needs new functionality in the future, we add it to the > appropriate sub-library or add a new dependency. That's a one-line meson > change, done intentionally, with a clear reason. > > That's better than the alternative: preemptively linking everything > against a library that drags in Cairo, ALSA, X11 and 35 other things > "just in case" someone someday needs something from it. > > > Since it should use dynamic linking, it is not that the size of the > > executable will change one way or the other. > > > The point is not executable size. The point is runtime dependencies > what needs to be installed on the system for the tool to run at all. > > With libigt.so as a dynamic dependency, you cannot run intel_stepping > on a headless server without first installing Cairo, X11, ALSA, freetype > and 35 other libraries that the tool has absolutely no use for. > > After this series, you just run the tool. Nothing extra needed. OK, because you are linking statically I think. > > > So what is driving this change? Maybe I am missing something. > I appreciate the question, sorry for not including the link in the cover > letter. This issue was raised by the community back in 2019 and is well > documented here: https://bugs.freedesktop.org/show_bug.cgi?id=110249 Thanks for the detailed explanations, the series is: Acked-by: Ashutosh Dixit Thanks. -- Ashutosh