Bug 88523 - sha1.c:37: error: 'SHA1_CTX' undeclared (first use in this function)
Summary: sha1.c:37: error: 'SHA1_CTX' undeclared (first use in this function)
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) OpenBSD
: medium blocker
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2015-01-17 01:16 UTC by Vinson Lee
Modified: 2015-01-19 18:59 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vinson Lee 2015-01-17 01:16:16 UTC
mesa: 9075823c17280d36ca2ba2e98ec93fb097801593 (master 10.5.0-devel)

OpenBSD build error

checking for PTHREAD_PRIO_INHERIT... yes
checking for SHA1Init... yes
checking for CC_SHA1_Init... no
checking for wincrypt.h... no
checking for SHA1Init in -lmd... no
checking for LIBSHA1... no
checking for nettle_sha1_init in -lnettle... no
checking for gcry_md_open in -lgcrypt... no
checking for SHA1_Init in -lcrypto... yes
checking for OPENSSL... yes
checking for SHA1 implementation... libc
checking for LIBDRM... yes

  CC       libmesautil_la-sha1.lo
sha1.c: In function '_mesa_sha1_init':
sha1.c:37: error: 'SHA1_CTX' undeclared (first use in this function)
sha1.c:37: error: (Each undeclared identifier is reported only once
sha1.c:37: error: for each function it appears in.)
sha1.c:37: error: 'ctx' undeclared (first use in this function)
Comment 1 Carl Worth 2015-01-17 01:26:17 UTC
Thanks for the bug report.

I don't have access to an OpenBSD system. Can you look into <sha1.h> and see what type is expected by SHA1Init() and friends?

-Carl
Comment 2 Jonathan Gray 2015-01-17 01:49:12 UTC
SHA1_CTX is defined in sha1.h
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/include/sha1.h?rev=HEAD&content-type=text/plain

The xserver code this was based off builds fine so there must be a Mesa specific problem here.
Comment 3 Jonathan Gray 2015-01-17 02:00:39 UTC
If I rename util/sha1.h to util/xsha1.h matching the xserver name the correct sha1.h is picked up.  Otherwise <sha1.h> picks up util/sha1.h
Comment 4 Jose Fonseca 2015-01-17 11:38:40 UTC
I think that for src/util either we:

- name headers as prefix_foo.h and include them as

  include "prefix_foo.h"
  
- or we always include the directory name

  include "util/foo.h"

Naming headers as foo.h and including as "foo.h" is bound to cause conflicts.


I also think that util might not be a good prefix for this.  I'd suggest we rename src/util to for exmaple src/cgr -- for "common graphics runtime".
Comment 5 Carl Worth 2015-01-19 18:58:24 UTC
commit 3b8ccca8a3b5e03829fba7cdb57b49fc10917954
Author: Carl Worth <cworth@cworth.org>
Date:   Mon Jan 19 10:49:41 2015 -0800

    Rename sha1.c and sha1.h to mesa-sha1.c and mesa-sha1.h
    
    The filename of sha1.h was conflicting with the system-provided
    sha1.h, (and in some confiurations, our sha1.c was unsuccessfully
    attemping to include "sha1.h" and <sha1.h> as two different files).
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88523
Comment 6 Carl Worth 2015-01-19 18:59:14 UTC
I just pushed the commit mentioned above and I believe it will fix this bug.

Please feel free to re-open the bug report if there is still any problem.

-Carl


bug/show.html.tmpl processed on Mar 27, 2017 at 20:26:22.
(provided by the Example extension).