On Sat, Jul 14, 2012 at 05:03:18PM -0500, Bruce Dubbs wrote: > Armin K. wrote: > > On 07/14/2012 11:35 PM, Bruce Dubbs wrote: > >> Armin K. wrote: > >>> On 07/14/2012 10:49 PM, Bruce Dubbs wrote: > >>>> > >>>> I'll take a look. Thanks for the suggestions. > >> > >>> Here are some corrections to your work. I've defined path to usb.ids and > >>> pci.ids, added common library to shared libudev because there are > >>> undefined references later when linking against that one. Also, I've > >>> modified installation to install gtk-doc htmldocs that are present there. > >> > >> > >> +OPTIONS += -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > >> > >> > >> I haven't had time to look at everything yet, but I did find out that a > >> sed works too: > >> > >> $ sed -i 's/off_t factor;/int64_t factor;/' src/shared/util.c > >> > >> I think that's a smaller fix as far a code generation goes. It's just a > >> build issue though. The functions that use this code are not used in > >> udev. The compile options -ffunction-sections -fdata-sections and the > >> link options -Wl,--as-needed -Wl,--gc-sections mean that this code never > >> gets built into the executables and they are not in libudev either. > > > > > I dislike that sed. Maintainers know what are they doing. Even udev 182 > > has those CFLAGS set by default (AC_SYS_LARGEFILE macro handles that) > > ... Just let them be there. > > Most of the time I would agree with you, but not in this case. I don't > think the maintainers thought about the type when they created the table > with an off_t index. It's a kludge to make off_t to used 64 bits in a > 32 bit system when specifying it directly in the code is more direct. > There are a couple of other types that could be used too: offset_t or > off64_t are always 64 bits as well as int64_t. > > -- Bruce > [ sorry for not snipping, but in this case I couldn't see a suitable place ]
Using the CFLAGS can be instructive (as in adding to the user's CFLAGS instead of totally overriding them, as a few packages still do). It also appears to be obviously correct, and therefore minimises future maintenance if the code in systemd is moved. If you want to fork systemd, you could happily change the type (and test it), but while you are working on the "add a Makefile to remove the worst of upstream's changes" approach, I think that the sed is likely to cause you more work in the future, not less. That's always the problem with seds for compilation problems - they need to be checked against each new version to see if they still do anything, as well as testing to see if it still compiles. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
