Purpose of lib*.def files?

24 views
Skip to first unread message

Steve Byan's Lists

unread,
May 19, 2017, 6:48:22 PM5/19/17
to pmem
I must be missing something. I can't find any use of the lib*.def files in the makefiles. Are these .def files used for anything? If so, what makefile rule uses them?

Best regards,
-Steve

--
Steve Byan
stev...@me.com
Littleton, MA



Andy Rudoff

unread,
May 21, 2017, 1:50:36 PM5/21/17
to pmem
Hi Steve,

The .def files are part of the Windows build process, so they're mentioned in the .vcxproj files instead of the makefiles.  On Linux, the analogous function is provided by the .map files, which are referenced by the makefiles (via a rule in the top-level Makefile.inc).

-andy 

Steve Byan's Lists

unread,
May 22, 2017, 2:03:36 PM5/22/17
to Andy Rudoff, pmem
Thanks Andy.

I'm having to remove symbols from the .map files that are obsolete and no longer defined, because unlike gnu ld, the Darwin ld complains if you try to supply a non-existent symbol to the -exported_symbols_list option. Apparently the non-existent symbols don't present a problem for Visual Studio, so I'll leave those alone.

> On May 21, 2017, at 1:50 PM, Andy Rudoff <an...@rudoff.com> wrote:
>
> Hi Steve,
>
> The .def files are part of the Windows build process, so they're mentioned in the .vcxproj files instead of the makefiles. On Linux, the analogous function is provided by the .map files, which are referenced by the makefiles (via a rule in the top-level Makefile.inc).
>
> -andy
>
> On Friday, May 19, 2017 at 4:48:22 PM UTC-6, Steve Byan wrote:
> I must be missing something. I can't find any use of the lib*.def files in the makefiles. Are these .def files used for anything? If so, what makefile rule uses them?

Krzysztof Czurylo

unread,
May 22, 2017, 3:48:13 PM5/22/17
to pmem, an...@rudoff.com
Steve,

Which symbols do you mean?

K.

Steve Byan's Lists

unread,
May 31, 2017, 2:06:58 PM5/31/17
to Krzysztof Czurylo, pmem, an...@rudoff.com

> On May 22, 2017, at 3:48 PM, Krzysztof Czurylo <krzyszto...@intel.com> wrote:
>
> Steve,
>
> Which symbols do you mean?

All of these are on Darwin.

First, jemalloc doesn't export memalign or aligned_alloc when built on Darwin, so I have to conditionally remove them from the .map file when compiling on Darwin.

In libvmmalloc.map, these symbols don't appear in the library:
__malloc_hook;
__realloc_hook;
__memalign_hook;
__free_hook;
Aside from __memalign_hook, this may be due to the functions being #ifdef'd and so not configured in the standard build.

In libpmemobj.map, libpmemobj is apparently missing these symbols:
pmemobj_direct;
pmemobj_oid;
pmemobj_tx_xadd_range_direct;
pmemobj_tx_xadd_range;
pmemobj_tx_xalloc;

I haven't had the time to go and check these libraries in the linux build to see if the symbols exist there. On Darwin, `nm` doesn't show them in the library, and trying to use the Darwin linker's `-exported_symbols_list` option to scope them as global (and everything omitted as local) causes the linker to barf.

It's possible that the libpmemobj symbols are missing due to my botching the merge from 1.0 to 1.2.2, or from my botching the original 1.0 port. I didn't enable scoping on Darwin until this latest round of work on the makefiles.

Best regards,
-Steve

Krzysztof Czurylo

unread,
Jun 1, 2017, 6:07:14 AM6/1/17
to pmem, krzyszto...@intel.com, an...@rudoff.com


On Wednesday, May 31, 2017 at 8:06:58 PM UTC+2, Steve Byan wrote:

> On May 22, 2017, at 3:48 PM, Krzysztof Czurylo <krzyszto...@intel.com> wrote:
>
> Steve,
>
> Which symbols do you mean?

All of these are on Darwin.

First, jemalloc doesn't export memalign or aligned_alloc when built on Darwin, so I have to conditionally remove them from the .map file when compiling on Darwin.

In libvmmalloc.map, these symbols don't appear in the library:
                __malloc_hook;
                __realloc_hook;
                __memalign_hook;
                __free_hook;
Aside from __memalign_hook, this may be due to the functions being #ifdef'd and so not configured in the standard build.

Thanks Steve, I see where is the problem.
I think conditional removing those symbols is fine. OTH, nothing prevents us from including and exporting all those symbols
regardless of whether they are supported by the installed version of libc or not. Let me ponder on that.

 
In libpmemobj.map, libpmemobj is apparently missing these symbols:
                pmemobj_direct;
                pmemobj_oid;
                pmemobj_tx_xadd_range_direct;
                pmemobj_tx_xadd_range;
                pmemobj_tx_xalloc;

I haven't had the time to go and check these libraries in the linux build to see if the symbols exist there. On Darwin, `nm` doesn't show them in the library, and trying to use the Darwin linker's `-exported_symbols_list` option to scope them as global (and everything omitted as local) causes the linker to barf.

It's possible that the libpmemobj symbols are missing due to my botching the merge from 1.0 to 1.2.2, or from my botching the original 1.0 port. I didn't enable scoping on Darwin until this latest round of work on the makefiles.

In NVML version 1.2 pmemobj_direct is an inline function defined in libpmemobj.h, so in fact, it's not exported by libpmemobj.so.
It used to be historically (until NVML 0.2), so this is why it still remains in the .map file. It's OK to remove it from there.
Since NVML 1.3 it will be exported again, but that's a different story.

The other pmemobj functions has been introduced in NVML 1.2, so I bet there must have been something wrong with your merge.

Thanks,
K.

Reply all
Reply to author
Forward
0 new messages