Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tzdb integration #142

Merged
merged 19 commits into from
Aug 5, 2024
Merged

tzdb integration #142

merged 19 commits into from
Aug 5, 2024

Conversation

h-vetinari
Copy link
Member

Retry bits that were de-scoped from #133

@conda-forge-webservices
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Copy link
Member

@jjerphan jjerphan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A first quick review.

+ this_lib = (char*)malloc(total_length + 1);
+ memcpy(this_lib, resolved, total_length);
+#endif
+
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For extra safety?

Suggested change
+
+
+ this_lib[static_cast<size_t>(total_length)] = '\0';

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's impossible to have a conda environment where the /lib folder does not have at least depth 1 (and thus a guaranteed null byte that we'll insert below). Not sure what the extra null byte would achieve

+ if (dladdr(addr, &info)) {
+ char* resolved = realpath(info.dli_fname, buffer);
+ if (resolved) {
+ int total_length = (int)strlen(resolved);
Copy link
Member

@jjerphan jjerphan Jun 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we prefer static_cast?

This suggestion applies in other places.

+ // we're in $PREFIX/lib/libstdcxx.so
+# define TO_PREFIX "/.."
+# define PATH_SEP '/'
+ char buffer[PATH_MAX];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity, where is PATH_MAX defined?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took this over from https://github.com/gpakosz/whereami, but some googling says its from <limits.h>.

recipe/build.sh Outdated Show resolved Hide resolved
@h-vetinari
Copy link
Member Author

OK, this now passes some basic tests, though I'm sure the implementation can be improved (e.g. less allocations as @mbargull pointed out in #133). It's still using the -ldl debug work-around (when we should really be adding libdl to the link interface of libstdc++.so (equivalent of CMake's target_link_libraries), but as I noted in #133:

I think it should be something like AC_LIB_LINKFLAGS, but the makefile(s) in GCC are just indecipherable for me (though I really tried to find where the shared lib gets defined...). Any ideas how/where to do this?

CC @conda-forge/ctng-compilers

recipe/tests/tzdb.cpp Outdated Show resolved Hide resolved
@h-vetinari h-vetinari force-pushed the tzdb branch 7 times, most recently from eebb928 to 0ed42a0 Compare July 1, 2024 06:02
loading zoneinfo_dir_override as an extern function does not actually
get the address of the function where it is defined (c.f. implementation
```
void* addr = __builtin_extract_return_addr(__builtin_return_address(0));
```
), but ends up returning the address of the file from where it is called.

As such, in order to observe/test the zoneinfo_dir_override implementation,
export libstdcxx's zoneinfo_file, which does exactly what's needed.
@h-vetinari
Copy link
Member Author

I haven't managed to get rid of -ldl being for linking to libstdc++.so, I'm either going to need a tip there how to add this to the link interface through autotools, or alternatively, we could just add -ldl to the default C++ flags in the activation feedstock.

@isuruf, this still fails when we compile something that needs libstdc++, because the -ldl is not automatically added. I don't know how to "bake this in"; unless you have an idea how to achieve this, I propose to add -ldl to the activation feedstock. WDYT?

@isuruf
Copy link
Member

isuruf commented Jul 17, 2024

@isuruf, this still fails when we compile something that needs libstdc++, because the -ldl is not automatically added. I don't know how to "bake this in"; unless you have an idea how to achieve this, I propose to add -ldl to the activation feedstock. WDYT?

That's because libstdc++.so is not getting linked to libdl with my changes nor yours. Basically the patch you add doesn't work.

@h-vetinari
Copy link
Member Author

Basically the patch you add doesn't work.

That's not a big surprise to me; it was an exploratory change, because I saw -lm in there, and hoped that it would similarly translate. I stared at the makefiles for a while, but I cannot even make out where the .so is defined, nor do I know for sure that AC_LIB_LINKFLAGS would be the right approach if I did find it.

@h-vetinari
Copy link
Member Author

h-vetinari commented Jul 17, 2024

That's because libstdc++.so is not getting linked to libdl with my changes nor yours.

Though it is getting linked successfully while building with that change; before this patch, I needed to explicitly add -ldl in build.sh (see c01b031); after the patch that was not necessary anymore. However, that linkage information doesn't persist until after the build, when we're trying to link the test code with libstdc++

@h-vetinari
Copy link
Member Author

If I do patch the Makefiles again, is it important for you to use the -Bstatic -ldl -Bdynamic -Wl,--exclude-libs,libdl.a stuff, or was that just exploratory as well?

@mbargull
Copy link
Member

If I do patch the Makefiles again, is it important for you to use the -Bstatic -ldl -Bdynamic -Wl,--exclude-libs,libdl.a stuff, or was that just exploratory as well?

I haven't yet thought about the static linking case; I'll leave this one for @isuruf since he is more of an expert than me on it ;).

@isuruf
Copy link
Member

isuruf commented Jul 17, 2024

Yes, we should link in libdl.a statically

@conda-forge-webservices
Copy link

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

@h-vetinari
Copy link
Member Author

This should be good now. Thanks for your help @isuruf & @mbargull!

@h-vetinari
Copy link
Member Author

Gentle ping @conda-forge/ctng-compilers

@h-vetinari
Copy link
Member Author

All good now?

Comment on lines +33 to +36
-#ifdef _AIX
- // Cannot override weak symbols on AIX.
- const char* (*zoneinfo_dir_override)() = nullptr;
-#else
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's keep this block or at least #error so that we don't trip if we build this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, probably not needed since we have tests.

@isuruf isuruf merged commit 2cdc2b9 into conda-forge:main Aug 5, 2024
64 checks passed
@isuruf
Copy link
Member

isuruf commented Aug 5, 2024

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants