[SOLVED] problems with GnuTLS in multilib

sr_ls_boy · 06-04-2016, 05:22 AM

Hello,

I posted that I built a LFS setup. That went without a hitch. I still have it.
But when CS-GO went 64-bit, I had to try to get multilib going. That's the
story.

My problem is in the CLFS book they nearly removed all of the sanity checks,
save one. I can't even be sure if GCC is properly set up. I finished the
CLFS book, experiencing only minor typos. I then moved on to CBLFS.
There are alot of old packages there. I try to use newer versions of tar balls.
It works the majority of the time.

GnuTLS won't compile. Maybe something is wrong with my GCC 6.1.0 compiler. The
gcc might not like the code. I don't know. The exact error follows.

Code:

GUILE_AUTO_COMPILE=0 /usr/bin/guile -L ../../guile/modules "make-enum-map.scm" > "enum-map.i.c.tmp"
mv "enum-map.i.c.tmp" "enum-map.i.c"
GUILE_AUTO_COMPILE=0 /usr/bin/guile -L ../../guile/modules "make-smob-types.scm" > "smob-types.i.c.tmp"
mv "smob-types.i.c.tmp" "smob-types.i.c"
GUILE_AUTO_COMPILE=0 /usr/bin/guile -L ../../guile/modules "make-enum-header.scm" > "enums.h.tmp"
mv "enums.h.tmp" "enums.h"
GUILE_AUTO_COMPILE=0 /usr/bin/guile -L ../../guile/modules "make-smob-header.scm" > "smobs.h.tmp"
mv "smobs.h.tmp" "smobs.h"
/usr/bin/guile-snarf -o core.x core.c   [EDITED]
/usr/bin/guile-snarf -o errors.x errors.c   [EDITED]
 make  all-am
make[4]: Entering directory '/root/archives/gnutls-3.4.12/guile/src'
  CC       guile_gnutls_v_2_la-core.lo
core.c: In function 'scm_init_gnutls':
core.c:3261:31: error: expected ')' before ';' token
   (void) gnutls_global_init ();
                               ^
core.c:3271:1: error: invalid use of void expression
 }
 ^
In file included from core.c:3258:0:
core.x:214:2: error: too few arguments to function 'scm_c_define_gsubr'
  scm_c_define_gsubr (s_scm_gnutls_set_log_level_x,
  ^~~~~~~~~~~~~~~~~~
In file included from /usr/include/libguile.h:52:0,
                 from core.c:29:
/usr/include/libguile/gsubr.h:47:13: note: declared here
 SCM_API SCM scm_c_define_gsubr (const char *name,
             ^~~~~~~~~~~~~~~~~~

There's more where that came from. This is from version 3.4.12. It's
reproducible with 3.5.0.

gcc dump specs on 6.1.0
make in debug mode

sr_ls_boy · 06-04-2016, 05:23 AM

I'll cross post in the cnutls mailing list. I'll post here if I get a response

ReaperX7 · 06-04-2016, 09:46 AM

What you could do is try to use the LFS sanity checks, or see if an older CLFS book might still have them.

Tim Abracadabra · 06-05-2016, 02:46 AM

Keep in mind that "Sanity Checks" are just that.
A simple check that tests the compiler/linker basically works and what tools/binaries are used.

Typically "Sanity Checks" are in no way a comprehensive diagnostic tool.

Now,.. make check or make test may be more thorough tool but the output may need thought and research to discern
what the results mean.

Plainly put, what errors or warnings are considered: expected, unimportant, informational, a serious concern,
or a fatal error requiring urgent attention before moving on ...

Even if all these checks pass, while my give a level of confidence, does not necessarily mean everything is all good.
I recommend sending all output to a file for careful review.

For Example:

make 2>&1 | tee gcc_make.log
Of course adjust the above to the task

Also see here for more on logging:
Creating Log Files During Installation

Please post back with any concerns.

Hope that helps.
Tim

sr_ls_boy · 06-07-2016, 12:32 PM

The gnutls developers suggested that I disable guile bindings altogether.
I have done that and moved on.

I'll mark this issue as solved but I still want to discuss the integrity of
my gcc installation. My compiler just choked on guile 2.0.11. It seg faulted
bash and warned of a broken pipe. I installed an earlier version. I didn't have
any problems with my LFS install I built a month ago.

I'll ask for tips from the gcc developers and post replies here.