Re: [Pan-users] pan always crashing fast again

[Duncan]

dchmelik-Re5JQEeQqe8AvxtiuMwx3w posted on Sat, 15 Jul 2023 22:20:08 -0700
as excerpted:

> On 7/13/23 12:57 PM, reijo.korhonen@gmail.com wrote:
>> On Tue, 2023-07-11 at 18:56 -0700, David Chmelik wrote:
>>> Well, how do I do that?  This command had no output: ./configure
>>> --help|grep -i debug .
>> My answer is again very generic.
>>
>> Hmm... Is your target to debug pan. What your have done before? If you
>> run "./configure", this command is normally run, when you have
>> downloaded on application zip-package and unzipped it gone to unzipped
>> app-code main directory. There is little runnable script ""configure".
>> "configure" makes makefiles for your system. After "./configure" your
>> compile pan with a command "make" in same directory, where your run
>> "./configure".
>>
>> Google "linux compile debuggeble" and you get basics, for instance "
>> https://newton.ex.ac.uk/teaching/resources/software/linuxcc/";
>>
>> When you have run ./configure, you have got makefile for compiling pan.
>> "./configure" (without grep) hopefully tells how you can confugure what
>> kind makefile is generated. But you can edit makefile yourself and as
>> Google tells us, your can edit makefile for generating debuggable
>> runnable by hand. Check that compiling flags include "-Oo -g", meaning
>> no optimazion and runnable will include code information", so when you
>> debug pan, your get code lines where runnable fails.
>>
>> When you run gdb <path to runnable-pan> your propably should be in same
>> directory, where you run "make", so gdb can find pan code lines. [...]
> 
> The pan.SlackBuild uses these compiling flags '-O2 -fPIC'.  Do any these
> conflict with '-Oo -g'?

Presumably slackware, like gentoo (unless it's in a separate package on 
slack), has a (long) gcc (1) manpage that lists the commandline options, 
which ones apply to each arch, and what they do.

Any -O (uppercase "o" not zero) option controls optimization level, and 
IIRC -g adds debugging info (it's debug related for sure).  -O2 is pretty 
standard optimization, and while unoptimized/-O0 or even -O1 in theory make 
debugging more straightforward, in modern compilers they tend to create 
entirely different code and thus may not recreate the problem.

I don't actually see -Oo here, maybe -O0 (unoptimized) was intended?

There's also a -Og, optimize for debugging, which could be useful here, and 
-Os, optimize for size (basically -O2 but with a couple optimizations that 
result in a bigger executable disabled -- in some cases it can actually be 
faster, however, if it results in the code fitting within a code-cache 
level that it wouldn't fit in with -O2 or -O3).

-fPIC is flag (-f) Position Independent Code, and is normally mandatory for 
amd64/x86_64 dynamic libraries.  For executables it's not mandatory and can 
be a slight deoptimization but it or -fPIE (basically the executable 
targeted -fPIC, not sure on the exact differences) is strongly recommended 
anyway because it makes for better security.

-fPIC and -g shouldn't interfere, but the differing -O optimizations will 
to some extent.  Order matters and IIRC the last one wins, so most build 
systems will arrange for user-supplied flags to come after the build-system 
defaults so they override.  Of course you can watch the build output to see 
what order they appear, tho with all the other flags about which libraries 
to link against, etc, the commandline tends to be pretty long so it can 
take either pausing or a practiced eye (and/or a slow CPU) to scan it on 
the fly.

Beyond that, check the manpage and/or experiment a bit.. or get further 
instructions. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman