Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: gcrypt

[PATCH] build: use LT_SYS_SYMBOL_USCORE instead of reinventing it

 

 

GnuPG gcrypt RSS feed   Index | Next | Previous | View Threaded


flameeyes at flameeyes

Sep 22, 2011, 7:03 AM

Post #1 of 5 (365 views)
Permalink
[PATCH] build: use LT_SYS_SYMBOL_USCORE instead of reinventing it

The version taken from GnuPG 1.4 assumes any cross-compiled package have
prefixed underscores, which is not the case; by using libtool's own macro,
we can avoid the whole issue.

Signed-off-by: Diego Elio Pettenò <flameeyes [at] flameeyes>
---
README | 2 +-
acinclude.m4 | 68 ------------------------------------------------------
configure.ac | 2 +-
mpi/config.links | 2 +-
4 files changed, 3 insertions(+), 71 deletions(-)

diff --git a/README b/README
index bbbd0db..1d4ed32 100644
--- a/README
+++ b/README
@@ -224,7 +224,7 @@

* SunOS 4.1.4

- ./configure ac_cv_sys_symbol_underscore=yes
+ ./configure lt_cv_sys_symbol_underscore=yes

* Sparc64 CPUs

diff --git a/acinclude.m4 b/acinclude.m4
index e69291a..149f309 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -61,74 +61,6 @@ AC_DEFUN([GNUPG_CHECK_GNUMAKE],
fi
])

-
-#
-# GNUPG_SYS_SYMBOL_UNDERSCORE
-# Does the compiler prefix global symbols with an underscore?
-#
-# Taken from GnuPG 1.2 and modified to use the libtool macros.
-AC_DEFUN([GNUPG_SYS_SYMBOL_UNDERSCORE],
-[.tmp_do_check="no"
-case "${host}" in
- *-mingw32msvc*)
- ac_cv_sys_symbol_underscore=yes
- ;;
- i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp)
- ac_cv_sys_symbol_underscore=yes
- ;;
- *)
- if test "$cross_compiling" = yes; then
- if test "x$ac_cv_sys_symbol_underscore" = x ; then
- ac_cv_sys_symbol_underscore=yes
- fi
- else
- tmp_do_check="yes"
- fi
- ;;
-esac
-if test "$tmp_do_check" = "yes"; then
- AC_REQUIRE([AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE])
- AC_MSG_CHECKING([for _ prefix in compiled symbols])
- AC_CACHE_VAL(ac_cv_sys_symbol_underscore,
- [.ac_cv_sys_symbol_underscore=no
- cat > conftest.$ac_ext <<EOF
- void nm_test_func(){}
- int main(){nm_test_func;return 0;}
-EOF
- if AC_TRY_EVAL(ac_compile); then
- # Now try to grab the symbols.
- ac_nlist=conftest.nm
- if AC_TRY_EVAL(NM conftest.$ac_objext \| $lt_cv_sys_global_symbol_pipe \| cut -d \' \' -f 2 \> $ac_nlist) && test -s "$ac_nlist"; then
- # See whether the symbols have a leading underscore.
- if egrep '^_nm_test_func' "$ac_nlist" >/dev/null; then
- ac_cv_sys_symbol_underscore=yes
- else
- if egrep '^nm_test_func ' "$ac_nlist" >/dev/null; then
- :
- else
- echo "configure: cannot find nm_test_func in $ac_nlist" >&AC_FD_CC
- fi
- fi
- else
- echo "configure: cannot run $lt_cv_sys_global_symbol_pipe" >&AC_FD_CC
- fi
- else
- echo "configure: failed program was:" >&AC_FD_CC
- cat conftest.c >&AC_FD_CC
- fi
- rm -rf conftest*
- ])
- else
- AC_MSG_CHECKING([for _ prefix in compiled symbols])
- fi
-AC_MSG_RESULT($ac_cv_sys_symbol_underscore)
-if test x$ac_cv_sys_symbol_underscore = xyes; then
- AC_DEFINE(WITH_SYMBOL_UNDERSCORE,1,
- [Defined if compiled symbols have a leading underscore])
-fi
-])
-
-
######################################################################
# Check whether mlock is broken (hpux 10.20 raises a SIGBUS if mlock
# is not called from uid 0 (not tested whether uid 0 works)
diff --git a/configure.ac b/configure.ac
index ab160c3..6df49bf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -886,7 +886,7 @@ fi
#
# Setup assembler stuff.
#
-GNUPG_SYS_SYMBOL_UNDERSCORE()
+LT_SYS_SYMBOL_USCORE
AC_ARG_ENABLE(mpi-path,
AC_HELP_STRING([--enable-mpi-path=EXTRA_PATH],
[prepend EXTRA_PATH to list of CPU specific optimizations]),
diff --git a/mpi/config.links b/mpi/config.links
index 7e910ee..9696828 100644
--- a/mpi/config.links
+++ b/mpi/config.links
@@ -291,7 +291,7 @@ fi

# Make sysdep.h
echo '/* created by config.links - do not edit */' >./mpi/sysdep.h
-if test x$ac_cv_sys_symbol_underscore = xyes; then
+if test x$sys_symbol_underscore = xyes; then
cat <<EOF >>./mpi/sysdep.h
#if __STDC__
#define C_SYMBOL_NAME(name) _##name
--
1.7.6.1


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


wk at gnupg

Sep 23, 2011, 1:09 AM

Post #2 of 5 (338 views)
Permalink
Re: [PATCH] build: use LT_SYS_SYMBOL_USCORE instead of reinventing it [In reply to]

On Thu, 22 Sep 2011 16:03, flameeyes [at] flameeyes said:
> The version taken from GnuPG 1.4 assumes any cross-compiled package have
> prefixed underscores, which is not the case; by using libtool's own macro,
> we can avoid the whole issue.

I won't apply such changes for GnuPG 1.4. It is a stable code base and
changing such essential things is not good. On how many platforms did
you tested it? Gpg has been tested on dozens of different flavors of
Unix and CPUs.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


flameeyes at flameeyes

Sep 23, 2011, 2:41 AM

Post #3 of 5 (341 views)
Permalink
Re: [PATCH] build: use LT_SYS_SYMBOL_USCORE instead of reinventing it [In reply to]

Il giorno ven, 23/09/2011 alle 10.09 +0200, Werner Koch ha scritto:
>
> I won't apply such changes for GnuPG 1.4. It is a stable code base
> and
> changing such essential things is not good. On how many platforms did
> you tested it? Gpg has been tested on dozens of different flavors of
> Unix and CPUs.

This is for libgcrypt, not gnupg 1.4; but I'd assume libtool's own macro
is more tested than gnupg's (and if it's not, that ś something to pick
up with libtool developers I guess).

