Apple has deliberately depreciated static linking of user executables on Mac
OS X. Any time you try to link statically with Apple's ld, if a dynamic
library of the same name is available, it grabs that instead. Not sure if
the Autoconf build is affected by this, but the CMake build is. We work
On 5/17/07, Shawn W. <[EMAIL PROTECTED]> wrote:
On May 15, 2007, at 7:35 AM, Brandon Van Every wrote:
>
> At a first go, read INSTALL-CMake.txt and try to build Chicken on
> your Mac OS X. Then see the bugtracker ticket I've just added
> about universal binaries. http://trac.callcc.org/ticke
On May 12, 2007, at 11:36 PM, Brandon Van Every wrote:
Do Mac OS X users think this is worth doing?
I personally do not think it worth doing. Ideally any application
that used chicken would distribute the necessary .dylib files with
the app, either as a framework for user level or system
Brandon Van Every wrote:
> Apple has deliberately depreciated static linking of user executables on
> Mac OS X. Any time you try to link statically with Apple's ld, if a
> dynamic library of the same name is available, it grabs that instead.
> Not sure if the Autoconf build is affected by this,
On 5/13/07, Thomas Christian Chust <[EMAIL PROTECTED]> wrote:
I would only change the behaviour of the build if it doesn't mean a lot
of work. If the library names were changed, though, I would try to keep
them identical across all platforms to reduce confusion of the users ;-)
Windows lib
On 5/13/07, Brandon Van Every <[EMAIL PROTECTED]> wrote:
Hey I just had a brilliant idea. We don't have to rename anything. We
could just symlink libchicken-s.a to libchicken.a. Then the user can have
his cake and eat it too.
On the other hand, we could eliminate all support for static
Brandon Van Every wrote:
> [...]
> On the other hand, we could eliminate all support for static linking,
> bowing to the One True Apple Way Of Doing Things [TM]. How do people
> feel about that?
> [...]
Hello,
I wouldn't mind if static linking was not supported. But in that case we
can just as
On 5/14/07, Thomas Christian Chust <[EMAIL PROTECTED]> wrote:
Brandon Van Every wrote:
> [...]
> On the other hand, we could eliminate all support for static linking,
> bowing to the One True Apple Way Of Doing Things [TM]. How do people
> feel about that?
I wouldn't mind if static linking wa
On Mon, May 14, 2007 at 11:55:31AM -0400, Brandon Van Every wrote:
> Any static linking horror stories out there?
Sure, I have some that aren't necessarily apple related, but could
happen on that platform. Although, it isn't so much of static linking as
static/dynamic linking. You need both sides
On 5/14/07, Peter Keller <[EMAIL PROTECTED]> wrote:
On Mon, May 14, 2007 at 11:55:31AM -0400, Brandon Van Every wrote:
> Any static linking horror stories out there?
Sure, I have some that aren't necessarily apple related, but could
happen on that platform.
Ok Mac OS X users, what say you?
On May 14, 2007, at 10:24 AM, Brandon Van Every wrote:
On 5/14/07, Peter Keller <[EMAIL PROTECTED]> wrote: On Mon, May
14, 2007 at 11:55:31AM -0400, Brandon Van Every wrote:
> Any static linking horror stories out there?
I CAN'T make statically linked C programs on OS X using the compiler
On May 14, 2007, at 10:56 AM, Shawn W. wrote:
On May 14, 2007, at 10:24 AM, Brandon Van Every wrote:
On 5/14/07, Peter Keller <[EMAIL PROTECTED]> wrote: On Mon, May
14, 2007 at 11:55:31AM -0400, Brandon Van Every wrote:
> Any static linking horror stories out there?
I CAN'T make statical
On 5/14/07, Shawn W. <[EMAIL PROTECTED]> wrote:
On May 14, 2007, at 10:24 AM, Brandon Van Every wrote:
>
> Ok Mac OS X users, what say you? Should we tie your hands for your
> own good, or give you the freedom to cut off your own fingers?
>
I don't care about static linking.
I've yet to h
On Mon, May 14, 2007 at 04:39:15PM -0400, Brandon Van Every wrote:
> But, I've never observed dynamic linking complications in
> all the time that CMake has been tested. Peter Keller's post also seems to
> indicate that static linking is the case more likely to cause problems.
In general, an easy
On 5/14/07, Peter Keller <[EMAIL PROTECTED]> wrote:
Dynamic libraries were created to solve upgradability and text size in the
VM problems. However, they do have some nasty edge cases. Truth be told,
you probably won't hit any of them unless you A) want multiple revisions
of a tool coeexisting
On 5/14/07, Peter Keller <[EMAIL PROTECTED]> wrote:
Example 1
-
1. You statically link the openssl libraries into your application because
you can't guarantee that the target platform will have one. So, you move
your executable to a machine, start it up, and here is what could happen
On 5/14/07, Peter Keller <[EMAIL PROTECTED]> wrote:
So, the summary of my argument is that out of all linking problems, both
static and dynamic, 80% of them would be related to static linking, 20%
of them would be related to dynamic linking. This is purely anecdotal
from my previous experiences
On Tue, May 15, 2007 at 01:51:20AM -0400, Brandon Van Every wrote:
> This resembles the case of PCRE. We have our own code for this library. To
> create a dynamic libchicken, first we create a static libpcre. The static
> libpcre is compiled with shared flags, so that the .obj files are correct
On Tue, May 15, 2007 at 08:36:20AM +0200, felix winkelmann wrote:
> Indeed. My experience has been quite the opoosite. There are situations
> where
> static linking may give problems, but there are vastly more with dynamic
> linking.
I suspect if in the future I run into those problems that you h
On 5/15/07, Peter Keller <[EMAIL PROTECTED]> wrote:
Doesn't chicken already have a tool someon can run when linking with
chicken applications? Like csc -libs? Why can't you just add -lpcre there
if applicable? Then it'll just grab whatever the user wanted.
Wouldn't that cause versioning probl
On Tue, May 15, 2007 at 08:43:07AM +0200, felix winkelmann wrote:
> On 5/15/07, Peter Keller <[EMAIL PROTECTED]> wrote:
> >Doesn't chicken already have a tool someon can run when linking with
> >chicken applications? Like csc -libs? Why can't you just add -lpcre there
> >if applicable? Then it'll j
On May 14, 2007, at 1:39 PM, Brandon Van Every wrote:
On 5/14/07, Shawn W. <[EMAIL PROTECTED]> wrote:
...
CMake doesn't have framework support. See
http://www.cmake.org/Wiki/CMake:MacOSX_Frameworks
The issue is known but isn't getting attention. Bill Hoffman is
interested in moving for
On 5/15/07, Shawn W. <[EMAIL PROTECTED]> wrote:
On May 14, 2007, at 1:39 PM, Brandon Van Every wrote:
> On 5/14/07, Shawn W. <[EMAIL PROTECTED]> wrote:
>
...
>
> CMake doesn't have framework support. See
> http://www.cmake.org/Wiki/CMake:MacOSX_Frameworks
> The issue is known but isn't getti
On 5/15/07, Peter Keller <[EMAIL PROTECTED]> wrote:
Given what I've seen above, I think the fake is unstable.
Doesn't chicken already have a tool someon can run when linking with
chicken applications? Like csc -libs? Why can't you just add -lpcre there
if applicable? Then it'll just grab what
On May 15, 2007, at 3:06 AM, Peter Keller wrote:
Unfortunately, the real world for UNIX basically works on linux and
solaris. Solaris gets this right far more than you could imagine,
linux
couldn't care less if they got it right.
Since the title of this thread is "Mac OS X static library
On Tue, May 15, 2007 at 03:10:13PM -0400, Raffael Cavallaro wrote:
> Since the title of this thread is "Mac OS X static library names"
> it's worth noting that Mac OS X is UNIX, and Mac OS X really does
> care about getting this right, and, in my experience, does. This is
> one of the reasons
On 5/15/07, Peter Keller <[EMAIL PROTECTED]> wrote:
I don't think there is ANYTHING that anyone can do which is the right
answer since you basically have to bail at *runtime* if the linker loader
notices two APIs of the same kind clashing in the program.
I thought C# had a strong notion of
On Tue, May 15, 2007 at 03:30:35PM -0400, Brandon Van Every wrote:
> I thought C# had a strong notion of versioning. I haven't really gone up
> the C# learning curve enough to recall whether an Assembly is a C# or a .NET
> concept though. Nor whether it provides an ultimate solution.
>
> Don't k
On May 15, 2007, at 12:30 PM, Brandon Van Every wrote:
On 5/15/07, Peter Keller <[EMAIL PROTECTED]> wrote:
I don't think there is ANYTHING that anyone can do which is the right
answer since you basically have to bail at *runtime* if the linker
loader
notices two APIs of the same kind cla
Brandon Van Every scripsit:
> We've had a feature complete, field tested, all but bug free CMake
> build for awhile now. It took 1 man year to produce. It is the only
> way to produce the MSVC versions of Chicken, and it is preferred for
> MinGW also.
And for Cygwin, thanks to the libffi suppor
On 5/15/07, John Cowan <[EMAIL PROTECTED]> wrote:
Brandon Van Every scripsit:
> We've had a feature complete, field tested, all but bug free CMake
> build for awhile now. It took 1 man year to produce. It is the only
> way to produce the MSVC versions of Chicken, and it is preferred for
> Min
Brandon Van Every scripsit:
> Having the 2nd invocation of "make install" repeat the build from
> scratch is not that important a bug, and all evidence says it's a
> Linux specific bug.
I'd like to see if it happens on a Solaris or BSD system. I've been
wondering if it might not be a general bug
On 5/16/07, John Cowan <[EMAIL PROTECTED]> wrote:
Brandon Van Every scripsit:
> Having the 2nd invocation of "make install" repeat the build from
> scratch is not that important a bug, and all evidence says it's a
> Linux specific bug.
I'd like to see if it happens on a Solaris or BSD system.
On 5/16/07, John Cowan <[EMAIL PROTECTED]> wrote:
Brandon Van Every scripsit:
> Having the 2nd invocation of "make install" repeat the build from
> scratch is not that important a bug, and all evidence says it's a
> Linux specific bug.
I'd like to see if it happens on a Solaris or BSD system.
On 5/17/07, Graham Fawcett <[EMAIL PROTECTED]> wrote:
On 5/16/07, John Cowan <[EMAIL PROTECTED]> wrote:
> Brandon Van Every scripsit:
>
> > Having the 2nd invocation of "make install" repeat the build from
> > scratch is not that important a bug, and all evidence says it's a
> > Linux specific b
On May 15, 2007, at 7:35 AM, Brandon Van Every wrote:
On 5/15/07, Shawn W. <[EMAIL PROTECTED]> wrote:
> Universal binary support to go along with that would be nice
> too. The latter is easy to do. (Add '-arch i386 -arch ppc' to the
> cflags used by the chicken compiler, and I /think/ everything
On 5/17/07, Brandon Van Every <[EMAIL PROTECTED]> wrote:
On 5/17/07, Shawn W. <[EMAIL PROTECTED] > wrote:
>
>
> On May 15, 2007, at 7:35 AM, Brandon Van Every wrote:
> >
> > At a first go, read INSTALL-CMake.txt and try to build Chicken on
> > your Mac OS X. Then see the bugtracker ticket I've
On May 17, 2007, at 2:02 PM, Brandon Van Every wrote:
I wouldn't expect the Automake build to perform any better either,
as once upon a time I lifted the CStackGrowsDownward.c code from
Automake's output. It probably uses the same try-run mechanism to
determine the results. And if
On 5/17/07, Kon Lovett <[EMAIL PROTECTED]> wrote:
Compiling a universal binary is an exercise in x-compiling. Chicken
cannot discover anything about the foreign platform, it must "know."
All cpu specific configuration must be done via command-line options
or a separate set of configuration head
39 matches
Mail list logo
