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 #11 received at 28593 <at> debbugs.gnu.org (full text, mbox):
Hi Dave and Ludo,
Thank you Dave for your helpful suggestions on the OpenFOAM package
definition.
Firstly, on the question of adding a debug output, I have checked the
effect of the current '#:strip-directories' keyword definition. In the
build log:
stripping binaries in "/gnu/store/4zqn4w0wlq0irdwh3dhrdbsr7i3f1dag-
openfoam-4.1/lib/OpenFOAM-4.1/platforms/linux64GccDPInt32Opt/bin" with
"strip" and flags ("--strip-debug" "--enable-deterministic-archives")
stripping binaries in "/gnu/store/4zqn4w0wlq0irdwh3dhrdbsr7i3f1dag-
openfoam-4.1/lib/OpenFOAM-4.1/platforms/linux64GccDPInt32Opt/lib" with
"strip" and flags ("--strip-debug" "--enable-deterministic-archives")
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?
>
> Normally the ‘strip’ phase would strip things. I guess the problem
> here
> is that libraries are not in lib/, so nothing gets stripped. This
> would
> be worked around by simply passing something like:
>
> #:strip-directories '("OpenFOAM-1.2.3/lib")
Would that not give a 'directory not found' message? Currently,
#:strip-directories (list (string-append
"lib/OpenFOAM-" ,version
"/platforms/linux64GccDPInt32Opt/bin"
)
(string-append
"lib/OpenFOAM-" ,version
"/platforms/linux64GccDPInt32Opt/lib"
))
> >
> > + (add-after 'build 'cleanup
> > + ;; Avoid lots of junk installed
> > + (lambda _
> > + (delete-file-recursively
> > + "platforms/linux64GccDPInt32Opt/src")
> > + (delete-file-recursively
> > + "platforms/linux64GccDPInt32OptSYSTEMOPENMP
> > I/src")
> > + (zero?
> > + (system* "find" "-name" "*.o" "-delete"))))
> Rather:
>
> (for-each delete-file (find-files "." "\\.o$"))
>
> Paul can you confirm that this is OK?
>
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.
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.