Re: Dynamic loading progress

[Stephen Leake]

Eli Zaretskii <address@hidden> writes:

>> > I also don't like the -I$(ROOT)/nt/inc thing, it should only be needed
>> > for Emacs-specific system-level stuff.  Why was it needed here?
>> 
>> some file included ms-w32.h:
>> 
>> address@hidden make
>> gcc -std=c99 -ggdb3 -Wall -I../../src -I../../lib `pkg-config libcurl 
>> --cflags` -fPIC -c curl.c
>> curl.c:1:0: warning: -fPIC ignored for target (all code is position 
>> independent)
>>  #include <stdio.h>
>>  ^
>> In file included from ../../src/config.h:1866:0,
>>                  from curl.c:6:
>> ../../src/conf_post.h:32:27: fatal error: ms-w32.h: No such file or directory
>
> This is wrong on several levels.  First, the module shouldn't use
> "-fPIC" unconditionally, as on some platforms, such as Windows, it
> invokes a warning and is otherwise ignored.

Right. More reason to use configure.

> So the question now becomes: what happens if you _remove_ the
> "-I../../lib" option from the GCC command line?

gcc -std=gnu99 -ggdb3 -Wall -I../../src `pkg-config libcurl --cflags` -c curl.c
In file included from curl.c:8:0:
../../src/lisp.h:32:22: fatal error: intprops.h: No such file or directory
 #include <intprops.h>
                      ^
compilation terminated.


intprops.h is in lib; that explains why -I../../lib is needed.

> If that doesn't work, then we really need an emacs.h file ASAP, and
> the module should include only that file, without including <config.h>
> inside that file.

Nor <lisp.h>. And probably not lots of other things.

>> >    -Wl,--out-implib=libemacs.dll.a
>> 
>> And that goes in src/Makefile somewhere? Not on the "emacs$(EXEEXT)"
>> line, since that doesn't run gcc. So it must go on the temacs$(EXEEXT)
>> line (line 693)?
>
> Yes, it should be part of the temacs link command.
>
>> And until we write emacs.h, it also needs -Xlinker -E (or can that
>> be -Wl,-E ?).
>
> I don't see what does a header file have to do with linking.  

-Wl,-E is short for -Wl,--export-all-symbols; that makes all symbols
declared in Emacs visible to the module. (Similarly, --export-dynamic
makes all symbols visible on Debian).

I'm assuming emacs.h will include some annotation to make the symbols
declared in that file visible, so we won't need --export-all-symbols
(but more below).

>> That should be added by configure when Windows and --with-ltdl are
>> specified. 
>
> I'd imagine --with-modules, not --with-ltdl, but I didn't take a look
> at the branch yet.

It's currently --with-ltdl, but I agree --with-modules is a better
option name.


>> Hmm. We already have:
>> 
>> LIBLTDL = -lltdl -Wl,--export-dynamic
>> 
>> which is included in LIBES, and thus in the temacs.exe link. However,
>> that produces a warning:
>> 
>> C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> warning: --export-dynamic is not supported for PE+ targets, did you mean
>> --export-all-symbols?
>> 
>> So apparently that should be changed to --export-all-symbols? Doing that
>> produces libemacs.dll.a
>
> No, using --export-all-symbols is wrong.  See my other message in this
> thread.  We don't want to export all the Emacs symbols to the outside
> world.  Please use -Wl,--out-implib= instead.

How does that know which symbols to export? The help for Gnu ld
--out-implib doesn't say.

Testing; apparently it exports all symbols - emacs.dll.a did not change
size. So --export-all-symbols is redundant, but I don't see how we are
going to restrict what symbols are available to the module.

Unless we are proposing to do that solely via .h files, not at the
linker level. I think that's better - compile time errors are easier to
understand than link time errors. We'll have to see how well that
works. 


>> So one question is how to make this Makefile do the right thing
>> for the current operating system. The intent is for this Makefile to be
>> part of the Emacs test suite, so it needs to not require user intervention.
>
> Indeed, this is part of the job of figuring out how to use modules in
> Emacs.  Apparently, that part was not yet done.
>
>> One option is to rename modules/curl/Makefile to
>> modules/curl/Makefile.in and use configure in the modules directories.
>
> Which configure? the Emacs configure?  That'd be a wrong solution,
> IMO, as it will require the Emacs maintainers to know about modules in
> order to DTRT for them in our mainline configure script.

Not modules in general, just the few that are in the Emacs test suite.

> So if Autoconf should be used to generate Makefile's in the modules,
> it should be their own configure scripts.

That is true for normal modules, yes.

>> Another is to set flags in modules/tests.py.
>
> That requires Python, which is an additional requirement for the build
> environment.  I'd rather we used Emacs for that.

Ok.

> Alternatively, if the number of different settings is small, we could
> assume GNU Make and use its conditional directives to cater to the few
> different platforms.  That's much easier, but doesn't scale well to
> large and complex modules.  But perhaps that's not a big deal, if we
> assume modules will not be large and complex.

Is there an acceptable (ie portable and reliable) way to determine the
OS in a Makefile? I'm not aware of one (short of Gnu config.guess).

-- 
-- Stephe