mailing list of musl libc
 help / color / mirror / code / Atom feed
From: argante <argante@pm.me>
To: "musl@lists.openwall.com" <musl@lists.openwall.com>
Subject: Re: static linking problem
Date: Sun, 02 Dec 2018 19:25:56 +0000	[thread overview]
Message-ID: <P-Nojd9WwxRK9fThVUHuxyj1Gowxq8D8CBQD1vQsTpCTubs_TFeKSX5Ns7okNDjoQ-2zz9gSW2_1qYLRDtS2fA==@pm.me> (raw)
In-Reply-To: <20181202181503.GT21289@port70.net>


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, 2 December 2018 19:15, Szabolcs Nagy <nsz@.net> wrote:

> * argante argante@ [2018-12-02 17:20:15 +0000]:
>
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Sunday, 2 December 2018 01:18, Rich Felker dalias@ wrote:
> >
> > > On Sat, Dec 01, 2018 at 10:07:53PM +0000, argante wrote:
> > >
> > > > /lib/ld-musl-x86_64.so.1 (0x7ff0dca25000)
> > > > libc.so => /lib/ld-musl-x86_64.so.1 (0x7ff0dca25000)
> > >
> > > This is dynamic-linked, yes. But there's nothing wrong with your
> > > static-linked program. If you really don't want pie, use -no-pie or a
> > > toolchain that wasn't built to produce pie by default (gcc's
> > > --enable-default-pie option at configure time).
>
> > ./configure \
> > CFLAGS="-Os -g0" \
> > CXXFLAGS="${CFLAGS}" \
> > --enable-languages=c,c++ \

> > --enable-default-pie \
>
>        ^^^^^^^^^^^^^^^^^^^^^
>
> > I still can't understand why musl-cross ldd works correctly, and new toolchain shows such a strange result. Did I overlook something? I even tried -Wl,--no-dynamic-linker.
>
> what do you mean strange?
>
> it seems to work exactly as expected.


I checked Alpine, where there is also a default pie. Indeed, ldd behaves the same:

# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-musl/6.4.0/lto-wrapper
Target: x86_64-alpine-linux-musl
Configured with: /home/buildozer/aports/main/gcc/src/gcc-6.4.0/configure --prefix=/usr
...
--enable-__cxa_atexit --enable-default-pie --enable-cloog-backend --enable-
                      ^^^^^^^^^^^^^^^^^^^^
Thread model: posix
gcc version 6.4.0 (Alpine 6.4.0)

# gcc -static test.c
# ldd a.out
	ldd (0x7f02ef28d000)


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, 2 December 2018 01:18, Rich Felker <dalias@> wrote:

> On Sat, Dec 01, 2018 at 10:07:53PM +0000, argante wrote:

> > ldd a.out
> >
> > ==========
> >
> > ldd (0x7fb6c936f000)
>
> Is this the musl ldd? I believe it will do this or similar, and that's
> a known bug or at least limitation. It should report that the program
> is not dynamic-linked.


yes, this is musl ldd.


but Gentoo:

# gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-gentoo-linux-musl/gcc-bin/7.3.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-gentoo-linux-musl/7.3.0/lto-wrapper
Target: x86_64-gentoo-linux-musl
Configured with: /var/tmp/portage/sys-devel/gcc-7.3.0-r3/work/gcc-7.3.0/configure --host=x86_64-gentoo-linux-musl --build=x86_64-gentoo-linux-musl --prefix=/usr

...

--without-isl --disable-libsanitizer --enable-default-pie --enable-default-ssp
                                     ^^^^^^^^^^^^^^^^^^^^
Thread model: posix
gcc version 7.3.0 (Gentoo Hardened 7.3.0-r3 p1.4)


# gcc -static test.c
# ldd a.out
ldd: a.out: Not a valid dynamic program
# ls -l /usr/bin/ldd
lrwxrwxrwx 1 root root 24 Nov 13 21:27 /usr/bin/ldd -> /lib/ld-musl-x86_64.so.1

or:

# gcc -c -fPIE test.c
# gcc -static -pie test.o
# ldd a.out
ldd: a.out: Not a valid dynamic program
# readelf -l a.out

Elf file type is EXEC (Executable file)
Entry point 0x40014d
There are 4 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x000000000000133c 0x000000000000133c  R E    0x200000
  LOAD           0x0000000000001fd8 0x0000000000601fd8 0x0000000000601fd8
                 0x0000000000000130 0x0000000000000840  RW     0x200000
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10
  GNU_RELRO      0x0000000000001fd8 0x0000000000601fd8 0x0000000000601fd8
                 0x0000000000000028 0x0000000000000028  R      0x1

 Section to Segment mapping:
  Segment Sections...
   00     .init .text .fini .rodata .eh_frame
   01     .ctors .dtors .data.rel.ro .data .bss
   02
   03     .ctors .dtors .data.rel.ro



that's why it seemed surprising to me.

thx


  reply	other threads:[~2018-12-02 19:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-01 22:07 argante
2018-12-02  0:18 ` Rich Felker
2018-12-02 17:20   ` argante
2018-12-02 18:15     ` Szabolcs Nagy
2018-12-02 19:25       ` argante [this message]
2018-12-02 21:16         ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='P-Nojd9WwxRK9fThVUHuxyj1Gowxq8D8CBQD1vQsTpCTubs_TFeKSX5Ns7okNDjoQ-2zz9gSW2_1qYLRDtS2fA==@pm.me' \
    --to=argante@pm.me \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).