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

Mailing List Archive: GnuPG: devel

Building on OS X Lion

 

 

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


nicholas.cole at gmail

Jul 25, 2011, 3:31 AM

Post #1 of 13 (1566 views)
Permalink
Building on OS X Lion

Dear List,

Building 1.4.11 on OS X Lion (Intel Core 2 Duo) fails with the following error:

Is this a known problem?

Best wishes,

Nicholas

gcc -g -O2 -Wall -Wno-pointer-sign -o gpg gpg.o build-packet.o
compress.o compress-bz2.o free-packet.o getkey.o keydb.o keyring.o
seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o
progress.o misc.o openfile.o keyid.o parse-packet.o status.o
plaintext.o sig-check.o keylist.o signal.o cardglue.o tlv.o
card-util.o app-openpgp.o iso7816.o apdu.o ccid-driver.o pkclist.o
skclist.o pubkey-enc.o passphrase.o seckey-cert.o encr-data.o cipher.o
encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o
import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o keygen.o
pipemode.o helptext.o keyserver.o photoid.o exec.o
../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -liconv
../intl/libintl.a -liconv -Wl,-framework -Wl,CoreFoundation -lz
-lbz2 -L/opt/local/lib -lusb
Undefined symbols for architecture x86_64:
"_iconv_open", referenced from:
_utf8_to_native in libutil.a(strgutil.o)
_native_to_utf8 in libutil.a(strgutil.o)
_set_native_charset in libutil.a(strgutil.o)
__nl_find_msg in libintl.a(dcigettext.o)
"_iconv", referenced from:
_utf8_to_native in libutil.a(strgutil.o)
_native_to_utf8 in libutil.a(strgutil.o)
__nl_find_msg in libintl.a(dcigettext.o)
"_iconv_close", referenced from:
_utf8_to_native in libutil.a(strgutil.o)
_native_to_utf8 in libutil.a(strgutil.o)
_set_native_charset in libutil.a(strgutil.o)
ld: symbol(s) not found for architecture x86_64

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


nicholas.cole at gmail

Jul 25, 2011, 8:38 AM

Post #2 of 13 (1553 views)
Permalink
Re: Building on OS X Lion [In reply to]

On Mon, Jul 25, 2011 at 11:31 AM, Nicholas Cole <nicholas.cole [at] gmail> wrote:
> Dear List,
>
> Building 1.4.11 on OS X Lion (Intel Core 2 Duo) fails with the following error:
>
> Is this a known problem?

My mistake - I think I might have had some 3rd party libraries
confusing the build process!

N

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


nicholas.cole at gmail

Jul 25, 2011, 8:40 AM

Post #3 of 13 (1544 views)
Permalink
Re: Building on OS X Lion [In reply to]

On Mon, Jul 25, 2011 at 4:38 PM, Nicholas Cole <nicholas.cole [at] gmail> wrote:
> On Mon, Jul 25, 2011 at 11:31 AM, Nicholas Cole <nicholas.cole [at] gmail> wrote:
>> Dear List,
>>
>> Building 1.4.11 on OS X Lion (Intel Core 2 Duo) fails with the following error:
>>
>> Is this a known problem?
>
> My mistake - I think I might have had some 3rd party libraries
> confusing the build process!

But a rebuilt gpg is still failing with this error:

nicholas$ gpg --card-status
gpg(97903) malloc: *** mmap(size=2608166010582208512) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
gpg: out of memory while allocating 26 bytes

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


alex at gpgtools

Jul 25, 2011, 8:44 AM

Post #4 of 13 (1550 views)
Permalink
Re: Building on OS X Lion [In reply to]

Hi Nicholas,

actually, I've the same issue when compiling MacGPG1 on Lion using
this script: https://github.com/GPGTools/MacGPG1/blob/master/build-script.sh
(also removed the ppc part)

Best regards, Alex


On Mon, Jul 25, 2011 at 17:38, Nicholas Cole <nicholas.cole [at] gmail> wrote:
> On Mon, Jul 25, 2011 at 11:31 AM, Nicholas Cole <nicholas.cole [at] gmail> wrote:
>> Dear List,
>>
>> Building 1.4.11 on OS X Lion (Intel Core 2 Duo) fails with the following error:
>>
>> Is this a known problem?
>
> My mistake - I think I might have had some 3rd party libraries
> confusing the build process!
>
> N
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel [at] gnupg
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>



