Re: Change to DSO-linking semantics of the compiler
> SystemTap is failing on pthread_cancel, which is odd since we have no
> mention of pthread in our own sources. It seems to be pulled in by some
> headers in the STL. Consider this minimal example:
>
> $ cat string.cxx
> #include
> int main()
> {
> return std::string("foo").length() != 3;
> }
> $ g++ -c string.cxx
> $ nm -C string.o
> U _Unwind_Resume
> U std::string::length() const
> U std::allocator::allocator()
> U std::allocator::~allocator()
> U std::basic_string,
> std::allocator >::basic_string(char const*, std::allocator
> const&)
> U std::basic_string,
> std::allocator >::~basic_string()
> 0008 r __gthread_active_p()::__gthread_active_ptr
> U __gxx_personality_v0
> T main
> w pthread_cancel
> $ g++ -o string string.o
>
> This is fine, becauses __gthread_active_p is just using the fact that
> the weak pthread_cancel symbol becomes 0 if libpthread isn't linked.
Right. There's no dependency if it's a weak reference.
> But if one of your dependent libraries uses pthreads, suddenly the main
> executable gets the normal pthread_cancel symbol too, and the new linker
> serves up death:
>
> $ g++ -o string string.o -ldb
> /usr/bin/ld.bfd: string.11980.test: undefined reference to symbol
> 'pthread_cancel@@GLIBC_2.2.5'
> /usr/bin/ld.bfd: note: 'pthread_cancel@@GLIBC_2.2.5' is defined in DSO
> /lib64/libpthread.so.0 so try adding it to the linker command line
> /lib64/libpthread.so.0: could not read symbols: Invalid operation
> *** /usr/bin/ld: ld behavior mismatch! ***
> *** /usr/bin/ld.bfd succeeeded ***
> *** /usr/bin/ld.bfd --no-add-needed exits 1 ***
> *** arguments: --eh-frame-hdr --build-id -m elf_x86_64 --hash-style=gnu
> -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o string
> /usr/lib/gcc/x86_64-redhat-linux/4.4.2/../../../../lib64/crt1.o
> /usr/lib/gcc/x86_64-redhat-linux/4.4.2/../../../../lib64/crti.o
> /usr/lib/gcc/x86_64-redhat-linux/4.4.2/crtbegin.o
> -L/usr/lib/gcc/x86_64-redhat-linux/4.4.2
> -L/usr/lib/gcc/x86_64-redhat-linux/4.4.2
> -L/usr/lib/gcc/x86_64-redhat-linux/4.4.2/../../../../lib64
> -L/lib/../lib64 -L/usr/lib/../lib64
> -L/usr/lib/gcc/x86_64-redhat-linux/4.4.2/../../.. string.o -ldb -lstdc++
> -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
> /usr/lib/gcc/x86_64-redhat-linux/4.4.2/crtend.o
> /usr/lib/gcc/x86_64-redhat-linux/4.4.2/../../../../lib64/crtn.o
> collect2: ld returned 1 exit status
>
> So it seems that now I have to know what my dependent libraries are
> linking to, which I thought was exactly what we were trying to eliminate
> with these new linking semantics.
I think these are not the semantics they're supposed to be. Nick?
I wonder if gold behaves that way. It's a subtle point, I supppose.
The weak undefined reference does need to be associated with the real
definition to some degree, in that it uses that symbol version assocation.
But clearly the mere presence of a weak reference should never trigger any
kind of "undefined reference" error.
> 75 of the failed packages have an undefined reference to pthread_cancel,
> probably for the same reason as above.
We'll fix the toolchain and/or libstdc++ as needed for this.
Those packages should not need a change just because of this issue.
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
> According to notting and the experimentation that I did after the FESCo > meeting, the shared libraries bring in any libraries that they depend on. > However, if the application linking to the shared library also requires the > third shared library but doesn't explicitly link it then the link will fail. That's right. > ie: > > Given: > libfoo requires libbar. > This is used to link: gcc -o libfoo.so -lbar foo.o > libfoo.so contains the dependency on libbar. > > Scenario 1: > /usr/bin/baz depends on symbols in libfoo but not libbar. > This can be used to link: gcc -o baz -lfoo baz.o > The link succeeds and the resulting /usr/bin/baz links to both libfoo.so and > libbar.so as expected. > > Scenario 2: > /usr/bin/baz depends on symbols in both libfoo and llibbar > This fails to link because of missing libbar: gcc -o baz -lfoo baz.o > This succeeds: gcc -o baz -lfoo -lbar baz.o > > Roland, can you clarify that this is indeed how things are supposed to work? Yes, that's correct. A common example seems to be -lm. If you use 'pow' (or whatever), then you should pass -lm. If some other library you use happens to use -lm at the moment, that doesn't mean you shouldn't pass -lm when you are using some API symbols from -lm. > Also... it took me quite a while to come up with the command line flags on > F12 that would allow me to test this (I think I had to get gcc to show me > the linker invokation it used and then run those linker lines with my > modifications), can you tell us what command line flags let us test out the > differences in behaviour on F12? You can always pass extra linker flags through gcc with -Wl,--foo. You can give as many of these as you like, and -Wl,a,b is the same as -Wl,a -Wl,b (both mean to pass "a" and "b" arguments on to ld). On F12 (or F11) you can use 'gcc -Wl,--no-add-needed' to get the new linking semantics. e.g., .../configure LDFLAGS=-Wl,--no-add-needed probably works on many packages if you want to try a manual build of something this way. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
> 78 of those seem to be caused by separated libtinfo. In default > ncurses configuration libtinfo is included in libncurses, so I don't > think the upstreams will be very happy about adding support for > non-standard configurations. > > Petr Machata suggested we could work around it by replacing > libncurses.so and libncursesw.so symlinks with linker scripts > including both libraries. > > Is that acceptable? Yes, that's the right thing to do in this sort of case. If as the maintainer of the -devel package providing -lncurses, you are saying you want -lncurses to go along with an API that is actually provided in more than one DSO, then that is your choice. You've decided that you want your API to map to an ABI in a non-default way, which is fine when you think it makes sense for your case. The way you implement this is to make libncurses.so a plain text file that looks like (modulo indentation): # Your comment here. AS_NEEDED ( libncurses.so.5 libtinfo.so.5 ) Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
> I have problems to understand the xmlrpc-c build failure > > | /usr/bin/ld.bfd: xml-rpc-api2cpp.5842.test: undefined reference to symbol > 'pthread_cancel@@GLIBC_2.2.5' > > pthread_cancel() is not used by the program. I see it in the .plt section > only but not where it is referenced. > > I would like to avoid blind '-lpthread' flags without knowing why they > are required. You are right to ask and not do blind changes! Thanks for checking this. You should not add any -lpthread if you don't really use pthread_cancel yourself. This is biting libstdc++ users and we think it's an ld bug, so we'll try to get that fixed. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
> > - "Jussi Lehtola" wrote: > > > > So is --as-needed within the current default flags? > > As far as I know, no. The default will still be --no-as-needed. That's correct. This change does not affect --as-needed at all. > The --as-needed flag will link libraries if > A) they define symbols required by object files > B) those symbols are still undefined when the library is checked That's correct. In other words, the libfoo.so DSO will only be used at runtime if the presence of -lfoo at link time actually had any effect on what symbols got resolved to what. But --as-needed is not really apropos in this thread. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
> > That's correct. In other words, the libfoo.so DSO will only be used at > > runtime if the presence of -lfoo at link time actually had any effect on > > what symbols got resolved to what. But --as-needed is not really apropos > > in this thread. > > OK, if RPM picks only the libraries that are actually used in > auto-requires, then there's no connection. Otherwise the situation would > be a whole lot different, since the requires might have some bloat. I don't really follow what you mean here. The ld behavior determines what libraries are actually required at runtime by a linked executable (or other library), i.e. the set of DT_NEEDED entries it gets. The rpmbuild auto-requires looks at DT_NEEDED. Regardless of the choices made at link time, rpmbuild correctly determines which libraries will be required at runtime. Anyway, if you are interested one way or another in --as-needed, let's start a separate thread about that and you can say why you want to discuss that subject. It is entirely separate from this F13 feature discussion. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
> Right - Obviously I had not considered the case of a weak reference to a > symbol defined in an as-needed DSO. I'll look into it today. You're going to confuse the poor bystanders by using the wrong terminology. There is no issue with as-needed. It's only --no-add-needed we are talking about today. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
> But, you have added an explicit dependency upon libdb to your executable > by mentioning -ldb on the gcc command line. Therefore libdb will be > loaded at execution start-up. But libdb has a dependency upon > libpthread, so that library will also be loaded at execution start-up. > Hence when you run 'string' the pthread_cancel symbol will be resolved > and so 'string' really does now have a resolved reference to > pthread_cancel. Hence the linker is correct in complaining that you > have a reference to a symbol that is defined in a library which have not > included on the linker command line. > > At least that is how I see it at the moment. That would all be correct if it were not a weak reference. But it is. I doubt that gold behaves this way. Does it? Regardless of what's correct, I think we agree that BFD-ld --no-add-needed and gold should behave consistently. Probably we should take this to the binutils list to resolve what all the linker experts think is right. If your logic above holds, then all "if (&weak_symbol == 0)" tests become useless. You've redefined the semantics of a weak reference to have all the requirements of a strong reference except when nobody anywhere defines the symbol. I'm not all clear yet on jreiser's points about the symbol version binding. But let's leave that as a separate issue to resolve with the ld and rtld experts on symbol versioning. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Creating private branches under fedpkg/git
I believe the manifest ACL behavior is that you are permitted to push to a branch called fN/anything if you are on the pkgdb ACL for fN, and to anything not matching fN/* if you are on the pkgdb ACL for devel/rawhide. So the practical answer is probably that whatever the maintainers for a particular package don't object to is going to be fine. I think it would be a good idea for Fedora to settle on some standard branch name conventions for private branches. The details of how strict one needs to adhere to any detailed conventions for a particular package's repo can of course be up to the consensus that package's maintainers. (So, for the kernel, talk to the kernel list and we'll tell you to do anything you want that's not too ugly.) I've suggested a convention of user//whatever-you-want, being at top level for rawhide forks and fN/user/... for release branch forks. But choosing any such conventions Fedora-wide is probably a FESCo activity. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 'make prep' breaks on private branches.
> Here is what I'm doing: > > fedpkg clone kernel > fedpkg switch-branch f14 > git checkout -b pnfs-all-2.6.35-2010-08-05 Make that 'git checkout --track -b pnfs-blah-blah origin/f14/master'. Or, equivalently, after the fact, do: git config branch.pnfs-blah-blah.remote origin git config branch.pnfs-blah-blah.merge refs/heads/f14/master > git.errors.GitCommandError: 'git config --get > branch.pnfs-all-2.6.35-2010-08-05.merge' returned exit status 1: fedpkg is using this to figure out which dist to build for. Having it set up also means that 'git pull' et al will automagically know to merge the f14/master branch into your branch. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg prep
Perhaps local and so forth could be given a --dist=foo switch, and these sorts of errors could say "can't figure out your dist from git, use --dist or fix your repo". -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: all-versions Koji repository (or a build-id database)
The koji database does contain the file lists in some fashion. You can see from the "info" link for an rpm on a "buildinfo" page. e.g. https://koji.fedoraproject.org/koji/buildinfo?buildID=180269 -> https://koji.fedoraproject.org/koji/rpminfo?rpmID=2041477 I bet some koji guru around here can write a database query to do a "kojiquery -f /file/name" of sorts. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem while building mono-2.8
> I've not come across this (mainly as I've not been that active due to a > mix of work problems and hardware problems which meant a big > re-install). Most of mono is built, but I've just hit this error > > *** ERROR: No build ID note found > in > /home/paul/rpmbuild/BUILDROOT/mono-2.8-1.fc15.i386/usr/lib/mono/2.0/mscorlib.dll.so > > googling suggests that there has been a change and that I need to add > LDFLAGS += --build-id in the build and install parts. I've not had to do > this before, so am I missing something and if I include it, will it then > fail to build on koji? That is not usually the ideal solution. And that the problem is new (some time after F8) suggests there may be something more strange going on. I'll help you figure it out if I can see the build. If it's otherwise readyish, you might as well just commit it to git for rawhide (or make another branch in git if you like), as the easy way for me to get and try it. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem while building mono-2.8
> I can email you over the throwback from the build (or the spec file with > altered patches), but as it dies on on the missing build ID (even with > the LDFLAGS thing added), there is no build. The log might help. I meant, the source, so I can attempt the build. Use git. It's your friend. Just push some changes, to another branch if you're timid. > I'm assuming that make LDFLAGS+=--build-id is correct and that I don't > need to export it or add anything else.. That's not a good assumption. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: calculus of PT_NOTE "for GNU/Linux 2.6.32"
This note comes from crt1.o, which is linked into every normal program (both static and dynamic). Off hand, I'm not sure of anything that actually checks this note. What it indicates is the minimum required kernel version that glibc was built for (its --enable-kernel configure option). This controls what system calls and such kernel features the libc code is built to assume exist and work correctly. In a statically-linked executable, there may very well be libc code that requires that new a kernel. The startup code in libc actually checks the kernel version against this, so a static executable won't try to run. For normal dynamically-linked executables, it is unlikely this note really means anything that matters. (I'm not entirely positive about this.) The same kernel requirement is built into all the DSOs in the glibc package, including the dynamic linker itself. The dynamic linker's startup code does the same kernel version check that is done by static libc code in a static link. But that is based on what those DSOs need, not what the crt1.o note in your executable says. For Fedora glibc builds, we have chosen the newest --enable-kernel version that we can use. (It is always more optimal to disable the compatibility code.) The limiting factor has been the kernels that the koji build machines run, so that glibc's build can do "make check" (actually the build itself requires running the just-built libc too). That's why it was 2.6.18 for so long, because those machines ran RHEL5. Now, I guess they run RHEL6 or something, so we can rely on getting 2.6.32. The proper and recommended way to build binaries that will be sure to be compatible with an older Fedora is to build them against the glibc-devel (and every other -devel) from that Fedora. I think most people use mock. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Passing arguments into LDFLAGS
As I said before, this is almost certainly the wrong fix. If you share your code already, you will get the help you need quickly. As long as you don't, and just ask over-specific questions rather than let people see the context to help you properly, you will get only frustration. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Build fails on Koji x86_64 rawhide but not on any other release or arch.
> /usr/bin/ld: fldigi-trx.o: 'thread_id_' accessed both as normal and > thread local symbol > fldigi-trx.o: could not read symbols: File format not recognized > collect2: ld returned 1 exit status > make[2]: *** [fldigi] Error 1 Use 'eu-readelf -s foo.o | fgrep thread_id_' on each .o that goes into that link, and see which ones do not say STT_TLS. If they all do, then this is probably a linker bug (binutils). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ldd regression in F14B
File a glibc bug. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ldd regression in F14B
> On Mon, Oct 04, 2010 at 12:48:20PM -0700, Roland McGrath wrote: > > File a glibc bug. > > Upstream or in Fedora's bugzilla? (or both?) Both doesn't hurt, but you can just file in Fedora and let the package maintainer handle escalating it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building mono-2.8 for 64 bit - possible solution to the problem
> {standard input}: Assembler messages:
> {standard input}:24487: Error: @TLSLDM reloc is not supported with
> 64-bit output format
> {standard input}:24487: Error: junk `...@tlsld' after expression
> make[3]: *** [libmonoruntimesgen_la-sgen-gc.lo] Error 1
This is certainly a case of compiling i386 code and then trying to link it
as x86-64 (or with other code compiled for x86-64).
> After Googling around, I think I've hit the cause - it's down to the
> cross compiler used on koji (or could be). I found this...
>
> http://www.mail-archive.com/unattended-de...@lists.sourceforge.net/msg02316.html
>
> which seems to point to the cross compilation being the problem for
> building mono on the 64 bit buildsys.
If what you really intend is to compile i[3-6]86 code in an x86_64 rpm,
then indeed you need to make sure that you are passing -m32 for all
the compiler invocations any compilation or linking of the 32-bit code.
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building mono-2.8 for 64 bit - possible solution to the problem
> Hi,
>
> > > {standard input}: Assembler messages:
> > > {standard input}:24487: Error: @TLSLDM reloc is not supported with
> > > 64-bit output format
> > > {standard input}:24487: Error: junk `...@tlsld' after expression
> > > make[3]: *** [libmonoruntimesgen_la-sgen-gc.lo] Error 1
> >
> > This is certainly a case of compiling i386 code and then trying to link it
> > as x86-64 (or with other code compiled for x86-64).
>
> In previous incarnations of mono, this has worked without a hitch
You mean that building some different code worked on x86-64, right? Not
that you are specifically aware that Mono compiles i386 code and then links
it together with x86-64 code. If you mean the latter, color me doubtful.
> I'm not sure in this case. As I've said, the last version (2.6.7-3)
> build fine on the 64 bit boxes without the need to pass any flags to the
> compiler so either Novell has messed with something or the buildsys is
> not being nice to me. Can't decide which...
It seems nearly certain that the Mono code broke to do something dumb.
Have you built it by hand on any x86-64 system?
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building mono-2.8 for 64 bit - possible solution to the problem
Hmm. I did a build with: mock -r fedora-rawhide-x86_64 mono-2.8-1.1.fc15.src.rpm on an f13/x86-64 host and it finished without complaint. All the resultant binaries are 64-bit, not 32-bit. So any hacks with -m32 are surely quite wrong. Perhaps something is indeed wonky in koji, or maybe some prerequisite just got broken and fixed since. You should try just resubmitting the package build. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building mono-2.8 for 64 bit - possible solution to the problem
> It looks like glibc is missing TLS support. Do I submit a BZ against > glibc? That is simply not the case and it's hard to see how you came to such a conclusion. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
> Worth clarifying here: Rawhide or (and?) F13? They are still the same thing, so both. gcc-4.4.3-5.fc13 is there right now. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
> They will only be so for a fairly short time, and you gave no specific > time frame for landing the change (only 'pretty soon'), so it was not > entirely clear. Thanks. Sorry, we meant to be clear that it was "now" as of the posting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
> Will there we a switch to give me the old behavior? I might want this for > my own legacy code. Not forever. You really should fix your makefiles. It's just cleaning up usage that was sloppy originally. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
> Replace
> make CFLAGS="%{optflags} -X11" %{?_smp_mflags}
> with
> make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
This is still not really ideal. For the long run, you should be fixing the
upstream package so that it passes -lX11 where it needs it. The most proper
change keeps -lX11 at the end of the link line, rather than the beginning.
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
> Hi,
> On Wed, Feb 10, 2010 at 12:51 AM, Roland McGrath wrote:
> >> Replace
> >> make CFLAGS="%{optflags} -X11" %{?_smp_mflags}
> >> with
> >> make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
> >
> > This is still not really ideal. For the long run, you should be fixing the
> > upstream package so that it passes -lX11 where it needs it. The most proper
> > change keeps -lX11 at the end of the link line, rather than the beginning.
>
> But, howcome build succeed with just adding -lX11 to CFLAGS for iok package?
I didn't say it wouldn't. "Ideal" means "ideal".
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
> To answer the question, it works because the CFLAGS happen to be applied
> to the linker command as well as the LDFLAGS. As Roland says, though,
> adding it to CFLAGS is the wrongest fix, forcing it into LDFLAGS via the
> spec file is slightly less wrong, but having the upstream code add the
> flag properly during its configure stage is least wrong.
The main point of entirely pointless pedanticism I was making is that you
really should put -lfoo at the end of a linking command line (after all the
.o files), not at the beginning where ${LDFLAGS} usually goes.
For cases like this, it probably doesn't make a great deal of sense to use
a configure test. That is, the call to some X11* function is not
conditional in the source, so -lX11 need not be conditional in the makefile.
When there is no true need to conditionalize anything, extra autoconf
and/or pkg-config magic just makes everything more arcane for no reason.
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
> Well, I'd say it's at least as important that the fix should be done in > the appropriate place - the source code's configure step - and not > wedged into the spec file. And then, of course, it should be sent > upstream. Absolutely! Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
> Note that _libraries_ generally do not have a problem building in a > --no-add-needed world. ELF does not require that all references in a > DSO be resolvable at ld time, and this linking change does not change > that. If your library libfoo uses symbols from libbar but does not > itself link against libbar, that's still legal (although probably > impolite). It is ill-advised. It's recommended to use -shared -Wl,-z,defs so that you will get a link-time failure for being sloppy in this way. (You can't do this if the DSO intentionally has free undefined symbols as part of its ABI, but that is not a style we would recommend for any new libraries.) The reason this really matters is that you want to get symbol version bindings for the references from your DSO to another DSO. It's also the most reliable way (the implicit way) to make sure you have rpm dependencies for the libraries you require. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update - pthread question
> But I'm asking about -pthread option (which is detect/use for this package). -pthread is the same as -D_REENTRANT at the beginning (which is useless) and -lpthread at the end. I don't recommend using it at all. Just use -lpthread instead (at the end of the link line, like all other libraries). Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
> Sure? For the libpng case I have a build failure which looks like this > isn't the case (bug 565047): > > > /usr/bin/ld: /usr/lib/gcc/i686-redhat-linux/4.4.3/../../../libpng12.so: > undefined reference to symbol 'crc32' > /usr/bin/ld: note: 'crc32' is defined in DSO /lib/libz.so.1 so try > adding it to the linker command line > > > Which made me think -lz is needed on the command line even if zlib is > used only indirectly via libpng (and likewise that -lX11 should be there > for gtk2 because gtk2 needs it). That looks suspicious to me. libpng12.so has a DT_NEEDED for libz.so.1, so its reference should not produce this error. This might be an ld bug. Are you sure you don't have other references to 'crc32'? It could be that it is just citing the wrong one for the error. If that's not it, then AFAICT it's just a bug. Either way, file a binutils bug--but say whether it's a spurious message or a message misidentifying which reference has the problem. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
> Is it ok to backport changes to F-12 for fixed packages in F-13 for > this DSO feature? The changes to a package's linking lines that you make for this issue are cleaning up sloppy practice to what was always the right thing to be doing. So it should always be fine to do that in builds for earlier Fedoras too. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to package .so linker scripts?
What ldconfig actually does is fairly stupid. When a file is not something else (i.e. ELF), it checks if the entire contents contain either "GROUP" or "GNU ld script" and barfs if they don't. So the generic advice is to put: /* GNU ld script Explain briefly what this is here for. */ at the top of your installed linker script. That's what's in the installed linker scripts you noticed working fine. In your case, INPUT and GROUP are completely equivalent. (GROUP really only matters when .a libraries are involved.) So you could also s/INPUT/GROUP/ (or, equivalently, use INPUT(GROUP(...))) if you like. But using a comment containing the magic string "GNU ld script" seems like the most sensible thing given ldconfig's behavior. It seems to me we might want to change ldconfig to be less obtuse about this. But that will come later if it does. For example, we can have its message explicitly tell you to add the magic comment if it's a linker script, and perhaps we can make that just a warning rather than a fatal error. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pthreads linking in devel/F-13 issue
-pthread is indeed sufficient when it's really given to the linking $CC run.
> Does someone know why this is going wrong?
In unbound.spec I see:
%{__make} CFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE" QUIET=no %{?_smp_mflags}
This overrides the CFLAGS setting written into Makefile by configure.
You should never override CFLAGS in this way.
The place to set CFLAGS is in the configure line.
You use %configure, which uses CFLAGS="${CFLAGS:-%optflags}".
(%optflags is the same as $RPM_OPT_FLAGS.)
So what would work is:
%configure ... \
CFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE"
However, what I would really suggest is that you instead put -D_GNU_SOURCE
into CFLAGS in the source package itself. If you need that, it should not
be a Fedora-specific issue. e.g., early in configure.ac you can use:
CFLAGS="$CFLAGS -D_GNU_SOURCE"
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pthreads linking in devel/F-13 issue
> Though CFLAGS is not the issue, LIBS= is. You are mistaken. Your configure check decides -pthread alone is sufficient (which it is), and that is all it sets. If your configure put -lpthread into LIBS, then you would not have a problem. The substitution of LIBS into the makefile is working fine. > > So what would work is: > > > > %configure ... \ > >CFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE" > > That fails with: [...] > + ./configure --build=i386-redhat-linux-gnu --host=i386-redhat-linux-gnu > --program-prefix= --disable-dependency-tracking --prefix=/usr > --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc > --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib > --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib > --mandir=/usr/share/man --infodir=/usr/share/info --with-ldns= > --with-libevent --with-pthreads --with-ssl --disable-rpath --enable-debug > --disable-static --with-conf-file=/etc/unbound/unbound.conf > --with-pidfile=/var/run/unbound/unbound.pid --enable-sha2 'CFLAGS=-O2 -g > -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom > -fasynchronous-unwind-tables -D_GNU_SOURCE QUIET=no' This indicates you wrote : %configure ... \ CFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE QUIET=no" QUIET=no belongs outside of quotes. It also does not serve any purpose there at all. Leave it on your make line as you had it before. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing `gold-rebuild' - link your packages with gold now
Nice hack, Michal! As you are aware, I have been slowly preparing things to get towards the option of using gold for real in the future. Making this sort of testing easy is about the next thing I thought someone should do (and wasn't going to hack on myself!), so it's a thrill to see you've taken the initiative. I believe that upstream gold has changed a fair bit since the binutils snapshot we have in Fedora. Before paying much attention to actual testing results, I would recommend working with nickc to get a fresher binutils based on current upstream into rawhide (it's too late to be mucking with F-13 tools now). I had not been planning to announce or recommend anyone play with gold until that was done. As your wiki page mentions, for playing locally by hand you can already (as of F-13) use: alternatives --set /usr/bin/ld /usr/bin/ld.gold to try some compilations. Even with the latest gold, there are still some known limitations. So nobody should be expecting perfection. But it is useful to collect the cases that fail in ways that are not already known gold bugs. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing `gold-rebuild' - link your packages with gold now
> Actually what I do, Roland, it that I grab binutils daily tarball > and rebuild it as Source0 of Rawhide's SRPM (really ugly...) so I > always use the latest one, see '-r' option. Drawback in the script > is that it always rebuilds binutils even if you have today's > binutils RPMs somewhere, that's just a detail a the moment, I guess. Wow, cute hack! You are a crazy man. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
> Also, the "undefined reference to symbol" error is typical for the 'you > left it out of the linker line' situation, but "could not read symbols: > Invalid operation" is not, I've never seen that error before. This and several other odd-looking things are "normal" cascade errors from an undefined symbol in various circumstances. If there are other error messages first, don't worry about the incomprehensible ones until you've resolved the earlier ones. > Um. As I said in my email, it's already *in* the linker line. That's why > I say it's weird. Show the linking command line in question. (As with all requests for help, showing the complete command line and all error messages in the very first report is always the best policy.) It's possible to have this problem by having the libraries in the wrong order relative to each other or to .o files that refer to them. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
> Knock yourself out: > > http://fpaste.org/FnFc/ > > as I replied to John, though, oddly enough when I re-ran the command > manually, it succeeded. Trying to see if it builds through mock now. Are you sure that's the right command? The ld error mentions libvo/vo_vaapi.o, but that file name does not appear in the command line. Also, try adding -v -Wl,-t,-y,vaGetConfigAttributes to the cc command--but of course that's really only useful when you're modifying a command line that is verified to reproduce the error. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can I have some documentation examples excluded from Abrt crash collection?
Ideally I think abrt's crash signature stuff ought to find two characteristic failures are the same, and so send a reporter to an existing bug report. Then that bug can be marked closed with an annotation explaining what you need to install. (Of course, it's also arguably wiser to have a hook in your python infrastructure code that can talk to PackageKit magic to suggest installing a necessary package right there instead of crashing.) Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vfork() semantics changed: ERESTARTNOINTR
> On Thu, Dec 02, 2010 at 09:27:34AM -0800, John Reiser wrote: > > vfork() can fail with ERESTARTNOINTR which is 513 > > and somewhat young. 'make' did not know: > >https://bugzilla.redhat.com/show_bug.cgi?id=659382 > > > > If your package has any shell-like feature > > then it might be good to check for vfork(). > > > > These are internal kernel errnos, and I'm fairly certain are not > supposed to leak to userspace, but be fixed up by the syscall return > code... > > Roland? That is correct. You should never see an ERESTART* code as the result of any system call. The only time userland code should be able to see this is via ptrace, which can sometimes see it (maybe only in syscall tracing?) before the rollback of user register state it indicates has been done. So seeing this in strace is not unexpected, but any user program seeing it leak out is a kernel bug. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vfork() semantics changed: ERESTARTNOINTR
> I am not sure ERESTARTNOINTR leaks to user-space. Probably reporter > noticed ERESTARTNOINTR in strace.out and came to the wrong conclusion. > Afaics, make reports -EINVAL. But I don't think vfork is supposed to be able to fail with EINVAL. So something is fishy. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there any value to per-Fedora branch ACLs?
> Is anybody seeing any real value of having different commit ACLs per > Fedora branch? I've seen some argument for EPEL vs Fedora, but is there > real value in ACLs for f13, f14, devel, etc...? The pkgdb interface distinguishes them. Apparently there was some motivation for that in the first place. If the git hooks are not going to distinguish them, then pkgdb should change not to either. In my own experience, I've never put someone on any ACL for a package whom I wouldn't trust to respect informal agreements about who should do what commits to which branches. So any finer granularity on the ACL enforcement is to avoid accidental braino commits, if anything. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help with dist-git
> But then that breaks simple things that (mostly) worked with the old > cvs/Makefile system. > >fedpkg prep >Traceback (most recent call last): > ... >git.errors.GitCommandError: 'git config --get branch.resurrect.merge' > returned exit status 1: Do something like: git config --add branch.resurrect.merge refs/heads/f14/master to make fedpkg build for f14, or refs/heads/master for rawhide. (You can also just edit .git/config by hand--it will be pretty obvious.) 'fedpkg switch-branch' is a front-end command that does this magic for you, but I don't know exactly how it translates into the underlying git commands, so I don't have a recipe. That .git/config variable replaces the "branch" file in the dist-cvs setup. Rather than a source-controlled file you have to deal with when merging branches, it's just local git state (automagically maintained by fedpkg in normal uses, or by git itself when you use 'git branch --track'). It's what tells fedpkg which %dist tag to define and which koji target to use. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg switch-branch behavior
That is consistent with the normal git workflow. Since fedpkg is a helper around simple git operations, it would make sense for it to give you a message saying you might want to pull, and to have a --pull option to do it for you. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PHP floating point bug possibly misinterpreted
It's not a bug. It's a choice of behavior that has been well-understood for a very long time, even if some developers have only recently become aware of it and are upset about the choices made long ago. When you want a different choice for your program, use the compiler flag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: heads-up: systemtap-sdt-devel rebase in rawhide
> What I was more worried about was what happens when sdt.h is included in > plain C code. Whatever you think of C++ apps that don't play nice with > , such a complaint is unlikely to impress authors of plain C > apps. The only header used by in C is . (Frankly I can't tell any more why we even need that, and probably we don't.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub Hosted upstream 'Source0'
> That does not mean that the compressed contents will always be the same. > At least the gzip compressed tarballs from github contain a time stamp. That is true of the tarball-generation feature of gitweb or whatever it's called last I looked too. It's easily fixed by having it pass -n to gzip (which I would have thought they could have fixed in gitweb by now), and already does not apply to bzip2 format. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bugs in debuginfo packages
> component: CCfits (sergiopr) > file: > CCfits-debuginfo-2.3-2.fc15.i686/usr/lib/debug/.build-id/da/7236759b8c63fab2925bd308123b9b277a238c >- unused debuginfo, binary is not packaged: /usr/bin/cookbook The debuginfo is collected from the %buildroot directories. There is an rpmbuild check that barfs if there are any unpackaged files in there, so that should have broken the build. There is some macro magic to disable that check, but Fedora spec files should not be using that (if it isn't formally disallowed in the packaging guidelines to turn this check off, it should be). So I'm not sure how that could happen. > component: Canna (tagoh) > file: Canna-3.7p3-31.fc15.i686/usr/bin/cannaping >- debuginfo missing; ELF stripped > file: Canna-3.7p3-31.fc15.i686/usr/sbin/cannaserver >- debuginfo missing; ELF stripped It's a bug in the package build if ELF files are stripped in %install (or before that, or built without -g). > component: Inventor (corsepiu) > file: InventorXt-2.1.5-40.fc15.i686/usr/bin/SceneViewer >- debuginfo symlink points to another binary in another RPM package which > might not be installed: > Inventor-demos-2.1.5-40.fc15.i686/usr/lib/Inventor/SceneViewer IMHO these things should not be packaged such that the same binary is copied in two separate packages. Here, I would think Inventor-demos would just require InventorXt and have /usr/lib/Inventor/SceneViewer be a symlink to ../../bin/SceneViewer. If that's not desireable, then the right thing to do is to have an Inventor-common subpackage that contains the binary and have both those packages require it. I think you should look into what the packaging guidelines say about such cases and work on getting them to specify that you just shouldn't copy binaries in two packages. > -- > component: PyMca (jussilehtola) > file: > PyMca-4.4.1-2.fc15.i686/usr/lib/python2.7/site-packages/PyMca/Object3D/Object3DCTools.so >- debuginfo missing; ELF is not stripped This probably means it was compiled without -g, or perhaps that it was stripped using (eu-)strip -g at install time. Just like an ELF file that was fully-stripped at install time, this is a broken package build and should be fixed in the .spec file (or upstream makefiles, or whatever). > component: bigloo (jjames) > file: bigloo-3.6a-1.fc16.i686/usr/bin/bgljfile >- debuginfo missing; ELF stripped As with the Haskell code, these are binaries built by a compiler for some other language rather than the normal GCC suite. These compilers don't generate DWARF. It would be a good goal for all the compilers that produce ELF binaries to eventually produce DWARF for them, but it is beyond the scope of mere Fedora packaging to ensure that they do. These files are rightly omitted from the bigloo-debuginfo rpm. Since bigloo also includes shared libraries that are built from normal C, there is rightly a bigloo-debuginfo rpm at all, to contain those. A package that does not build any normal C/C++/etc code at all (as is perhaps that case with some of the ghc-* packages), should not produce a debuginfo rpm at all. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
> Hm. I can see the use of this, but I can also see issues with how you > do updates for it sanely (if at all.) Why would you do updates for it? Your install CD/DVD to use for rescue boot doesn't get updated. I'd think you'd just install a pristine newer one verbatim if you had a reason to bother, like deciding to burn a new CD. Hence the nice automagic deployment feature would reserve two partitions (or whatevers) for the purpose, so you can install the new image on B and still have the option to boot A if the new one is bad. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: debuginfo for sub packages (Help with RPM SPEC files)
It's normal to get a single foo-debuginfo package from a foo.src.rpm. Please explain exactly why this is a problem for you. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gethostbyname() and resolv.conf updates
nscd and sssd exist in part exactly to address this issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package "ownership"
I agree. The relevant concept is not "owner", but "sucker", or "victim". When businessspeak people say someone "owns" a piece of work, what they mean is to identify the person as the recipient of problems, complaints, pleas for help, and perhaps even, rarely, praise, regarding the state of the work. We don't own the code, the code owns us. It knows where we live, and it keeps bringing people over and expecting us to feed them. When a robot sends me email via an alias that ends with "-owner", I never, ever, get the feeling that I am the one in charge. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
> Is there a way to include pre-packaged workloads analysis? I realise > we'd have to regenerate these somehow possible for each compiler update > (not sure how the files look). What a "workload" means to the compiler is all the results of all the conditional branches in the compiled code. What sites there are to have data points and what the association between those and any high-level notion of "workload" (i.e. all forms of input to the program) changes not only with compiler differences, but with every source code change. It's pretty hard to imagine what you could preserve across builds of nontrivially nonidentical source trees that would continue to line up at the basic block level where it's meaningful to the compiler. Perhaps you could do something reduced to terms of source line locations, or number of basic blocks into a named function, or something. But it sounds very iffy. > This would allow us for some thing like firefox or openoffice to run > some stuff offline on a packagers desktop and then use those files in a > koji run later. Those are both examples of big multi-component things that probably have their own build infrastructure for exercising components in various ways. Internal ways to drive those with representative synthetic workloads are probably the wisest thing in the long run. Those are also both examples of GUI things. For those things, a representative workload could be recorded as something like a dogtail test suite (I don't really know anything about such tools, but they exist). That could perhaps be substantially automated by some magic in mock/koji to do a full rpmbuild, then a test suite run and mine out its .gcda files, and then a final rpmbuild with those results poked into its gcc runs. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
> This has a multilib problem. libstdc++ has a few of the same files in > both the x86-64 and i686 packages, making it impossible to have both > installed (which should be possible, and is in F13). > > The files are a few Python bits > in /usr/share/gcc-4.5.0/python/libstdcxx/v6/ . Would it work if they were in libstdc++-devel instead? In F13 that seems to be ok for /usr/include/c++/4.4.4/ files. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
> I dunno, I'm not a multilib expert, just an asshole telling you to make > it work =) I'm no expert on the rpm part of the world either, but I have seen many things and I'll yell some out from the corner now and then. > I think it probably doesn't 'work', in the sense that you can't install > the f13 -devel i686 and x86-64 packages together, but in another sense > that's fine, as I don't think our multilib policy says you _will_ be > able to install -devel packages together and it's not a huge tragedy if > you can't. So that would certainly be an improvement. Just being able to > install the main lib package is the most important thing. The -devel package seems like the right place for them anyway. You don't really want anything extra in lib* packages that just satisfy DSO dependencies (even though these python files happen to be tiny). In F13 they live in gdb instead. If you were using gdb then you probably wanted to see the source code in the header files and thus had -devel installed anyway. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
> So I'd package up stuff, do a koji build, download it, run my > representative test suite, upload the result and do another build. Oh. Well, sure then. What was the question? You don't want much of it automated at all then, but you're asking about the little? The profiled build will litter your world with .gcda files, and we'll have to select some useful convention for -fprofile-dir= in builds and then setting GCOV_PREFIX/GCOV_PREFIX_STRIP environment variables when you do your run so you know where it will put them. I can see doing some rpm macro magic to tweak RPM_OPT_FLAGS for the build and implicitly generate a subpackage of the .gcno files. Those are the compile-time half of what you need to feed back into the final build. Then you'd need to get that subpackage (or its contents, the .gcno files) along with your collected .gcda files into something that could be a SourceN: for the final build. I'm really not sure how to tie that into the whole rpmbuild/mock/koji world. To preserve the actual bit for bit reproducibility of builds that makes koji great, that tarball (or whatever it is, all the .gcno and .gcda files) needs to be saved forever along with the build. We can do it with automation over the current process, where it goes into the lookaside cache and its signature committed in the sources file and all that. Or it could be some sort of special koji magic where the koji rpmbuilds just slurp from some koji database via some permanent identifier URL or whatnot, e.g. a URL set in an rpm macro that koji sets on an rpmbuild for "koji build --profileball=foo.tar.xz ..." after storing it there for posterity. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
> This is accurate. > > the files must be identical if they are not elf binaries. I think the .py[co] files embed timestamps or something like that. So they are nonidentical but not actually different at all. You want all python to be in things that you don't want two of, AFAICT. In general one could split out a -headers subpackage with the headers and the python. But the rawhide libstdc++-devel actually has nothing but the headers anyway (with libstdc++-static split out), so just the python there would make you only ever want libstdc++-devel.x86_64 and you can compile with -m32 just with matching-version libstdc++.i686 installed. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
> > Unresolved regressions > > -- > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16353 > > Subject : 2.6.35 regression > > Submitter : Zeev Tarantov > > Date: 2010-07-05 13:04 (4 days old) > > Message-ID : > > References : > http://marc.info/?l=linux-kernel&m=127836002702522&w=2 > > This is a gcc-4.5 issue. Whether it's also something that we should > change in the kernel is unclear, but at least as of now, the rule is > that you cannot compile the kernel with gcc-4.5. No idea whether the > compiler is just entirely broken, or whether it's just that it > triggers something iffy by being overly clever. What you cited talks about lossage in the metadata for ftrace syscall tracing. It's hardly fatal. There's already a fix on its way upstream, and it appears to have been nothing more than default alignment changes vs the highly-fragile ftrace hooey. "compiler is just entirely broken" is laughable even to have speculated about for the actual facts here. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
My opinion is that a branch called F-/master is the nicest thing. Actually, all else being equal, I'd probably go for it being called f/master, since gratuitous caps and punctuation in branch names is not a normal git convention. (But I only really care about the structure of the names, not the spelling.) I don't really care whether you have an F-/HEAD alias to that or not. I don't really care whether fedpkg provides front-end features to git that relieve one of knowing the actual branch name or not. Personally, I'd always look at the canonical git repository to see what the branches are called, and use those full names directly. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
> That said, I don't think I'd use either HEAD or master as the branch name > since they both have some sort of association with how git itself works > unless the name actually matches 100% with the concept that you're trying to > express here. This is nothing more or less than our convention for git branch names, so the generic git conventions for branch names exactly match the concept. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
> My first idea would be for fedpkg to do something similar to the > following when trying to find out the target to build for: > > 0. If "--target F-13" is given, use that as target. > If not, continue. > 1. Determine the current git branch ($origbranch=$curbranch). > 2. Check 'git config "branch.$curbranch.fedora-target"'. > If set, use that as target. If not, continue. > 3. Check whether "$curbranch" starts with "F-13/". If so, > use "F-13" as the target. If not, continue. > 4. Check what branch "$curbranch" is tracking. > If it tracks one, set curbranch to that branch and > go to step 2. > Otherwise, bail out and ask for --target or > 'git config branch.$origbranch.fedora-target' to be set. I'd suggested something just about like this. Jesse is concerned by the fact that some local state (the .git/config file in your local repo) affects this. I think the fear is that you could easily manage to confuse yourself about what magic cookie is driving your "dwim" build target behavior, so another developer you're collaborating with might end up having a local git repo you both looks the same as yours, but builds pick a different target. My first suggestion was not to have the magical leading "F-/" matching at all. Rather, just have fedpkg front-end commands set and show the state of branch.SOMEBRANCH.fedora-target settings. e.g., 'fedpkg checkout foo' would both do 'git checkout foo' and set the branch.foo.fedora-target automatically. I can see both sides of Jesse's point about the extra locally-confusable magic setting here. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
> > Using names like f13, el5, and so forth would also keep dist-git
> > consistent with git branch naming conventions. If we were to do
> > something like that we might as well just use the value of %{dist}.
But that's just too obviously right for us to be allowed to do it!
> That was going to be my next question, although that would bring back
> the "c" in fc13 and fc14 since that's what the dist value is. We could
> bite the bullet and change the dist value to remove the c, and just
> manually keep track of making sure that builds on older releases won't
> be "newer" than builds on the newer branches. not sure if we want to go
> through that pain at this point.
I'd say bite the bullet. Die, little c, die! It just looks silly there
nowadays, since the C-word has not been in our vocabulary for so long now.
What does "manually" mean, anyway? A database query and a short script?
Roll it into existing nag mail or update sanity-checking stuff? This seems
like a simple enough matter among all the things we're nowadays trying to
have some coherent checking for.
> Yes. Branches of rawhide would be of the form origin/ so if we
> don't find one of our expected f(c)??,el?,olpc? we default to building
> for rawhide.
Where is the mapping of branch name patterns to koji build targets going to
live? Is it just in fedpkg locally and you'll change the norm only by
pushing a fedora-packager update in each release? (That doesn't sound very
likely. People use older Fedoras with older fedora-packager installed to
commit and trigger newer dist builds.) Or is it partly local and partly
gotten from the (koji?) server, or what? (In the CVS system this is the
common/branches file, which is both locally available in that it's a local
file in your common/ checkout, and centrally maintained in CVS.)
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git wordsmithing wanted
> It was suggested to keep the Makefile that exists in every package > module/branch in CVS right now, but set it up so that any Make command > issued would print a reminder to the user that the Make system has been > retired and to use fedpkg. So the expectation would be people leave this boilerplate around forever (as the wordsmithing drifts)? Or do you expect every maintainer who knows about fedpkg will just remove Makefile from their git trees first thing after the conversion? Frankly, I don't see the point. So you're a Fedora maintainer and you managed to get a git checkout after the conversion, but you can't read a wiki page that tells you how to use fedpkg instead of make. (Presumably the wiki page has a nice table of make commands and corresponding fedpkg commands.) Where did you read how to do the git checkout if it wasn't the same wiki page that tells you all about fedpkg? What will you do in your confusion, and will it not include email to this list or asking on IRC so that you get answers to "I knew how to do 'make foo' but what now?" in about three minutes? But, some of my Makefiles have nonstandard cruft in them I need to keep around until I replace it with something. So don't delete *my* makefiles. Just delete *their* makefiles. Oh, also, I don't care at all. So, just do, you know, whatever. Rock on. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git wordsmithing wanted
> $ cat Makefile > # Makefile for source rpm: pungi > # $Id$ > .PHONY :: $(ARCHES) sources uploadsource upload export check build-check [...] Just use a single .DEFAULT: or %: rule, you don't need to list anything. (And :: is almost never what you meant.) Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is import.log of any use?
> Not sure if I've asked the wider audience here, but is the import.log > file of any use to anybody? It's one more file that might differ > between branches even when all else is the same, and I don't necessarily > want to keep munging it with fedpkg when importing items. Would anybody > cry if this file went away? Whatever information it carries can be put into formulaic git commit log messages generated by the cvs-import.sh replacement. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
