On Wed, Jul 26, 2017 at 01:21:29PM +0200, Mark Wielaard wrote: > On Wed, 2017-07-26 at 11:37 +0100, Richard W.M. Jones wrote: > > Could this be causing: > > > > error: Empty %files file /builddir/build/BUILD/cduce-0.6.0/debugsourcefiles.list > > > > in https://koji.fedoraproject.org/koji/taskinfo?taskID=20742651 ? > > Yes, if %_debugsource_packages is defined and the rpm debugedit cannot > find any debug sources then that error would be created. That is > obviously a bug. Someone else also just reported it. But I haven't had > time to look into it yet. > > Note that that the fedora rawhide rpm package now has enabled > %_debugsource_packages by default. So you will have to %undefine > it in your spec file if you don't want a -debugsource package. > > > OCaml generates DWARF information which is picked up for debuginfo > > files (and is useful), but our debuginfo tools have never been able to > > locate the source files correctly -- perhaps they need to be told that > > *.ml files are source files? > > The problem seems to be that the generated DWARF doesn't use > a .debug_line directory table but only plain file names. Those file > names are all relative to the debuginfo compile unit comp_dir attribute. > But the comp_dir is always the full absolute path: > > $ eu-readelf > --debug-dump=info ./usr/lib/debug/usr/bin/cduce-0.6.0-23.fc27.x86_64.debug 2>&1 | grep comp_dir > comp_dir (strp) > "/builddir/build/BUILD/ocamlnet-4.1.2/src/netsys" > > This confuses rpm debugedit which assumes anything with an absolute path > is outside the build dir and so a system file belonging to another > package (e.g. /usr/include/...) and so gets excluded. > > That should be fixable in rpm debugedit. I'll try to come up with a > patch. I think actually the compiler is correct, but there's another thing going on. Firstly, here's an example of the compiler being (ISTM) correct: $ pwd /var/tmp $ cat comp/test.ml print_endline "hello world" $ ocamlopt.opt -g ./comp/test.ml -o ./comp/test-ocaml $ eu-readelf --debug-dump=info ./comp/test-ocaml |& less Compilation unit at offset 0: ... name (strp) "pervasives.ml" comp_dir (strp) "/builddir/build/BUILD/ocaml-4.04.2/stdlib" Compilation unit at offset 46: ... name (strp) "./comp/test.ml" comp_dir (strp) "/var/tmp" What's happened is that some functions from the pervasives.ml stdlib have been statically linked into the final binary. The same happens in the cduce binary, with a bunch of stuff being statically linked. However the problem is that cduce itself was compiled without the ‘-g’ flag, so none of the debuginfo refers to the main binary, only to statically linked libraries. That's why the paths appear to only refer to random external directories (the ones which the libraries were compiled under) and nothing under the cduce build directory. That's a bug in cduce.spec which I'll fix shortly. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
