On Fri, 2016-03-11 at 09:39 +0000, Long, Qin wrote: > > > It looks like the libraries are built into an archive and then > linked > > statically. So only those objects which are *referenced* are > actually > > pulled into the build. Which means that if we just *add* the ssl/ > > directory to the OpensslLib build, it will only be pulled in if > > something *uses* it. Doesn't it? > > > > Yes, it's feasible to archive two libraries into one, and only > referenced symbols will be included. > The current design (separated libraries) is try to keep the original > openssl layout (libcrypto and libssl). Different library serve as > different scopes. Of cause, the name of OpensslLib.inf looks > confusing, which should be one crypto library only. > > I agree the proposal looks also valuable. We should ever discuss this > internally. Let me try and get some size data for evaluations (I > think the total symbols / functions in image still highly depend on > the capabilities of the compiler / linker).
Yeah. With GCC we seem to have function granularity — if a function isn't actually called, it gets completely dropped out of the image. With MSVC it seems to be object file granularity. So if *one* function in a given .obj file is called, that whole .obj file is included. That's why we had additional problems with the MSVC build and needed extra cleanups in the OpenSSL code (and I could reproduce them on Linux by adding -fno-function-sections to the CFLAGS). But I think that in both cases, we should have confidence that if you don't *use* anything from the objects in the ssl/ directory, you won't get anything else pulled in. I'll try just fixing the process_files.sh script to include the ssl/*.c files in the build. If I'm right, the resulting image will be identical. I'm slightly concerned by all the other duplication in the OpensslTlsLib.inf file — the CFLAGS and other things. Merging them into one, if it's technically feasible, does seem cleaner. -- David Woodhouse Open Source Technology Centre [email protected] Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
