Le 31 août 07 à 10:36, Vincent Lefevre a écrit :
On 2007-08-29 20:28:30 -0500, Ryan Schmidt wrote:
But we always want users to compile MacPorts base using the gcc
provided with Apple Xcode. We don't want people attempting to use
any other version of gcc.
Does MacPorts ensures that Xcode gcc
On Aug 31, 2007, at 03:36, Vincent Lefevre wrote:
On 2007-08-29 20:28:30 -0500, Ryan Schmidt wrote:
But we always want users to compile MacPorts base using the gcc
provided with Apple Xcode. We don't want people attempting to use
any other version of gcc.
Does MacPorts ensures that Xcode
On 2007-08-31 18:05:21 -0500, Ryan Schmidt wrote:
On Aug 31, 2007, at 03:36, Vincent Lefevre wrote:
Then that's a user-side problem. The best fix is to remove/replace this
incredibly old version of readline.
Of course. But if MacPorts *seems* to build correctly against this old
readline,
On 2007-08-28 22:58:16 +0200, N_Ox wrote:
Le 22 août 07 à 17:25, Vincent Lefevre a écrit :
On 2007-08-21 22:15:08 -0400, Jay Sachs wrote:
What about:
gcc -nostdinc \
-isystem /usr/lib/gcc/i686-apple-darwin8/4.0.1/include \
-isystem /usr/include \
-isystem
On Aug 29, 2007, at 14:29, Vincent Lefevre wrote:
On 2007-08-28 22:58:16 +0200, N_Ox wrote:
Le 22 août 07 à 17:25, Vincent Lefevre a écrit :
On 2007-08-21 22:15:08 -0400, Jay Sachs wrote:
What about:
gcc -nostdinc \
-isystem /usr/lib/gcc/i686-apple-darwin8/4.0.1/include \
Le 22 août 07 à 17:25, Vincent Lefevre a écrit :
On 2007-08-21 22:15:08 -0400, Jay Sachs wrote:
What about:
gcc -nostdinc \
-isystem /usr/lib/gcc/i686-apple-darwin8/4.0.1/include \
-isystem /usr/include \
-isystem /System/Library/Frameworks \
-isystem /Library/Frameworks
?
On Aug 21, 2007, at 21:15, Jay Sachs wrote:
On Aug 21, 2007, at 8:00 PM, Bryan Blackburn wrote:
On Aug 21, 2007, at 3:33 PM, Ryan Schmidt wrote:
Devs: I think this problem occurs because MacPorts needs a newer
version of readline than the one you have in /usr/local. Couldn't
we add a
libreadline.a is the statically-linked library. Are you sure there
aren't also any dynamically-linked libraries of readline in /usr/
local/lib? Their names would be libreadline.*.dylib.
Hurray, now it's all ok! It was the dynamic library!!
Thank you all! :)
On Aug 21, 2007, at 8:00 PM, Bryan Blackburn wrote:
On Aug 21, 2007, at 3:33 PM, Ryan Schmidt wrote:
...
Devs: I think this problem occurs because MacPorts needs a newer
version of readline than the one you have in /usr/local. Couldn't
we add a check to ./configure to make sure the
On 2007-08-21 16:33:11 -0500, Ryan Schmidt wrote:
[...]
ld: Undefined symbols:
_rl_completion_matches
_rl_filename_completion_function
_rl_username_completion_function
/usr/bin/libtool: internal link edit command failed
make[2]: *** [Pextlib.dylib] Error 1
make[1]: *** [all] Error 1
make:
On Aug 22, 2007, at 10:24 AM, Jason Stelzer wrote:
I alluded to this before, but does anyone know the moral equivalent
to a -rpath linker directive on os x?
there isn't, -rpath is an ELFism.
On Mac OS X, install_name of the library you link to is added to the
application (it's what you see
On Aug 22, 2007, at 11:04 AM, Vincent Lefevre wrote:
libreadline.a is the statically-linked library. Are you sure there
aren't
also any dynamically-linked libraries of readline in /usr/local/
lib? Their
names would be libreadline.*.dylib.
I recall that the same problem could also happen due
On 2007-08-21 22:15:08 -0400, Jay Sachs wrote:
What about:
gcc -nostdinc \
-isystem /usr/lib/gcc/i686-apple-darwin8/4.0.1/include \
-isystem /usr/include \
-isystem /System/Library/Frameworks \
-isystem /Library/Frameworks
? It'd be nice not to hardcode this -- it could be
On 2007-08-22 08:42:20 -0400, Jason Stelzer wrote:
Its not that /usr/local is special, its that it is part of the
standard runtime/compile time search path by default. You should be
able to override its search vial -L at compile time and
DYLD_LIBRARY_PATH at runtime.
Yes, for libraries *only*
On Aug 20, 2007, at 04:10, Tommaso Urli wrote:
ld: warning prebinding disabled because of undefined symbols
ld: Undefined symbols:
_rl_completion_matches
_rl_filename_completion_function
_rl_username_completion_function
/usr/bin/libtool: internal link edit command failed
make[2]: ***
Ok, I renamed libreadline.a and tried port install readline. Now
let's see if it works.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
As I said I reinstalled redaline through MacPorts, but still:
frodo:/usr/local/lib root# port selfupdate
MacPorts base version 1.5 installed
Downloaded MacPorts base version 1.520
Configuring, Building and Installing new MacPorts base
Error: /opt/local/bin/port: selfupdate failed: Error
On Aug 21, 2007, at 8:00 PM, Bryan Blackburn wrote:
On Aug 21, 2007, at 3:33 PM, Ryan Schmidt wrote:
...
Devs: I think this problem occurs because MacPorts needs a newer
version of readline than the one you have in /usr/local. Couldn't
we add a check to ./configure to make sure the
So get those reports in to sanitize our ports tree as much as
possible. In the mean time, enjoy MacPorts 1.5.2!
frodo:/Volumes/Users/tunnuz root# port selfupdate
MacPorts base version 1.5 installed
Downloaded MacPorts base version 1.520
Configuring, Building and Installing new MacPorts
Good evening everyone!
MacPorts 1.5.2 is now available through selfupdate to temporarily
downgrade from fatal errors to warnings all the mtree violations some
ports are showing. Users should upgrade to this new release but still
report in trac tickets when ports violate the
20 matches
Mail list logo
