GNU bug report logs -
#28593
[PATCH] gnu: openfoam: Clean up to reduce closure.
Previous Next
Reported by: Dave Love <fx <at> gnu.org>
Date: Mon, 25 Sep 2017 10:50:01 UTC
Severity: normal
Tags: patch
Done: ludo <at> gnu.org (Ludovic Courtès)
Bug is archived. No further changes may be made.
Full log
Message #17 received at 28593 <at> debbugs.gnu.org (full text, mbox):
Paul Garlick <pgarlick <at> tourbillion-technology.com> writes:
> This suggests that the binaries in .../bin and .../lib are being
> stripped. However, if I check a randomly-selected executable in the
> bin directory:
>
> $ objdump --syms /home/paul/.guix-profile/lib/OpenFOAM-
> 4.1/platforms/linux64GccDPInt32Opt/bin/blockMesh | grep debug
>
> 0000000000000000 O *UND* 0000000000000000 _ZN
> 4Foam8fileName5debugE
> 0000000000000000 O *UND* 0000000000000000 _ZN
> 4Foam4word5debugE
>
> The 'file' command also reports that the executables and shared objects
> are 'not stripped'. Does adding a debug output achieve the effect of
> stripping the binaries?
That was confusing me too, and I was going to ask about it...
>> > + (zero?
>> > + (system* "find" "-name" "*.o" "-delete"))))
>> Rather:
>>
>> (for-each delete-file (find-files "." "\\.o$"))
I don't understand the need to avoid system(*), but I assumed the
optimizations in find make it significantly faster then find-files -- is
that not true? (Dealing with the file structure in openfoam is horribly
slow when I've done builds on the NFS filesystems.)
> Maybe. We need to be careful that we not delete files which are needed
> later on. Typically, a user will copy part of the directory structure
> to a subdirectory of $HOME and compile a new solver. The OpenFOAM
> 'wmake' utility takes care of the dependencies and re-compiles object
> files as needed.
>
> So, object files under 'platforms/linux64GccDPInt32Opt/src' should be
> safe to delete. However, this needs to be checked to make sure no
> dependencies are deleted that cannot easily be re-compiled. Have you
> already checked this Dave by, for example, re-compiling a standard
> solver?
>
> Paul.
Not in this case, but people have been using my rpm version in anger,
though it's an earlier version. (I was looking at this partly to help
updating the rpm.) I'd have expected to have to regenerate the
dependency files when modifying the source.
[I wish openfoam had a sane build system, even one that stopped on an
error, sigh. Actually, it might be worth patching that, like the rpm --
I've several times missed components not being built -- assuming that
hasn't changed.]
This bug report was last modified 7 years and 178 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.