Whenever people talk about linking issues on MacOS X, they suggest
that in order to link, you need to use the compiler instead of using
the linker directly. I personally don't like this either, but I can
understand the argument, from the point of view of not including the C+
+ thread exception code in C programs, etc.: you get faster smaller
code than if you threw in the kitchen sink (this is more or less an
egcs design decision we gcc users have to live with now). So there
are good reasons for this, even if some of them are historical warts.
So I expect that you should link using the compiler you used to
compile the code, and if *any* of that code is C++ code, that you
should link using g++, rather than some other compiler.
So now the issue is visibility of symbols defined in the main
executable to shared objects in Octave.
The answer to this one is that the documentation is surprising. It's
probably better written as "-bundle_loader <executable>"; The
<executable> in this case needs to be the executable from which you
intend to get the symbols. So this needs to be the binary with the
crt1.o and main program linked into it - in other words, octave itself.
This is because it needs to get these symbol names from the binary
where it's going to access them, so that it will know their relocated
location in the binary.
It's probably arguably a bad thing that this type of thing is
required; however, the reasoning is that that the preferred method of
loading shared objects is to actually use "dyld" family routines,
rather than "dlopen" and family routines. That way, if you had a
bunch of libaries that were incompatible with some other application
vendor, you wouldn't end up stepping on each others toes; instead,
you'd each have your own private copies.
That doesn't really explain the unavailability of what "dlopen"
specifies using a hierarchical relationship between namespaces
("RTLD_GLOBAL"), which is supposed to let you get at the global
symbols anyway when loading the shared object and trying to resolve a
symbol via dlsym().
One potential workaround for this would be to:
handle = dlopen(0, RTLD_LAZY);
and then use
sym = dlsym(handle, "environ");
To reference the environment, instead of trying to reference it
directly. I'm not actually specifically positive this approach would
be a viable alternative, but its at least one possibility.
Hope that helps;
On Jan 10, 2006, at 3:44 PM, Joe Koski wrote:
> Thanks, but as I stated in my update, I tried both the -
> bundle_loader and
> -flat_namespace option without success. I didn't try both together,
> I guess I should try that too.
> If I try "-bundle_loader executable" for this large make file, where
> first task is building a .dylib based on Fortran, what executable am I
> referring to: ld? gcc? g95? octave? the library name? etc. I tried
> most of
> these without success. My gcc manual just says to refer to the
> massive ld(1)
> man page without specifics. Would I do better linking with something
> than ld?
> Also, why don't gfortran and g77 require this special care? The
> developer wants to know, also.
> on 1/10/06 4:27 PM, Terry Lambert at tlambert@appl... wrote:
>> That was actually me who sait it was in crt1.o, and both Dave Z.
>> and I
>> pointed out that you will need to use the option -bundle_loader when
>> you link your shared object to make the main binary symbols visible
>> your dynamically loaded shared objects.
>> Dave also pointed out that -flat_namespace could potentially also
>> -- Terry