Bill,
If Cmake orders items based on this expected behavior, then the compiler
should also match the same convention, and the -search_paths_first flag
should definitely be used.
Thanks,
Hans
On 6/26/06 10:04 AM, "William A. Hoffman" <[EMAIL PROTECTED]> wrote:
> At 10:57 AM 6/26/2006, Hans Joh
At 10:57 AM 6/26/2006, Hans Johnson wrote:
>Bill,
>
>I'm always leery about changing the default behavior for things like this.
>This change did fix my problem, which admittedly is a due to retrofitting
>the build system deal with my strange requirements, but it seems like many
>other people are no
William A. Hoffman wrote:
At 11:09 PM 6/24/2006, Hans Johnson wrote:
Thanks for all your suggestions. They put me onto the correct path to
figuring out what was going on. Close inspection of the man page for ld on
MacOSX indicates why the strange behavior was occuring.
-search_paths_first
Bill,
I'm always leery about changing the default behavior for things like this.
This change did fix my problem, which admittedly is a due to retrofitting
the build system deal with my strange requirements, but it seems like many
other people are not being affected.
I think that it would be bette
This sounds very familiar. I think we figured it out once before, and talked
about making this flag the default on OSX. Does that sound like a good idea?
-Bill
At 11:09 PM 6/24/2006, Hans Johnson wrote:
>Brad,
>
>Thanks for all your suggestions. They put me onto the correct path to
>figuring o
Brad,
Thanks for all your suggestions. They put me onto the correct path to
figuring out what was going on. Close inspection of the man page for ld on
MacOSX indicates why the strange behavior was occuring.
-search_paths_first
By default when the -dynamic flag is in effect, the
Bill,
There are simlinks to the libraries in /usr/lib that link to the libraries,
but /usr/lib is not on my link line, and is supposed to be looked at after
all the -L directories are searched.
Hans
On 6/23/06 12:45 PM, "William A. Hoffman" <[EMAIL PROTECTED]> wrote:
> I think there are symli
Hans J. Johnson wrote:
Here is the output. I am still perplexed as to why the tcl and tk libraries
from the framework (or /usr/lib) are being included.
[snip]
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/collect2 -dynamic -arch ppc
-bind_at_load -headerpad_max_install_names -macosx_version_mi
I think there are symlinks to the tcl/tk stuff in /usr/lib or some other
system area, they link to the framework version.
-Bill
At 01:38 PM 6/23/2006, Hans J. Johnson wrote:
>Brad,
>
>Here is the output. I am still perplexed as to why the tcl and tk libraries
>from the framework (or /usr/lib)
Brad,
Here is the output. I am still perplexed as to why the tcl and tk libraries
from the framework (or /usr/lib) are being included.
/usr/bin/c++-bind_at_load -O2 -ftemplate-depth-50 -no-cpp-precomp
-Wno-long-double -ftemplate-depth-50 -no-cpp-precomp -Wno-long-double
-DNO_ITK_TCL -O3 -
Hans J. Johnson wrote:
Cmake Experts,
I am running into a problem with static libraries and conflicting frameworks
on MacOSX. I need to statically build my own version of tcl and tk with X11
bindings and link it to my application. The problem is that the linker is
preferring to bind to the Tcl
Cmake Experts,
I am running into a problem with static libraries and conflicting frameworks
on MacOSX. I need to statically build my own version of tcl and tk with X11
bindings and link it to my application. The problem is that the linker is
preferring to bind to the Tcl.framework and Tk.Framewo
12 matches
Mail list logo
