From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92654 invoked by alias); 7 Jun 2018 08:01:50 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 92603 invoked by uid 89); 7 Jun 2018 08:01:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-oi0-f65.google.com Received: from mail-oi0-f65.google.com (HELO mail-oi0-f65.google.com) (209.85.218.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Jun 2018 08:01:45 +0000 Received: by mail-oi0-f65.google.com with SMTP id 14-v6so7784612oie.3 for ; Thu, 07 Jun 2018 01:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=X9QGet1gf9GryNvQCkXPHGA3HgC7q4XyCuxfPDC7UhA=; b=t1HZSqfIr1TD0iMahrOiCFaG4z94UaVQtXNZbsW2AAouwrcGgpJleoZQZMNmb9y9KB bERXJhpPMKShPfuyoVQUDhB2RjTpdrKvlHVWXW2SLNp6qtrwomkN+IbhcoZS/TSVRxyA B+Pl8+zCv0kUN1Ia+bJKUVuMjTkbx1E4lS7NwnlDD3BGt6pdwh3GlzZzAQgVdZdCjdhz xWVImDSBodtRPX/yaMrMrgMQFzk10M2smvFqfe0u9Gnds+pR49B6uRwg9UOIkc28e1I/ hAowezqUTSaxOCPtJSM5pr59zpAqQIT0a/RCs+UIq/fRgt3BOPWb8q2rRTjeJkojvU9h hObA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=X9QGet1gf9GryNvQCkXPHGA3HgC7q4XyCuxfPDC7UhA=; b=Oiln4RAH394reLOFFF22ok8kKxMuLZEeJi21ekS0d8j2Im49Z1ktTAwAOqjmyg/0eY iTCUtA5V64ErReCOMvv65DoS0TcxCUTg38pEZjqQWsDtyEu/Pjn0eCuNlm6ZUGkcyeVp 6IKznEjndzMk86Rgu1akOv0tq4xfzgITJO77tQN5bCwyHEKLtTJqUZ8rIRLocVFKB9HA IMAJHULhKoUk39yo0k09Ly6q42lZTyHQ8wkqFeydT3nBOo1wp4Wbb/B+HRDIyl/Hv0uL K8OdIxQ/+RYtMiVg4n2iNikTwA3QB7ovq3mId7d2+NJsX2BjbTulipe3UHaLOBf3pcm5 nJAQ== X-Gm-Message-State: APt69E19veOysN5CBRDBs/PB0IBfkeA2wZlJnWN7fnSIMK9L3Ubh0YIZ DqgER3x9DRN43aJpI4y3OBvYywX6/CkoQAVwvsC8wg== X-Google-Smtp-Source: ADUXVKI5wZGS7YabRThv8GBsgi7zwjAmPpvrD4JHz8z4eNRx9px//FYSrO/F0jGbttNdJyxRL/Md71rkTk5/phPVQ/0= X-Received: by 2002:aca:4ed1:: with SMTP id c200-v6mr324678oib.278.1528358503534; Thu, 07 Jun 2018 01:01:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:39cb:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 01:01:43 -0700 (PDT) From: Laurent Stacul Date: Thu, 07 Jun 2018 08:01:00 -0000 Message-ID: Subject: On demand static/shared libs and binary linkage To: elfutils-devel@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q2/txt/msg00163.txt.bz2 Hello, I am quite new on elfutils library. I know their were discussions in the past about the question I will ask but let me introduce my use case. I am working on a project which aims at building some kind of "standalone" toolchain (binutils, gcc, clang + tools like gdb, valgrind). This toolchain could be shipped easily on any linux machines by copying files on the targeted machine. To ease this, the tools binaries are statically linked to avoid any interferences with user local LD_LIBRARY_PATH environment variable. I am planning to add elfutils to this toolchain. The provided binaries are useful and the delivered libs are a prerequisite for libabigail (which I plan to also add). I can see there is no flag to chose between static and shared. >From my investigations in the code and the build system: - the delivered libs cannot be 100% static archives. Depending on the machine the libelf is used, some backend code are dlopen'd. So at least, the backends code must be delivered as shared lib (in the by default EBL directory) - the delivered binaries are by default dynamically linked except if the gcov or gprof support is enabled. I was wondering if it would be a good idea (or even possible) to have two options in the configure script, for instance, --enable-static and --enable-shared, which would be set to "yes" by default. In the case --enable-shared=no, no dso is generated (except the backends) and the binaries are statically linked. In the case --enable-static=no, only the dso are generated and binaries are dynamically linked. The combination --enable-shared=no and --enable-dynamic=no is impossible. Finally if the gcov or gprof support is required, we force the current behaviour (ie. --enable-shared=yes and --enable-static=yes). Can you give me your feed back on such a proposal ? If it is worth working on this, I can try to provide a patch. Regarding the project I am working on, I have a workaround which does not satisfy me: - build zlib shared lib - build elfutils with gcov support Thanks in advance, Laurent Stacul