--
gpgtools.org

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


wk at gnupg

Jul 25, 2011, 8:49 AM

Post #5 of 13 (1539 views)
Permalink
Re: Building on OS X Lion [In reply to]

On Mon, 25 Jul 2011 12:31, nicholas.cole [at] gmail said:

> ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -liconv
^^^^^^^
> ../intl/libintl.a -liconv -Wl,-framework -Wl,CoreFoundation -lz
^^^^^^^
It seems ld doesn't re-scan libiconv again and messes up entirely. Is
the GNU ld or the system's ld?

Try manual linking without the first -liconv .


Shalom-Salam,

Werner

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


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


dshaw at JABBERWOCKY

Jul 25, 2011, 9:10 AM

Post #6 of 13 (1541 views)
Permalink
Re: Building on OS X Lion [In reply to]

On Jul 25, 2011, at 11:40 AM, Nicholas Cole wrote:

> On Mon, Jul 25, 2011 at 4:38 PM, Nicholas Cole <nicholas.cole [at] gmail> wrote:
>> On Mon, Jul 25, 2011 at 11:31 AM, Nicholas Cole <nicholas.cole [at] gmail> wrote:
>>> Dear List,
>>>
>>> Building 1.4.11 on OS X Lion (Intel Core 2 Duo) fails with the following error:
>>>
>>> Is this a known problem?
>>
>> My mistake - I think I might have had some 3rd party libraries
>> confusing the build process!
>
> But a rebuilt gpg is still failing with this error:
>
> nicholas$ gpg --card-status
> gpg(97903) malloc: *** mmap(size=2608166010582208512) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> gpg: out of memory while allocating 26 bytes

Interesting. 2608166010582208512 in binary is 10010000110010000100010010101100000000000000000001000000000000. Looks like the lower 32 bits are correct (being equal to 4096, which makes sense in this context), but the upper 32 bits are uninitialized or otherwise mangled.

I haven't upgraded to Lion yet, so I can't easily run this myself, but can you get a backtrace via gdb? Just run gpg under gdb, and "break malloc_error_break", then "run --card-status". It'll stop at the breakpoint, and you can then do "bt full".

David


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


nicholas.cole at gmail

Jul 25, 2011, 9:20 AM

Post #7 of 13 (1548 views)
Permalink
Re: Building on OS X Lion [In reply to]

On Mon, Jul 25, 2011 at 4:49 PM, Werner Koch <wk [at] gnupg> wrote:
> On Mon, 25 Jul 2011 12:31, nicholas.cole [at] gmail said:
>
>> ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -liconv
>                                                          ^^^^^^^
>> ../intl/libintl.a -liconv  -Wl,-framework -Wl,CoreFoundation  -lz
>                    ^^^^^^^
> It seems ld doesn't re-scan libiconv again and messes up entirely.  Is
> the GNU ld or the system's ld?

Dear Warner,

The system ld.

Macintosh-2:gnupg-1.4.11 nicholas$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-123.2.1
llvm version 3.0svn, from Apple Clang 2.1 (build 163.7.1)

Best wishes,

Nicholas

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


wk at gnupg

Jul 25, 2011, 9:26 AM

Post #8 of 13 (1547 views)
Permalink
Re: Building on OS X Lion [In reply to]

On Mon, 25 Jul 2011 17:40, nicholas.cole [at] gmail said:

> nicholas$ gpg --card-status
> gpg(97903) malloc: *** mmap(size=2608166010582208512) failed (error code=12)

That is probably a bug in the pcsc code: We dlopen the pcsc library and
have our own prototypes for the functions. However we use "unsigned
long" instead of the "DWORD" type Windows originally used. Thus we
have a 64/32 bit mismatch if tyhe pcsc library is 32 bit.

See also https://bugs.gnupg.org/gnupg/issue1358 .


Shalom-Salam,

Werner

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


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


sebastien.lorquet at gmail

Jul 25, 2011, 12:26 PM

Post #9 of 13 (1537 views)
Permalink
Re: Building on OS X Lion [In reply to]

Hi,

some work was done recently in pcsclite regarding 64-bit compatibility.
Contacting Ludovic Rousseau on the pcsclite mailing list might be a good
thing.

