Bug 1279395

Seems to be a followup to:

  http://lists.claws-mail.org/pipermail/users/2015-November/014744.html

It hasn't been resolved? That thread is confusing and is missing all the details.

How exactly and when exactly does it fail? What does config.log tell?

1) As a work-around, run "autoreconf" (or "autoreconf -f") instead of autogen.sh.

Alternatively, clean up /usr/bin/libetpan-config --libs flags.


2) The problem autogen.sh runs into is this (in config.log):

configure:20326: checking whether libetpan-config hints compiles and links fine
configure:20340: gcc -o conftest -g -Wall -Wno-pointer-sign -DUSE_MAINTAINER_MODE -pthread -I/usr/include/enchant -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include    -L/usr/local/lib conftest.c  -lm  -letpan -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lz -lgnutls -ldb-5.3 -lz -llockfile -pthread -lsasl2 >&5
/usr/bin/ld: /tmp/ccbbx0ci.o: relocation R_X86_64_PC32 against undefined symbol `db_mailstorage_init' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status


3) Compared with a build after autoreconf:

configure:20326: checking whether libetpan-config hints compiles and links fine
configure:20340: gcc -o conftest -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -Wno-unused-function -Wno-pointer-sign -Wall -pthread -I/usr/include/enchant -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include    -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld conftest.c  -lm  -letpan -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lz -lgnutls -ldb-5.3 -lz -llockfile -pthread -lsasl2 >&5
configure:20340: $? = 0

[...]

The problem seems to be that Fedora's hardened linking flags have slipped into the libetpan-config script:

$ libetpan-config --libs
-letpan -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lz -lgnutls -ldb-5.3 -lz -llockfile -pthread -lsasl2

It doesn't look right to enforce those flags for everything that wants to link with libetpan.

OK, I ran autoreconf -f and it completed, but what next?

My normal process is make distclean && ./autogen.sh --prefix=/usr && make dist.

If I try the make dist there is no rule to make target dist, and running autogen.sh again fails (I suppose this is expected).

I don't have enough knowledge to sort this out myself, but I did see that apparently F23 requires all packages to be built with the hardened flags set so I suspect that the libetpan behaviour is as intended.

> OK, I ran autoreconf -f and it completed, but what next?
> 
> My normal process is make distclean && ./autogen.sh --prefix=/usr && make dist.

That process is faulty. If there are no Makefiles to begin with, you cannot run "make distclean" as the first command. You first need to generate the files maintained by Autotools, such as the "configure" script, all the "Makefile"s and some more. That's why you either run the provided autogen.sh script to take over multiple steps (see its bottom! it's a short script) or you run the more modern "autoreconf" script as included in package "autoconf". Both do not do the same thing, so if you run autoreconf, the actual "configure" step is missing.

  autoreconf ; ./configure --prefix=/usr; make dist

That will produce a tarball that's ready to be compiled without any need to re-run autoreconf or autogen.sh. However, you may need to run "configure" with additional options to enable/disable plugins and other Claws Mail features.


> so I suspect that the libetpan behaviour is as intended.

No. Fedora's src.rpm packages decide whether to apply special compiler/links flags to adhere to the guidelines. "libetpan-config --libs" should only return the -lfoo parameters that are needed to link with the library.

I know that make distclean is only needed if the git directory is still containing the previous version files.

In any case none of the above suggestions work for me, I don't have any Makefiles and obviously neither autogen.sh or configure get past the libetpan checks.

I shall have to wait until I either gain more clue or an updated libetpan package appears that specifies the linker directives correctly. Not sure how the released claws-mail-3.13.0 src rpm builds for me, but it does.

> I don't have any Makefiles and obviously neither autogen.sh or
> configure get past the libetpan checks.

Well, then please don't disagree with me about what I've written in comment 2 about libetpan-config. Either build with hardened CFLAGS and LDFLAGS everywhere _or_ fix /usr/bin/libetpan-config as a work-around.

Here, I've looked into it even further:

$ grep letpan libetpan-config.in
      echo -letpan@LIBSUFFIX@ @LDFLAGS@ @SSLLIBS@ @GNUTLSLIB@ @LIBICONV@ @DBLIB@ @LIBS@ @SASLLIBS@
$

That shows what Make variables build the libetpan-config --libs output. And since @LDFLAGS@ is in there,

$ grep ^S.*LDFLAGS config.status 
S["LDFLAGS"]="-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lz"
$

that causes Fedora's custom LDFLAGS to be inserted into the libetpan-config script as shipped in the libetpan-devel package. Boom!

I didn't mean to disagree, when I read about hardened cc and ld builds it appeared to say *all* packages should use them which is why I thought it was intentional that libetpan behaved this way.

I assume that I can simply remove that -specs=[...] argument in libetpan-config for now. Yes, that has worked, I can now create the tarball and build a new rpm.

I've been using my own local build process for years, I've never seen it break before in this way and I am struggling to understand how all the build environment files fit together.

Thanks for your help.

> when I read about hardened cc and ld builds it appeared
> to say *all* packages should use them

There is a big difference between "building Fedora packages with special compiler flags" and "forcing the users of Fedora packages to use the same flags when compiling something".

Fedora src.rpm packages need to _add_ the global compiler flags when building, provided that the software compiles fine,

  $ rpm -E %__global_ldflags
  -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld

  $ rpm -E %__global_cflags
  -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
  -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
  -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1

but that doesn't mean any of these flags are supposed to enter built *-config scripts and .pc (pkg-config) files, for example. Because then it may be cumbersome and unexpected to filter out unwanted flags -- even if it may be only during development of something.

In your case, you could not build Claws Mail upstream source releases. You can rebuild Fedora's src.rpm package, but only because it applies the %optflags.

Btw, "libetpan-config --libs" output is questionable anyway. It relinks with many shared libs, which it is linked with already. Scripts like that usually do that for the static linking scenario, but when linking with shared libs, relinking usually is not necessary.

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.