From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) by sourceware.org (Postfix) with ESMTPS id 0915C38582BF for ; Thu, 23 Nov 2023 22:26:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0915C38582BF Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0915C38582BF Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::1135 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700778384; cv=none; b=kj9E2PkCBqDPvfwrcWz5Qt8DXde+Wiz2Ye6bRvMxRCdFAwC8wotn4J99D5DmxXxpLsz/15A/Q8izyGd1lQlbGIv4T/BKiVQUcJACdM1UxtS+Pu9VHs6GcTpyjGKs+Kf04qAnio18zN2shO+xTxiUglfaddGqekDxNb7asQo8C2I= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700778384; c=relaxed/simple; bh=RgQJqKOjmFePcV/gyCppxAwlJxaDcGsalIBrbG7mzSs=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=O9/rrdLGD8hTXhcpuAfz1UgiP1F8r85lUiMwDIfjRu60uCN7byQ8TVy3jx0DidpSvM5Q7+6U6oaiyFl0KyXzbeATJdj0BGt8mCywQ/CmFPgE8xpeJWfgarLPcJGJxz02DQGx9ZM5ItDiefIckzI4ivKzBut9rpC2Vztv90YLu+c= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-5cd1bbc0413so12912137b3.0 for ; Thu, 23 Nov 2023 14:26:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700778382; x=1701383182; darn=gcc.gnu.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=RgQJqKOjmFePcV/gyCppxAwlJxaDcGsalIBrbG7mzSs=; b=XYwySH225iFf5EzO2wW0PeWTbjQnhHj658S6Db4xYFT1yKOghzX6jTNUwfGGy8WvgF /YlV8xO+q+KBiMm/60rGiptBONarXey7zKNWO3pqvloMQj8ouEVN3fqAG7EQMdgjlvZJ KnteCh8Mi6e8HCXy6TCjWU5UFGp4Sd7A33SBJLqwalnQFtIp9JkosEH0KkhFRZc1NhLc ZB2zdA1zxuyaC+NG3K3MtCI0VkOGQmt69JqDkq/eHlMDCXJHSte6ktDdYEW/dn3GLfQ0 Be4IhbPnr5mV9qQQpRp3Wns7ouB6H5q5VlhBkdwVxPFSyJexjYlraIGBOsx7/gBCEyhh zn2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700778382; x=1701383182; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RgQJqKOjmFePcV/gyCppxAwlJxaDcGsalIBrbG7mzSs=; b=d5dzc5+089h/ugwlCVG3dBDFDwL/RuhC7h1PdXNu1qHYQAX7u62kjEmHnU/sE8wRgl 0MZvVH7nIO3UiljOdD8FdPaLX6xFMTbdjNUrDcSMuRU4QfhSaxEHc+b1RlfC8bO12l77 p+7hulVnaXOkKCo7Mnj6NldRBjDFzXztlrvtXFQyeA458EF5Ool8uC2KR08709LCTaPO oAlCmgHeYivemkUJkJEaPk0zHKSxcXoREjL69aMpMkWPg7501pldFaji9EVdE4+wtzop M6VCOoFYf61tW/z5ijffOfyr0zA0pANuxDmdqfW4k6q/QdmWbnR+7SR95wlI2dx3ttHe T8OQ== X-Gm-Message-State: AOJu0Yzz7TcSzt27I4FUx1vkg1ZGHz1OQ4M0PWsGI1/FV18b6WlF1/a1 6XghBDoZdOPxTGo1EvfxziJDbbUAGLvSQzCticc3Pggh X-Google-Smtp-Source: AGHT+IHmCFWIJWTwlzGkBv9uGPPOSeKez8YH1y/ebVNhI0dnPoSUYiO5jFMWJiPR310qEu6dgtW019fCVQc42xiFA78= X-Received: by 2002:a81:7c56:0:b0:5cd:6748:732b with SMTP id x83-20020a817c56000000b005cd6748732bmr699577ywc.36.1700778382314; Thu, 23 Nov 2023 14:26:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: R jd <3246251196ryan@gmail.com> Date: Thu, 23 Nov 2023 22:26:11 +0000 Message-ID: Subject: Re: Fine granularity of control over libgcc* search paths To: gcc-help@gcc.gnu.org Content-Type: multipart/alternative; boundary="00000000000051cfbf060ad9530a" X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,FROM_STARTS_WITH_NUMS,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000051cfbf060ad9530a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I should have probably mentioned that my issue is to do with "multilib". The example that I posted in the original post was on my native machine. In fact, I am building compiler toolchains for AmigaNG. For this, we actually have 3 different C runtime libraries. We build this by using "multilib". The default is newlib, followed by two multilibs - if you like - named clib2 and clib4. What happens is that I notice during the linking of a program, whichever non-default lib is being used (clib2/clib4) had these implicitly added -L options, but it is always followed by the "default" lib (newlib). Semantically, this seems a little naughty. When debugging through the GCC.C file, I see that there are functions that seem to append the "default" paths _after_ the clib[24] lib paths. This is fine, so long as they are after, but just feels dirty. Thanks. On Sun, 12 Nov 2023 at 21:37, Jonathan Wakely wrote: > On Sun, 12 Nov 2023 at 19:30, Kai Ruottu wrote: > > > > R jd via Gcc-help kirjoitti 8.11.2023 klo 2.20: > > > I have tried for some hours to figure out how to get full control over > the > > > paths that are implicitly searched for *libgcc.a*. > > > > This reply isn't directly related to your problem but related to finding > > the right shared libgcc's in cross-compilers. > > > > I mean the peculiarity seen in the following : > > > > [kairuottu@fedora test]$ powerpc64-centos-linux7.9-gcc-13 -o > > hello_world_powerc64 hello_world.c [kairuottu@fedora test]$ > > powerpc64-centos-linux7.9-gcc-14 -o hello_world_powerc64 hello_world.c > > > /opt/cross64/bin/../lib/gcc/powerpc64-centos-linux7.9/14.0.0/../../../../= powerpc64-centos-linux7.9/bin/ld: > > cannot find -lgcc_s collect2: error: ld returned 1 exit status > > [kairuottu@fedora test]$ cd /opt/cross/lib/gcc/powerpc64-centos-linux7.9 > > [kairuottu@fedora powerpc64-centos-linux7.9]$ ls -l -t yhteens=C3=A4 56 > > drwxr-xr-x. 7 root root 4096 12.11. 19:52 14.0.0 drwxr-xr-x. 2 root root > > 4096 12.11. 19:51 lib drwxr-xr-x. 2 root root 4096 12.11. 19:51 lib64 > > drwxr-xr-x. 7 root root 4096 1. 8. 23:53 13.2.0 drwxr-xr-x. 7 root root > > 4096 10. 7. 15:47 10.5.0 drwxr-xr-x. 7 root root 4096 2. 6. 19:11 11.4.0 > > drwxr-xr-x. 7 root root 4096 12. 5. 2023 12.3.0 drwxr-xr-x. 7 root root > > 4096 11. 5. 2023 9.5.0 drwxr-xr-x. 7 root root 4096 11. 5. 2023 8.5.0 > > drwxr-xr-x. 7 root root 4096 11. 5. 2023 7.5.0 drwxr-xr-x. 7 root root > > 4096 11. 5. 2023 6.5.0 drwxr-xr-x. 8 root root 4096 11. 5. 2023 4.9.4 > > drwxr-xr-x. 8 root root 4096 11. 5. 2023 5.5.0 drwxr-xr-x. 8 root root > > 4096 10. 5. 2023 4.8.5 [kairuottu@fedora powerpc64-centos-linux7.9]$ ls > > lib* lib: libgcc_s.so libgcc_s.so.1 lib64: libgcc_s.so libgcc_s.so.1 > > > > The peculiarity is that the 'libgcc_s.so*' stuff isn't installed into > > the GCC-version dependent directory as expected when using the > > '--enable-version-specific-runtime-libs' in the GCC configure command. > > But installed in separare 'lib*' directories where they will not be > > found. After the gcc-13.2.0 and earlier GCC builds for the same target > > this peculiarity was fixed via manually moving the 'libgcc_s' stuff > > where it should be after running 'make install'. > > > > I don't remember when this issue started, maybe it was in gcc-9.5.0 or > > gcc-10.5.0. Is this a bug or is there some sanity in this thing? > > --enable-version-specific-runtime-libs has been broken for years: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D32415 > --00000000000051cfbf060ad9530a--