Regards
Sebastien Lorquet

On Mon, Jul 25, 2011 at 6:26 PM, Werner Koch <wk [at] gnupg> wrote:

> On Mon, 25 Jul 2011 17:40, nicholas.cole [at] gmail said:
>
> > nicholas$ gpg --card-status
> > gpg(97903) malloc: *** mmap(size=2608166010582208512) failed (error
> code=12)
>
> That is probably a bug in the pcsc code: We dlopen the pcsc library and
> have our own prototypes for the functions. However we use "unsigned
> long" instead of the "DWORD" type Windows originally used. Thus we
> have a 64/32 bit mismatch if tyhe pcsc library is 32 bit.
>
> See also https://bugs.gnupg.org/gnupg/issue1358 .
>
>
> Shalom-Salam,
>
> Werner
>
> --
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
>
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel [at] gnupg
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>


nicholas.cole at gmail

Jul 25, 2011, 1:58 PM

Post #10 of 13 (1580 views)
Permalink
Re: Building on OS X Lion [In reply to]

On Mon, Jul 25, 2011 at 5:10 PM, David Shaw <dshaw [at] jabberwocky> wrote:
> On Jul 25, 2011, at 11:40 AM, Nicholas Cole wrote:
>
>> On Mon, Jul 25, 2011 at 4:38 PM, Nicholas Cole <nicholas.cole [at] gmail> wrote:
>>> On Mon, Jul 25, 2011 at 11:31 AM, Nicholas Cole <nicholas.cole [at] gmail> wrote:
>>>> Dear List,
>>>>
>>>> Building 1.4.11 on OS X Lion (Intel Core 2 Duo) fails with the following error:
>>>>
>>>> Is this a known problem?
>>>
>>> My mistake - I think I might have had some 3rd party libraries
>>> confusing the build process!
>>
>> But a rebuilt gpg is still failing with this error:
>>
>> nicholas$ gpg --card-status
>> gpg(97903) malloc: *** mmap(size=2608166010582208512) failed (error code=12)
>> *** error: can't allocate region
>> *** set a breakpoint in malloc_error_break to debug
>> gpg: out of  memory while allocating 26 bytes
>
> Interesting.  2608166010582208512 in binary is 10010000110010000100010010101100000000000000000001000000000000.  Looks like the lower 32 bits are correct (being equal to 4096, which makes sense in this context), but the upper 32 bits are uninitialized or otherwise mangled.
>
> I haven't upgraded to Lion yet, so I can't easily run this myself, but can you get a backtrace via gdb?  Just run gpg under gdb, and "break malloc_error_break", then "run --card-status".  It'll stop at the breakpoint, and you can then do "bt full".

Dear David,

I hope that the following output is useful!

Best wishes,

Nicholas

Macintosh-2:gnupg-1.4.11 nicholas$ gdb ./g10/gpg
GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul 1 10:50:06 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for
shared libraries ...... done

(gdb) break malloc_error_break
Function "malloc_error_break" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (malloc_error_break) pending.
(gdb) run --card-status
Starting program: /Users/nicholas/Downloads/gnupg-1.4.11/g10/gpg --card-status
Reading symbols for shared libraries +++++............................... done
Breakpoint 1 at 0x7fff8f0606c0
Pending breakpoint 1 - "malloc_error_break" resolved
Reading symbols for shared libraries . done
gpg(20035) malloc: *** mmap(size=2608166010582208512) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

