CDT packages don't work

[isuruf]

The new compilers work fine now, but the CDT packages don't work now.

[isuruf]

@beckermr, CDTs end up in $PREFIX/x86_64-conda_cos6-linux-gnu, but the compiler only looks at $PREFIX/x86_64-conda-linux-gnu

[beckermr]

Can you explain?

[beckermr]

Ohhhh

[beckermr]

Huh?

[beckermr]

The tests in them would preclude that.

[isuruf]

What do you mean?

[beckermr]

We have tests in the sysroot packages that test that the libs are in the right spot on install.

[isuruf]

I'm not talking about the libs in the sysroot package. I mean the libs in the CDT packages. For eg: https://anaconda.org/conda-forge/libxt-cos7-ppc64le

[beckermr]

Ohhhh crap.

[beckermr]

An automated migration for those will be a nightmare.

[isuruf]

We don't even build CDTs for x86_64. We just use the ones from defaults.

[isuruf]

I hate saying this given the good work you've put into this, but shall we mark the new compilers as broken for a while?

[beckermr]

That’s not an option for me. I have colleagues depending on this.

[isuruf]

We'll be breaking all recipes using CDTs though.

[beckermr]

Not if we put in symlinks that replicate the old sysroot. We now have an excellent reason to keep the old ones.

[isuruf]

How is that going to work?

[beckermr]

What do you mean? We adjust the linux sysroot packages to use the old sysroot names and then add a symlink to the new one.

[isuruf]

Do you mean 2.17 would also be in cos6?

[beckermr]

Yep why not. It is just a directory name. Actually pulling cos7 CDTs is a much bigger issue that I don't think we can solve.

[isuruf]

Can you send a PR to fix sysroot_linux-64=2.12? I think that should be enough to solve the issues.

If we build the compilers with sysroot_linux with no conda_cos6 folders as we have already done, the index.json will have conda files only. Then, we can actually have sysroot_linux-64=2.17 with conda_cos7 and cos7 CDTs.

[beckermr]

Just to be clear, we’ll need symlinks from the compiler shim sysroot to the current one.

Also, should we be worried about mixing cdts between cos6 and cos7? Do we need to put in run constraints on say the sysroot package or some sort of centos cdt mutex?

[isuruf]

Just to be clear, we’ll need symlinks from the compiler shim sysroot to the current one.

Yes, we need to move the sysroot_linux-64's files to conda_cos6 and add a symlink, conda->conda_cos6.

Also, should we be worried about mixing cdts between cos6 and cos7?

Not at the moment.

[beckermr]

Ok if we are not worried about mixing cdts then I propose we stuff the cos7 sysroot in the cos6 path too. Otherwise people who use cos7 won’t have any CDTs at all.

[isuruf]

Otherwise people who use cos7 won’t have any CDTs at all.

What I mean is it's bad to mix CDTs, but we shouldn't worry about a mutex for now since we don't have any cos7 CDTs.

People who want to use cos7 should build CDTs for cos7.

[beckermr]

Hmm ok. I’d be nice to have an answer for automatically generating the cdt packages.

[beckermr]

Also we should have a story on a mutex before we ask ppl to build cdts

[isuruf]

If you use conda-build, there's a kind of mutex because {{ cdt('foo') }} will be expanded to foo_{{ cdt_name }}_{{ cdt_arch }} and cdt_name is constant for a given run

[beckermr]

Ah so we can set cdt name then. Sounds good.

[beckermr]

Should we rename the kernel headers and sysroot packages to use the cdt jinja2 in order to make them be able to be selected by the same logic?

[isuruf]

What would the run requirement for the compiler be then?

[beckermr]

We could / should insert shim cdts for the sysroot that people can insert into the build section. These cdts would simply have a run dep on the correct sysroot version. The actual compiler packages would stay the same. This way people can make sure to use the same cdt version as they have for the libraries in the host section.

[s22chan]

For the time being, can you remove the main label from

linux-64/gxx_impl_linux-64-7.5.0-h64c220c_7 and linux-64/gxx_impl_linux-64-7.5.0-h64c220c_8

packages since this is breaking clang builds that rely on CONDA_BUILD_SYSROOT being defined correctly by the compiler activation script.

[beckermr]

I’m about to go to bed. We will fix this tomorrow morning for sure.

[beckermr]

I’d you can send a pr to cf mark broken in the next 5 mins or so I can merge it.

[s22chan]

you do that via anaconda.org or the CLI: https://docs.anaconda.com/anaconda-cloud/user-guide/tutorials/

see move labels

[isuruf]

@s22chan, we use https://github.com/conda-forge/cf-mark-broken for it. Can you send a PR?

[s22chan]

@isuruf this tool doesn't work (to remove a broken build from being in the conda solution set), since it only adds a broken label, but doesn't remove the main label

[s22chan]

you can see that most of the sysroot packages and gxx_impl packages have both main and broken labels
nm - I see that conda resolves the labels differently nowadays

[beckermr]

see here: conda-forge/linux-sysroot-feedstock#18

[beckermr]

see here too: conda-forge/linux-sysroot-feedstock#19

[beckermr]

closing this one since the sysroot paths are now fixed!