Actually, looking at how similar they are I suppose libtool might have
followed from gnupg's...

--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


wk at gnupg

Sep 23, 2011, 5:56 AM

Post #4 of 5 (341 views)
Permalink
Re: [PATCH] build: use LT_SYS_SYMBOL_USCORE instead of reinventing it [In reply to]

On Fri, 23 Sep 2011 11:41, flameeyes [at] flameeyes said:

> This is for libgcrypt, not gnupg 1.4; but I'd assume libtool's own macro

Sorry, I didn't lloked at the mailing list name.

Well, in this case we should compare the libtool versions against the
one we use and switch if they are similar. I'd say, if GMP uses the
libtool versions we should do it although (Any breakage in libtool would
then also be a problem for GMP).


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


flameeyes at flameeyes

Sep 23, 2011, 6:32 AM

Post #5 of 5 (342 views)
Permalink
Re: [PATCH] build: use LT_SYS_SYMBOL_USCORE instead of reinventing it [In reply to]

Il giorno ven, 23/09/2011 alle 14.56 +0200, Werner Koch ha scritto:
>
> Well, in this case we should compare the libtool versions against the
> one we use and switch if they are similar. I'd say, if GMP uses the
> libtool versions we should do it although (Any breakage in libtool
> would
> then also be a problem for GMP).

GMP uses a different macro altogether which appears shorter, but I'm not
sure how more portable it is.

--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

GnuPG gcrypt RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.