Re: static pie: confusion between _DYNAMIC, crt1.o, Scrt1.o
On 24 Oct 2022 13:12, Florian Weimer via Libc-alpha wrote: > * Samuel Thibault: > > Florian Weimer, le lun. 24 oct. 2022 12:11:03 +0200, a ecrit: > >> * Samuel Thibault: > >> > >> > Is it not possible to make -static -pie get the same behavior? That'd be > >> > way more orthogonal for people to understand. > >> > >> I think you want -static to mean -static-pie if GCC defaults to PIE, > >> right? > > > > That would actually provide the pie benefit automatically for all > > static executable, yes. Otherwise static pie will be a nice thing, but > > not actually largely used in practice. And most people won't actually > > realize it. > > That's true. > > Fedora uses a specs file fragment that turns -static into -static-pie > under certain conditions. > > >> That will break a few things that use gcc -static to build binaries for > >> quasi-bare-metal targets using the GNU ELF toolchain (where glibc's > >> startup code is not use). > > > > But then the piece which is saying that glibc's startup code is not in > > use can be fixed into not using static-pie, can't it? > > In theory, yes. How hard it will be depends on the specs file change > for --enable-default-pie. i don't see a problem with -static DTRT. people abusing a compiler for a target it wasn't designed for means they get the pieces. it's not like they're using -static in the first place to pull in the C library & gcc internal libs (which also depend/assume the corresponding OS & C lib). plus, -static -no-pie would get you back to a non-PIE static binary. -mike signature.asc Description: PGP signature
Bug#783210: [PATCH] nscd_stat.c: make the build reproducible
On 28 Jul 2016 15:15, Florian Weimer wrote: > On 03/09/2016 05:30 PM, Mike Frysinger wrote: > > would it be so terrible to properly marshall this data ? > > Ximin Luo and I discussed this and I wonder if it is possible to read > out the libc.so.6 build ID if it is present. It should indirectly call > all the layout dependencies and be reasonably easy to access because it > is in an allocated section (and we might want to print it from an > libc.so.6 invocation, too). > > We still need the time-based approach if the build ID is not available, > but I expect most distributions will have something like it. > > The Debian bug is: > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783210 > > (Also Cc:ed) agreed that build-id should be an acceptable replacement for what the code is doing today, but in order to pull that off, i guess you'd have to have to do a configure test to see if build-id is active ? if you leave the logic to runtime, you'd still need to include the datetime stamp in the object which would still make the build unreproducible. this also doesn't really cover the quoted idea of marshalling the data between client & server :). -mike signature.asc Description: Digital signature
Re: glibc testsuite improvement
On Monday 27 August 2012 08:28:50 Tomas Dohnalek wrote: > I guess, that you are having the same difficulties so I want to ask, how > do you deal with current state? Have you made any internal tool for > comparing results or are you doing it manually? i run `make -k >& log` then grep it for the Error string from make, then look at each test individually. it's a pita. -mike signature.asc Description: This is a digitally signed message part.
Re: hppa nptl switch
On Tuesday 01 September 2009 11:50:27 Aurelien Jarno wrote: > Carlos O'Donell a écrit : > > On Tue, Sep 1, 2009 at 2:08 AM, Aurelien Jarno wrote: > >> Frans Pop a écrit : > >>> Carlos O'Donell wrote: > > In practice it shouldn't be problem at all. > > Debian should make sure that binary/library compiled > > against NPTL-hppa-glibc will require NPTL-hppa-glibc > > by proper Depends: line like "libc6 (>= 2.10)". > > Does every package have to do this? I'm not very familiar with all the > packaging requirements. > >>> > >>> It is something that should automatically get done correctly as long as > >>> the libc-dev package defines the minimum version that way. > >>> > >>> The mechanism that determines this is in > >>> /var/lib/dpkg/info/libc6.shlibs. Currently this has lines like: > >>>libc 6 libc6 (>= 2.9) > >> > >> No, as glibc uses symbols files, this file is actually not used. > >> Nevertheless it is still possible to resolve all symbols to libc6 (>= > >> 2.10). > > > > Once an application is rebuilt against a new libc, what prevents the > > user from downgrading libc and breaking the application? > > If we make sure that the new programs are using symbols from version > GLIBC_2.10, the program should refuse to start with a lower version of > the glibc. i think the question was one about packaging rather than general use ? if you build a package against a newer glibc version but it only uses older symbols, then in theory it should work fine with older glibc versions. if the symbol changes between versions, then it should have corresponding symbol version changes as well (which will automatically be recorded in the binary). -mike signature.asc Description: This is a digitally signed message part.
Re: glibc release branch procedures
On Sunday 24 May 2009 07:44:40 Petr Baudis wrote: > I'm full-quoting the mail. Summary of previous discussion: Me and > Roland agree that (up to exceptions) only cherry-picked commits from > master will appear on the branch, they will be only bugfixes and API/ABI > will never be changed. What we agree about less is the degree of > strictness on what patches to include. i think a pretty good rule is that if most distros are going to be including this anyways, it should be in the branch. not sure if that helps guide the strictness aspect at all. -mike signature.asc Description: This is a digitally signed message part.
Re: Kernel Version
On Friday 20 March 2009 15:58:15 Shameem Ahamed wrote: > Is there any glibc supported system call or library function which returns > the kernel details ( specifically the architecture, whether it is a 32 bit > or 64 bit). I was thinking that sysconf system call supports it. But i > checked the man pages, and couldn't find a match. if (sizeof(void*) == 4) /* 32 bit */ else if (sizeof(void*) == 8) /* 64 bit */ else /* magic */ or maybe `man 2 personality` in the future, you might want to: - fix your mailer. long lines unwrapped lines are not welcome in the open source world. - not cross post to as many lists as you can find. cross-posting is frowned upon when you dont have a good reason to do it. asking for help is not a good reason. -mike signature.asc Description: This is a digitally signed message part.
Re: xattr family of system calls
On Tuesday 17 March 2009 01:18:15 Shameem Ahamed wrote: > I am not able to compile my program, as i can't find > the getxattr, setxattr family of system calls. I checked the header > files folder and couldn't find the attr folder also. they arent provided by glibc. install the attr/acl packages. -mike signature.asc Description: This is a digitally signed message part.
Bug#506850: mcount crash moved upstream
ive moved this report upstream as it happens on Gentoo as well: http://sources.redhat.com/bugzilla/show_bug.cgi?id=9689 -mike -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.
On Thursday 22 February 2007, Roland McGrath wrote: > > All statically initialized locks are broken. We made locks smaller, > > and changed the value of the static initialization. > > Smaller? Smaller is easy. And you didn't actually reduce > __SIZEOF_PTHREAD_MUTEX_T, did you? This seems like it would not be at all > hard to accommodate just with symbol versioning and not break any > compatibility. Off hand, it seems like it would be some simple code in one > new file in your sysdeps/ tree and a smattering of sysdeps Versions files. how can you do symbol versioning on static initializers ? the initialized value is compiled into the .data sections of the actual binary ... hmm ... do you mean we retain the pthread code that uses the old locking methods and create all the new code with glibc-2.6 symbol versions ? -mike pgplTY6HiugLf.pgp Description: PGP signature
Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.
On Sunday 18 February 2007, Carlos O'Donell wrote: > NPTL for hppa-linux is not backwards compatible with Linuxthreads, we > have broken the pthread ABI. > > It has been recommended that we bump to libc6.1 for NPTL. Is that a > good idea? Are there any comments about how to make such a transition > smooth for debian, gentoo, and ubuntu? if the breakage is just in pthreads, i dont think the libc ABI needs to be bumped, just the pthread one ? libc provides look ahead stub functions for pthreads, so it shouldnt be affected by the breakage you've mentioned with static lock initializers ... libpthread.so.0 -> libpthread.so.1 -mike pgpDwA51zYre6.pgp Description: PGP signature
