Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12 - Mailing list pgsql-general

From rjhb@bb-c.de (Rainer J.H. Brandt)
Subject Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12
Date
Msg-id 22921.53987.62224.334831@x2270a.bb-c.de
Whole thread Raw
In response to Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12  (Adrian Klaver <adrian.klaver@aklaver.com>)
Responses Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Hi,

I'm coming back to an old thread.  My original issue isn't resolved yet;
this is just to answer your questions below.

Adrian Klaver writes:
> [...]
> I do not build on OS X so this is a bit of a reach for me, still here it
> goes. From your original post the error was:
>
> "reating conversions ... FATAL:  could not load library
> "/opt/bb/170704/lib/postgresql/ascii_and_mic.so":
> dlopen(/opt/bb/170704/lib/postgresql/ascii_and_mic.so, 10): Symbol not
> found: _check_encoding_conversion_args
>       Referenced from: /opt/bb/170704/lib/postgresql/ascii_and_mic.so
>       Expected in: /opt/bb/170704/bin/postgres
>      in /opt/bb/170704/lib/postgresql/ascii_and_mic.so"
>
> You also mentioned you have done 32 bit builds that worked.
I was wrong about that.  Everything was 64 bit.

> Now when I do 64 bit build on Linux the libraries end up in ~/lib64/:
On macOS, everything goes into the same $PREFIX/lib.  A library can be
32bit, or 64bit, or both (a "universal binary").  macOS has a tool
named "lipo" that can create those.  Usually, you get 64bit-only libraries.
Once I realized this (thanks to Tom Lane), I dropped all configure
arguments related to that.

> /usr/local/pgsql/lib64> l ascii_and_mic.so
> -rwxr-xr-x 1 root root 9760 Jun 14 07:32 ascii_and_mic.so*
>
> Yet in your case I see ~/lib/. Not sure how OS X handles 32bit/64bit,
> which is where I am reaching. Just wondering if there is cross
> contamination going on?
No, that's not the problem.  I only have 64 bit stuff.

> ldd ascii_and_mic.so
On macOS, there's no ldd.  The equivalent is "otool -L".
It looks like this (line breaks inserted for readability):

  % file /opt/pg/lib/postgresql/ascii_and_mic.so
  /opt/pg/lib/postgresql/ascii_and_mic.so: Mach-O 64-bit bundle x86_64

  % otool -L /opt/pg/lib/postgresql/ascii_and_mic.so
  /opt/pg/lib/postgresql/ascii_and_mic.so:
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
      current version 1238.60.2)

BTW, libSystem.B.dylib is a universal binary:

  % file /usr/lib/libSystem.B.dylib
  /usr/lib/libSystem.B.dylib: Mach-O universal binary with 2 architectures:
    [x86_64: Mach-O 64-bit dynamically linked shared library x86_64]
    [i386: Mach-O dynamically linked shared library i386]
  /usr/lib/libSystem.B.dylib (for architecture x86_64):
    Mach-O 64-bit dynamically linked shared library x86_64
  /usr/lib/libSystem.B.dylib (for architecture i386):
    Mach-O dynamically linked shared library i386

This 32/64 business isn't the problem, though.

I've found out that everything works if I type the configure/make commands
in my shell (which isn't what I said before, sorry about that), but stops
working if I put them into a Perl script (which is how I automate things
across OSes).  The weird thing is that the commands are absolutely the same,
and environment is the same, too.  Anyway, it seems clear that the error is
on my side.  Given enough time, I will find it and report to you.

Thanks, Rainer
--
Email: rjhb@bb-c.de  +  Telefon: 02448/919126  +  Mobiltelefon: 0172/9593205
Brandt & Brandt Computer GmbH  +  Am Wiesenpfad 6, 53340 Meckenheim
Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt
Handelsregister: Amtsgericht Bonn, HRB 10513


pgsql-general by date:

Previous
From: Ertan Küçükoğlu
Date:
Subject: [GENERAL] ZeosLib database components - uuid inserts using libpq
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12