From chofchof@kias.re.kr  Sun Dec 14 16:49:11 2003
Return-Path: <chofchof@kias.re.kr>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 24BC516A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 14 Dec 2003 16:49:11 -0800 (PST)
Received: from mail.kias.re.kr (mail.kias.re.kr [210.98.29.13])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 095F843D31
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 14 Dec 2003 16:49:08 -0800 (PST)
	(envelope-from chofchof@kias.re.kr)
Received: from mail (localhost [127.0.0.1])
	by mail2 (Spambreaker) with ESMTP id 564ED92E84
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 15 Dec 2003 09:47:36 +0900 (KST)
Received: from spin (dhcp.kias.re.kr [210.98.29.3])
	by mail.kias.re.kr (Spambreaker) with SMTP
	id 4143E92E83; Mon, 15 Dec 2003 09:47:36 +0900 (KST)
Message-Id: <002501c3c2a5$3a5c8480$8f1da8c0@kias.re.kr>
Date: Mon, 15 Dec 2003 09:48:59 +0900
From: "Jin-Hwan Cho" <chofchof@kias.re.kr>
To: <FreeBSD-gnats-submit@freebsd.org>
Cc: "Cho, Jin-Hwan" <chofchof@ktug.or.kr>
Subject: Problem in calling kpathsea library from Python extension

>Number:         60243
>Category:       misc
>Synopsis:       Problem in calling kpathsea library from Python extension
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Dec 14 16:50:19 PST 2003
>Closed-Date:    Wed Mar 09 19:50:45 GMT 2005
>Last-Modified:  Wed Mar 09 19:50:45 GMT 2005
>Originator:     Jin-Hwan Cho
>Release:        FreeBSD 5.1-RELEASE i386
>Organization:
Korean TeX Users Group
>Environment:
System: FreeBSD hep-ph.konkuk.ac.kr 5.1-RELEASE FreeBSD 5.1-RELEASE #0: Thu
Jun 5 02:55:42 GMT 2003
root@wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC i386
Packages: python-2.2.2_2, teTeX-2.0.2_2 (kpathsea library version 3.4.5)
>Description:
  Recently I am trying to write a Python extension using the kpathsea
library.
  It was simple and everying went smoothly. But I got a severe problem in
  FreeBSD. Even simple code did not work in FreeBSD. After trying some
tests,
  I found where the problem occurred. That was "cnf.c" in the kpathsea
  library (contained in teTeX-2.0.2_2 package). There is a place in "cnf.c"
  calling "hash_create()" function (defined in hash.c). However, in FreeBSD,
  the "hash_create()" was not called properly. After changing the name
  "hash_create()" to another one, for example, "hash_create2()", everything
  worked fine. I'd like to know exact reason why this kind of problem
  occurs in FreeBSD.
>How-To-Repeat:
  On FreeBSD system with python-2.2.2_2 and teTeX-2.0.2_2 installed,
  using the attached three files, run the following command

  python setup.py install

  and then run

  python kpse_test.py

  The result is "Segmentation fault (core dumped)".
>Fix:
  The problem above can be fixed by modifying the kpathsea library itself
  as follows:

  Change the name of "hash_create" function (defined in hash.c) to another
  name, for example, "hash_create2" from several files, cnf.c, db.c, dir.c,
  fontname.c, hash.c, and hash.h.

  It seems quite curious because there was no problem in cygwin.

--- setup.py begins here ---
from distutils.core import setup, Extension

kpse_module = Extension('kpse',
    include_dirs = ['/usr/local/include'],
    libraries = ['kpathsea'],
    library_dirs = ['/usr/local/lib'],
    sources = ['kpse_module.c'])

setup(name = 'kpse', ext_modules = [kpse_module])
--- setup.py ends here ---

--- kpse_module.c begins here ---
#include <Python.h>
#include <kpathsea/kpathsea.h>

static PyObject *SetProgramName (PyObject *self, PyObject *args)
{
  string argv0, progname;
  if (!PyArg_ParseTuple(args, "sz", &argv0, &progname)) return NULL;
  kpse_set_program_name(argv0, progname);
  return Py_BuildValue("");
}

static PyObject *VarValue (PyObject *self, PyObject *args)
{
  string var;
  if (!PyArg_ParseTuple(args, "s", &var)) return NULL;
  return Py_BuildValue("z", kpse_var_value(var));
}

static PyMethodDef kpseMethods[] = {
  {"set_program_name", SetProgramName, METH_VARARGS, NULL},
  {"var_value", VarValue, METH_VARARGS, NULL},
  {NULL, NULL, 0, NULL} /* sentinel */
};

void initkpse (void)
{
  Py_InitModule("kpse", kpseMethods);
}
--- kpse_module.c ends here ---

--- kpse_test.py begins here ---
import kpse
kpse.set_program_name('/usr/local/bin/kpsewhich', None)
print kpse.var_value('TEXMFMAIN')
--- kpse_test.py ends here ---

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->analyzed 
State-Changed-By: kris 
State-Changed-When: Fri Dec 26 08:00:40 PST 2003 
State-Changed-Why:  
The cause of the problem is understood, it remains to be determined 
whether or not it is a bug in FreeBSD. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=60243 

From: Kris Kennaway <kris@obsecurity.org>
To: Jin-Hwan Cho <chofchof@kias.re.kr>
Cc: FreeBSD-gnats-submit@FreeBSD.org,
	"Cho, Jin-Hwan" <chofchof@ktug.or.kr>
Subject: Re: misc/60243: Problem in calling kpathsea library from Python extension
Date: Fri, 26 Dec 2003 08:00:35 -0800

 On Mon, Dec 15, 2003 at 09:48:59AM +0900, Jin-Hwan Cho wrote:
 
 >   calling "hash_create()" function (defined in hash.c). However, in FreeBSD,
 >   the "hash_create()" was not called properly. After changing the name
 >   "hash_create()" to another one, for example, "hash_create2()", everything
 >   worked fine. I'd like to know exact reason why this kind of problem
 >   occurs in FreeBSD.
 
 hash_create is a symbol defined in libc.so.4.  You're calling that
 function instead of the one in your library.  I'm not sure whether
 this symbol needs to be exported from libc, because it doesn't appear
 to be in libc.so.5.
 
 Kris

From: Kris Kennaway <kris@obsecurity.org>
To: Jin-Hwan Cho <chofchof@ktug.or.kr>
Cc: Kris Kennaway <kris@obsecurity.org>,
	FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: misc/60243: Problem in calling kpathsea library from Python extension
Date: Sat, 21 Feb 2004 17:54:15 -0800

 On Sat, Dec 27, 2003 at 02:20:47PM +0900, Jin-Hwan Cho wrote:
 > Kris Kennaway wrote:
 > 
 > > hash_create is a symbol defined in libc.so.4.  You're calling that
 > > function instead of the one in your library.  I'm not sure whether
 > > this symbol needs to be exported from libc, because it doesn't appear
 > > to be in libc.so.5.
 > 
 > I could find the symbol "hash_create" in libc.so.5 as follows:
 > 
 > /usr/lib$ objdump -T libc.so.5 | grep hash
 > 00000094 l    d  .hash  00000000
 > 0001e020 g    DF .text  000000d2 hash_destroy
 > 000231d0 g    DF .text  00000021 uuid_hash
 > 0001e350 g    DF .text  0000025a hash_stats
 > 0001e2c0 g    DF .text  00000089 hash_purge
 > 000c43d4 g    DO .data  00000004 __default_hash
 > 0001e100 g    DF .text  000000c7 hash_search
 > 0001e250 g    DF .text  00000067 hash_traverse
 > 0001def0 g    DF .text  0000008d hash_create
 > 000a3840 g    DF .text  00000031 __call_hash
 > 000a24c0 g    DF .text  000003e6 __hash_open
 > 
 > Is there any way to use "hash_create" in the kpathsea library
 > instead of the standard libc?
 
 Sorry for the delay in responding to this.  Did you ever resolve this?
 
 I wonder if you are linking to libc before libkpathsea (e.g. -lc
 -lkpathsea); symbols are resolved to the first library in the sequence
 that contains them.
 
 Also, I can't reproduce that libc.so.5 contains the hash_create symbol:
 
 kkenn@enigma:/lib objdump -T libc.so.5 | grep hash
 00000000000000e8 l    d  .hash  0000000000000000
 000000000003b4a0 g    DF .text  0000000000000020 uuid_hash
 00000000001ee970 g    DO .data  0000000000000008 __default_hash
 00000000000cff00 g    DF .text  0000000000000040 __call_hash
 00000000000cec80 g    DF .text  00000000000003a4 __hash_open
 
 Kris

From: Kris Kennaway <kris@obsecurity.org>
To: Jin-Hwan Cho <chofchof@ktug.or.kr>
Cc: Kris Kennaway <kris@obsecurity.org>,
	freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/60243: Problem in calling kpathsea library from Python extension
Date: Sun, 22 Feb 2004 18:48:59 -0800

 On Mon, Feb 23, 2004 at 11:41:53AM +0900, Jin-Hwan Cho wrote:
 
 > >>Is there any way to use "hash_create" in the kpathsea library
 > >>instead of the standard libc?
 > >
 > >Sorry for the delay in responding to this.  Did you ever resolve this?
 > 
 > Surely. In my FreeBSD 5 machine, the command above gives exactly.
 > Here is another information of my libc.so.5.
 > 
 > /usr/lib$ ls -al libc.so.5
 > -r--r--r--  1 root  wheel  886848 Jun  5  2003 libc.so.5
 > /usr/lib$ objdump -f libc.so.5
 > 
 > libc.so.5:     file format elf32-i386-freebsd
 > architecture: i386, flags 0x00000150:
 > HAS_SYMS, DYNAMIC, D_PAGED
 > start address 0x0001c470
 
 OK, you have an old 5.x installation.  It was fixed at some point in
 the last 8 months.
 
 > >I wonder if you are linking to libc before libkpathsea (e.g. -lc
 > >-lkpathsea); symbols are resolved to the first library in the sequence
 > >that contains them.
 > 
 > I already new because there was some discussion on that topic in the
 > TeX world. Here is the compiling commands generated by Python.
 > 
 > ~/test/kpathsea$ python setup.py build
 > running build
 > running build_ext
 > building 'kpse' extension
 > creating build
 > creating build/temp.freebsd-5.1-RELEASE-i386-2.2
 > cc -DNDEBUG -O -pipe -mcpu=pentiumpro -D_THREAD_SAFE -fPIC 
 > -DHASH_SHARED -I/usr/local/include -I/usr/local/include/python2.2 -c 
 > kpse_module.c -o build/temp.freebsd-5.1-RELEASE-i386-2.2/kpse_module.o
 > creating build/lib.freebsd-5.1-RELEASE-i386-2.2
 > cc -shared -lc_r build/temp.freebsd-5.1-RELEASE-i386-2.2/kpse_module.o 
 > -L/usr/local/lib -lkpathsea -o 
 > build/lib.freebsd-5.1-RELEASE-i386-2.2/kpse.so
 > 
 > I tried the last link command without -lc_r and -lkpathsea -lc_r, etc.
 > But all failed. Could you tell me what I missed?
 > 
 > >Also, I can't reproduce that libc.so.5 contains the hash_create symbol:
 > >
 > >kkenn@enigma:/lib objdump -T libc.so.5 | grep hash
 > >00000000000000e8 l    d  .hash  0000000000000000
 > >000000000003b4a0 g    DF .text  0000000000000020 uuid_hash
 > >00000000001ee970 g    DO .data  0000000000000008 __default_hash
 > >00000000000cff00 g    DF .text  0000000000000040 __call_hash
 > >00000000000cec80 g    DF .text  00000000000003a4 __hash_open
 > 
 > Is your operating system FreeBSD? My machine does not have the directory
 > /lib. Actually I tested my code in another operating systems, but no
 > problem yet; even there was no problem in Mac OS X.
 
 FreeBSD 5.2 moved a number of libraries from /usr/lib to /lib to allow
 a dynamically-linked root partition.  This aspect is unrelated to your
 problem, but it sounds like upgrading to 5.2-RELEASE will fix it
 anyway.
 
 Kris
State-Changed-From-To: analyzed->feedback 
State-Changed-By: linimon 
State-Changed-When: Wed Sep 1 04:43:14 GMT 2004 
State-Changed-Why:  
Is this still a problem on FreeBSD 5.2 or -CURRENT? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=60243 
State-Changed-From-To: feedback->closed 
State-Changed-By: vs 
State-Changed-When: Wed Mar 9 19:50:26 GMT 2005 
State-Changed-Why:  
Feedback timeout 

http://www.freebsd.org/cgi/query-pr.cgi?pr=60243 
>Unformatted:
