[bug] Regression: PR #8740 breaks adding objects to link through sharedlinkflags

mimalloc/1.6.7 uses self.cpp_info.sharedlinkflags and self.cpp_info.exelinkflags to add objects to link. (Do note, I am not the maintainer of this package, just a user)

https://github.com/conan-io/conan/pull/8740 makes a change that assumes any ‘sharedlinkflags’ starting with / is a msvc flag changes it to -. This breaks absolute unix urls, like a full path to an object, by changing /some/path.o to -some/path.o.

I’m not sure if this is a regression due to the assumption made in #8740 or due to miss-use of sharedlinkflags by mimalloc. But it’s regressed usage of mimalloc which previously worked.

[elqueffo]

A couple of quick questions:

• This configuration of the recipe (option) is not built by default by ConanCenter, so it is difficult to know if this feature breaks or not in the CI. So far this seems a bit of abuse of the xxxlinkflags feature to provide a linkage that is not implemented in Conan. Is it possible to fallback to normal static library while we figure out? Because the right approach seems to explicitly model self.cpp_info.objects or something like that.

It is not possible to use a normal static library while at the same time guaranteeing that the overrides work. This has to be done using an object file. self.cpp_info.objects would be great, but it doesn’t solve the ordering problem below:

• From https://github.com/microsoft/mimalloc#static-override, to link with that library object, it should be linked as the first object, I am not sure if this really works on consumers side. How are you dealing with it? How are you guaranteeing that it is the first object?

This is why link flags is used, because link flags come before any other object files on the commandline. It’s a pretty dirty workaround, but personally i don’t see any obvious other ways to do it, unless we can directly modify the object file list.

On windows builds there is a similar problem; somehow we have to guarantee the .lib for the override dll comes first on the commandline, otherwise the overrides will not actually override everything correctly. Currently i deal with this seperately in cmake by setting the linker command.

[memsharded]

self.cpp_info.objects would be great, but it doesn’t solve the ordering problem below:

It seems difficult to come with an ordering definition for this. If we treat objects that could have transitive dependencies to other objects in dependencies packages, then the rule should be the same as the libs linkage order that is happening now, and objects shouldn’t just go before everything else… It doesn’t seem possible that we just put the objects first always.

So yes, I don’t see at the moment any solution that does not look a workaround and that is general enough. Lets revert this and lets keep thinking about this. All feedback and ideas welcome.