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;
-- Terry


On Jan 10, 2006, at 3:44 PM, Joe Koski wrote:
> Terry,
>
> 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,  
> though.
> I guess I should try that too.
>
> If I try "-bundle_loader executable" for this large make file, where  
> the
> 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  
> other
> than ld?
>
> Also, why don't gfortran and g77 require this special care? The  
> compiler
> developer wants to know, also.
>
> Joe
>
>
> 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  
>> to
>> your dynamically loaded shared objects.
>>
>> Dave also pointed out that -flat_namespace could potentially also  
>> work.
>>
>> -- Terry

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list      (Unix-porting@list...)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/unix-porting/subscriber%40opensubscriber.com

This email sent to subscriber@open...