[issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library

2014-08-03 Thread koobs

Changes by koobs koobs.free...@gmail.com:


--
nosy: +koobs

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11445
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library

2013-07-06 Thread Ronald Oussoren

Changes by Ronald Oussoren ronaldousso...@mac.com:


Removed file: http://bugs.python.org/file21243/issue-11445.txt

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11445
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library

2013-07-06 Thread Ronald Oussoren

Ronald Oussoren added the comment:

I've attached an updated patch (against the 2.7 branch, the same idea should 
work for 3.3 and default). 

This does two things:

1) Explicity add '-Wl,-search_paths_first' to LDFLAGS on Mac OS X.

   This ensures that the linker behaves like other platforms: in every
   directory on the search path look for both shared and static libraries,
   the default (upto xcode 4) was to first walk the entire path looking
   for dylibs, then walk the path again looking for static libraries.

2) Change the order of arguments when linking $(BUILDPYTHON),
   the -L flags in $(LDFLAGS) were first added before the -L. flag, 
   and are now after that flag. This ensures that the correct python 
   library will be found, even if there is a libpython in one of the
   directories on the search path that's added by $(LDFLAGS).

This should work fine on OSX (obviously) and Linux, but I'm not 100% that
moving $(LDFLAGS) will work with the vendor compilers on commercial unix
systems.

(Adding 3.3 and 3.4 to the versions because those should also be affected by 
this issue)

--
keywords:  -patch
versions: +Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30820/issue-11445-linkflags.txt

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11445
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library

2013-07-06 Thread Ed Campbell

Changes by Ed Campbell drescampb...@gmail.com:


--
nosy: +esc24

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11445
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library

2012-07-13 Thread Eduardo Cereto Carvalho

Changes by Eduardo Cereto Carvalho eduardocer...@gmail.com:


--
nosy: +Eduardo.Cereto.Carvalho

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11445
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library

2012-06-11 Thread Samuel John

Changes by Samuel John pyt...@samueljohn.de:


--
nosy: +samueljohn

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11445
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library

2011-10-17 Thread Éric Araujo

Éric Araujo mer...@netwok.org added the comment:

 I'm not committing this yet though as this will affect all platforms
 that use Makefiles to build, and I'm not sure if this change save for
 all compilers we effectively support.
I can test with GCC on Debian (linux kernel); I don’t know if it would be easy 
to ask all buildbots to test your branch, if not you could call for volunteers 
on python-dev.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11445
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library

2011-03-19 Thread Skip Montanaro

Changes by Skip Montanaro s...@pobox.com:


--
nosy:  -skip.montanaro

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11445
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library

2011-03-16 Thread Ronald Oussoren

Ronald Oussoren ronaldousso...@mac.com added the comment:

The attached patch fixes the issue by moveing LDFLAGS after BLDLIBRARY in the 
linking step.

I'm not committing this yet though as this will affect all platforms that use 
Makefiles to build, and I'm not sure if this change save for all compilers we 
effectively support.

Fixing this completely for OSX will require another change as well: we'd have 
to add -Wl,-search_paths_first to ensure that the build will pick up the 
first libpython on the search path, otherwise we'd still have a problem if you 
try to build a staticly linked binary (as this would still cause the linker to 
find macports if the additional flag isn't used).

--
keywords: +needs review, patch
stage: needs patch - patch review
Added file: http://bugs.python.org/file21243/issue-11445.txt

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11445
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library

2011-03-09 Thread Ronald Oussoren

Ronald Oussoren ronaldousso...@mac.com added the comment:

It is --enable-shared that is the culprit, but in the negated form...

The OSX linker will search the entire link path for a shared library before 
trying to look for a static library. As a workaround you could use 
'--enable-shared', and that should ensure that you get linked to the python 
version you're actually building as it is earlier on the path.

A proper fix is to add -Wl,-search_paths_first to the linker flags on OSX, 
with that flag the linker behaves just like the linker on any other unix 
platform.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11445
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library

2011-03-09 Thread Ned Deily

Ned Deily n...@acm.org added the comment:

I see the problem now. Using a --enable-shared configure similar to Skip's, the 
gcc step that builds python.exe is:

  gcc -L/opt/local/lib -u _PyMac_Error -o python.exe \
  Modules/python.o \
  -L. -lpython2.7 -ldl  -framework CoreFoundation

What I failed to notice originally is that the MacPorts python27 port, which 
both Skip and I have installed, adds a link in /opt/local/lib to its framework 
lib:

/opt/local/lib/libpython2.7.dylib@ - 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python

So since /opt/local/lib comes first on the lib list, that libpython2.7 is going 
to be found before the build directory's dylib.  Moving -L /opt/local/lib to 
after -L. does seem to fix the problem.

In the non-shared case, the gcc link step is:

  gcc -L/opt/local/lib -u _PyMac_Error -o python.exe \
  Modules/python.o libpython2.7.a \
  -ldl  -framework CoreFoundation

so the local static lib is explicitly loaded and there shouldn't be a problem.

The shared-lib case is nasty in that you can easily link to the wrong lib 
without realizing it.  The Makefile (for 2.7 - py3k is similar) is:

# Build the interpreter
$(BUILDPYTHON): Modules/python.o $(LIBRARY) $(LDLIBRARY)
$(LINKCC) $(LDFLAGS) $(LINKFORSHARED) -o $@ \
Modules/python.o \
$(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)

I wonder whether $(LDFLAGS) can be safely moved to after $(BLDLIBRARY) without 
breaking some platform. And I suspect the problem is not unique to OS X but 
perhaps more likely there.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11445
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library

2011-03-08 Thread Ned Deily

Changes by Ned Deily n...@acm.org:


--
components: +Macintosh
nosy: +ronaldoussoren
stage:  - needs patch
title: Something changed w.r.t. prefix/pythonN.M/site-packages in the Hg 
switch - python.exe on OS X shared-llbrary build erroneously linked to 
MacPorts python library

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11445
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com