Breakpoint 1, 0x00007fff8f0606c0 in malloc_error_break ()
(gdb) bt full
#0 0x00007fff8f0606c0 in malloc_error_break ()
No symbol table info available.
#1 0x00007fff8f023477 in szone_error ()
No symbol table info available.
#2 0x00007fff8f025404 in allocate_pages ()
No symbol table info available.
#3 0x00007fff8f025ba4 in large_malloc ()
No symbol table info available.
#4 0x00007fff8f02bdee in szone_malloc_should_clear ()
No symbol table info available.
#5 0x00007fff8f0603c8 in malloc_zone_malloc ()
No symbol table info available.
#6 0x00007fff8f0611a4 in malloc ()
No symbol table info available.
#7 0x000000010009aaad in xmalloc (n=4296171520) at memory.c:443
p = 0x0
#8 0x00000001000417f2 in open_pcsc_reader_direct [inlined] () at apdu.c:1499
nreader = 2608166010582204441
slot = 0
err = 0
list = 0x0
#9 0x00000001000417f2 in open_pcsc_reader [inlined] () at
/Users/nicholas/Downloads/gnupg-1.4.11/g10/apdu.c:1785
nreader = 2608166010582204441
slot = 0
err = 0
list = 0x0
#10 0x00000001000417f2 in apdu_open_reader (portstr=0x0) at apdu.c:2463
nreader = 2608166010582204441
slot = 0
err = 0
list = 0x0
#11 0x000000010002d339 in open_card () at cardglue.c:453
No locals.
#12 0x000000010002f323 in agent_learn (info=0x7fff5fbff0f0) at cardglue.c:874
stamp = 140735592927652
serial = 0x7fff5fbff0b0 ""
app = (app_t) 0x0
ctrl = {
status_cb = 0x10012a268,
status_cb_arg = 0xa8
}
rc = <value temporarily unavailable, due to optimizations>
#13 0x0000000100030e50 in card_status (fp=0x7fff7ca664e8,
serialno=0x0, serialnobuflen=0) at card-util.c:369
info = {
error = 1221232,
apptype = 0x100129a00 "",
serialno = 0xffffffffffffffe0 <Address 0xffffffffffffffe0 out of bounds>,
disp_name = 0x5 <Address 0x5 out of bounds>,
disp_lang = 0x100126000 "",
disp_sex = 8192,
pubkey_url = 0x7fff5fbff1b0 "",
login_data = 0x7fff8f0275c3 "A??P\b",
private_do = {0x1002fc080 "", 0xad <Address 0xad out of bounds>,
0x0, 0x40000000 <Address 0x40000000 out of bounds>},
cafpr1valid = -32 '?',
cafpr2valid = -15 '?',
cafpr3valid = -65 '?',
cafpr1 = "_?\000\000?u\002??\000\000??/\000\001\000",
cafpr2 = "\000?\000\000\000\000\000\000\000\000\000
\000\001\000\000\000?\000",
cafpr3 = "\000\000\000\000\000\000\000
\000\001\000\000\000@\000\000\000\000\000",
fpr1valid = 0 '\0',
fpr2valid = 1 '\001',
fpr3valid = 0 '\0',
fpr1 = "\000\000\000\000\000\000? \000\001\000\000\000\000\000 \000\001",
fpr2 = "\000\000?? \000\001\000\000\000\000`\022\000\001\000\000\000??",
fpr3 = " \000\001\000\000\000\b? \000\001\000\000\000\000\000\000\000\000",
fpr1time = 1204224,
fpr2time = 1,
fpr3time = 64,
sig_counter = 140734799802928,
chv1_cached = -1895430263,
is_v2 = 32767,
chvmaxlen = {0, 0, 0},
chvretry = {0, 64, 0},
key_attr = {{
algo = 0,
nbits = 0
}, {
algo = 2140680,
nbits = 1
}, {
algo = 0,
nbits = 0
}},
extcap = {
ki = 0,
aac = 0
}
}
uval = 0
rc = 2140680
thefpr = (const unsigned char *) 0x0
#14 0x0000000100007b19 in main (argc=0, argv=0x7fff5fbff970) at gpg.c:3926
remusr = (STRLIST) 0x0
nrings = (STRLIST) 0x0
configname = 0x0
sl = (STRLIST) 0x0
cmd = aCardStatus
orig_argc = 2
default_configname = 0x0
locusr = (STRLIST) 0x0
sec_nrings = (STRLIST) 0x0
configlineno = 228
orig_argv = (char **) 0x7fff5fbff960
a = (IOBUF) 0x0
pargs = {
argc = 0x7fff5fbff61c,
argv = 0x7fff5fbff610,
flags = 32769,
err = 0,
r_opt = 0,
r_type = 0,
r = {
ret_int = 0,
ret_long = 0,
ret_ulong = 0,
ret_str = 0x0
},
internal = {
idx = 2,
inarg = 0,
stopped = 0,
last = 0x7fff5fbffab7 "--card-status",
aliases = 0x0,
cur_alias = 0x0
}
}
may_coredump = 0
afx = {
refcount = 0,
what = 0,
only_keyblocks = 0,
hdrlines = 0x0,
no_openpgp_data = 0,
inp_checked = 0,
inp_bypass = 0,
in_cleartext = 0,
not_dash_escaped = 0,
hashes = 0,
faked = 0,
truncated = 0,
qp_detected = 0,
pgp2mode = 0,
eol = "\000\000",
buffer = 0x0,
buffer_size = 0,
buffer_len = 0,
buffer_pos = 0,
radbuf = "\000\000\000",
idx = 0,
idx2 = 0,
crc = 0,
status = 0,
cancel = 0,
any_data = 0,
pending_lf = 0
}
rc = 0
(gdb)

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


