make install fails on macosx for Python-2.1a2

[1f758259-2d8b-450e-8266-8bfd902bdc65]

BPO	231170
Nosy	@tim-one, @nascheme

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = created_at = labels = ['build'] title = 'make install fails on macosx for Python-2.1a2' updated_at = user = 'https://bugs.python.org/sdm7g' ``` bugs.python.org fields: ```python activity = actor = 'nascheme' assignee = 'none' closed = True closed_date = None closer = None components = ['Build'] creation = creator = 'sdm7g' dependencies = [] files = [] hgrepos = [] issue_num = 231170 keywords = [] message_count = 8.0 messages = ['3169', '3170', '3171', '3172', '3173', '3174', '3175', '3176'] nosy_count = 4.0 nosy_names = ['tim.peters', 'nobody', 'nascheme', 'sdm7g'] pr_nums = [] priority = 'normal' resolution = 'wont fix' stage = None status = 'closed' superseder = None type = None url = 'https://bugs.python.org/issue231170' versions = [] ```

[1f758259-2d8b-450e-8266-8bfd902bdc65]

Python-2.1a2 on macosx make install fails trying to ranlib the shared library:

ranlib: file: /usr/local/lib/python2.1/config/libpython2.1.dylib is not an archive

(This bug wasn't in 2.0, and I don't think was in 2.1a1.)

-- Steve M.

[3772858d-27d8-44b0-a664-d68674859f36]

Commenting out the $(RANLIB) line in the install section of Makefile seems to fix the problem on macosx, but I don't know if it is a problemon any other platforms.

   @if test -d $(LDLIBRARY); then :; else \\
            $(INSTALL_DATA) $(LDLIBRARY) $(LIBPL)/$(LDLIBRARY) ; \\

# $(RANLIB) $(LIBPL)/$(LDLIBRARY) ; \

-- Steve M.

[1f758259-2d8b-450e-8266-8bfd902bdc65]

Well, the missing libtool switch to tell it the library will be installed somewhere else is:

-install_name $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to be unable to find the os.module and sys.path is set all wrong. (and it fails somewhere else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK conditional code in getpath.c is getting the path not from the executable, but from the library.

[1f758259-2d8b-450e-8266-8bfd902bdc65]

Note: after removing the ranlib, installation succeeds, and the program works when you are in the python directory, however, running the installed program from somewhere else gives the fatal error:

dyld: python2.1 can't open library: libpython2.1.dylib (No such file or directory, errno = 2)

If you look at the python executable with "otool -L" , you can see that system frameworks, for example, have their complete pathnames, while libpython2.1.dylib has no path, so it's expected in the current directory.

(looking for the libtool option to correct this...) -- Steve M.

[1f758259-2d8b-450e-8266-8bfd902bdc65]

Well, the missing libtool switch to tell it the library will be installed somewhere else is:

-install_name $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to be unable to find the os.module and sys.path is set all wrong. (and it fails somewhere else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK conditional code in getpath.c is getting the path not from the executable, but from the library.

[1f758259-2d8b-450e-8266-8bfd902bdc65]

Well, the missing libtool switch to tell it the library will be installed somewhere else is:

-install_name $(LIBPL)/$(LDLIBRARY)

but building with that switch causes python to be unable to find the os.module and sys.path is set all wrong. (and it fails somewhere else in 'make' )

It looks like the WITH_NEXT_FRAMEWORK conditional code in getpath.c is getting the path not from the executable, but from the library.

[tim-one]

Assigned to Neil for the heck of it.

[nascheme]

Steve says things are okay if --with-next-framework is not specified.