octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DEFUN_DLD link rule


From: Mike Miller
Subject: Re: DEFUN_DLD link rule
Date: Fri, 30 Aug 2013 11:08:03 -0400

On Thu, Aug 29, 2013 at 23:33:19 -0400, Michael Goffioul wrote:
> On Thu, Aug 29, 2013 at 11:10 PM, Mike Miller <address@hidden> wrote:
>>
>> On Thu, Aug 29, 2013 at 19:41:03 -0400, Michael Goffioul wrote:
>> > On Thu, Aug 29, 2013 at 7:33 PM, Mike Miller <address@hidden> wrote:
>> >>
>> >> Can someone comment on the necessity of explicitly linking in the
>> >> Octave libraries liboctinterp and liboctave when building oct-files?
>> >> Particularly with regard to non-GNU operating systems.
>> >>
>> >> Oct-files are shared objects that are dlopen'd by Octave at runtime on
>> >> demand, while the Octave libraries have already been loaded by the
>> >> executable. In my experience, on GNU/Linux at least, it's not
>> >> necessary (and sometimes even discouraged) to link in libraries that
>> >> the application is expected to have already loaded.
>> >>
>> >> What about other operating systems? If we were to remove
>> >> liboctinterp.la and liboctave.la from LIBADD, would this still work on
>> >> all other systems that we currently work on? And the same for the
>> >> mkoctfile command?
>> >
>> >
>> > That's not gonna work for Windows system, where you cannot have
>> > undefined
>> > references at link time (and and oct-file is very likely gonna use
>> > symbols
>> > from liboctinterp and liboctave).
>> >
>> > In my experience with MSVC, I even need to add libgnu.la to various link
>> > commands to make it work. Because MSVC does not auto-export all symbols,
>> > so
>> > the gnulib symbols that are linked into liboctave are private to
>> > liboctave
>> > and not re-exported for the other libraries. And I'm not sure it's even
>> > desirable to export the gnulib symbols, as they could clash with runtime
>> > library symbols and lead to multiple symbols errors.
>>
>> Ok, thanks, exactly what I was asking for. We could potentially make
>> this conditional on the system. Is this related at all to the
>> --enable-link-all-dependencies configure option, is that also required
>> on Windows to link the way you are describing?
>
>
> It's related, but not exactly the same. Under Windows, you only need to link
> against libraries you directly use in your code. You don't need to link
> against the dependencies of those libraries if you don't use symbols from
> those deps directly. I understand that --enable-link-all-dependencies
> includes all dependencies, but this is theoretically not needed under
> Windows.
>
> IIRC, I really only had problems with libgnu.la. I'm not sure
> --enable-link-all-dependencies would add it to the libs when linking
> liboctinterp, or the oct-files. Because MSVC does not support auto-exporting
> symbols, I had to add libgnu.la manually in libinterp/Makefile.am,
> src/Makefile.am and libinterp/dldfcn/config-module.awk.

Thanks for all of the info. I'll probably leave this alone for now but
we may want to come back to it later, maybe make the linking of
libgnu, liboctave, and liboctinterp in oct-files system-dependent.
It's not that urgent of a problem for me at the moment.

-- 
mike


reply via email to

[Prev in Thread] Current Thread [Next in Thread]