dshaw at jabberwocky

Jul 25, 2011, 8:22 PM

Post #11 of 13 (1545 views)
Permalink
Re: Building on OS X Lion [In reply to]

On Jul 25, 2011, at 4:58 PM, Nicholas Cole wrote:

> On Mon, Jul 25, 2011 at 5:10 PM, David Shaw <dshaw [at] jabberwocky> wrote:
>> On Jul 25, 2011, at 11:40 AM, Nicholas Cole wrote:
>>
>>> On Mon, Jul 25, 2011 at 4:38 PM, Nicholas Cole <nicholas.cole [at] gmail> wrote:
>>>> On Mon, Jul 25, 2011 at 11:31 AM, Nicholas Cole <nicholas.cole [at] gmail> wrote:
>>>>> Dear List,
>>>>>
>>>>> Building 1.4.11 on OS X Lion (Intel Core 2 Duo) fails with the following error:
>>>>>
>>>>> Is this a known problem?
>>>>
>>>> My mistake - I think I might have had some 3rd party libraries
>>>> confusing the build process!
>>>
>>> But a rebuilt gpg is still failing with this error:
>>>
>>> nicholas$ gpg --card-status
>>> gpg(97903) malloc: *** mmap(size=2608166010582208512) failed (error code=12)
>>> *** error: can't allocate region
>>> *** set a breakpoint in malloc_error_break to debug
>>> gpg: out of memory while allocating 26 bytes
>>
>> Interesting. 2608166010582208512 in binary is 10010000110010000100010010101100000000000000000001000000000000. Looks like the lower 32 bits are correct (being equal to 4096, which makes sense in this context), but the upper 32 bits are uninitialized or otherwise mangled.
>>
>> I haven't upgraded to Lion yet, so I can't easily run this myself, but can you get a backtrace via gdb? Just run gpg under gdb, and "break malloc_error_break", then "run --card-status". It'll stop at the breakpoint, and you can then do "bt full".
>
> Dear David,
>
> I hope that the following output is useful!

Werner spotted it earlier. This looks like a 32-bit/64-bit mismatch between gpg and pcsc. It's an open bug at https://bugs.gnupg.org/gnupg/issue1358

David


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


martin at martinpaljak

Jul 25, 2011, 10:57 PM

Post #12 of 13 (1527 views)
Permalink
Re: Building on OS X Lion [In reply to]

On Jul 25, 2011, at 7:26 PM, Werner Koch wrote:

> On Mon, 25 Jul 2011 17:40, nicholas.cole [at] gmail said:
>
>> nicholas$ gpg --card-status
>> gpg(97903) malloc: *** mmap(size=2608166010582208512) failed (error code=12)
>
> That is probably a bug in the pcsc code: We dlopen the pcsc library and
> have our own prototypes for the functions. However we use "unsigned
> long" instead of the "DWORD" type Windows originally used. Thus we
> have a 64/32 bit mismatch if tyhe pcsc library is 32 bit.
Why don't you use the provided .h files?

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


wk at gnupg

Jul 26, 2011, 1:47 AM

Post #13 of 13 (1541 views)
Permalink
Re: Building on OS X Lion [In reply to]

On Tue, 26 Jul 2011 07:57, martin [at] martinpaljak said:

>> have a 64/32 bit mismatch if tyhe pcsc library is 32 bit.
> Why don't you use the provided .h files?

Because that adds yet another dependency to GnuPG and I try to avoid
this. Actually many people are better off not to use PC/SC but the
internal driver. This is the reason why PCSC and the old ctAPI are
dlopened.


Salam-Shalom,

Werner

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


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

GnuPG devel 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.