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

non-unique header files /usr/include/ircd/* #179

Open
jonassmedegaard opened this issue Jan 3, 2021 · 8 comments
Open

non-unique header files /usr/include/ircd/* #179

jonassmedegaard opened this issue Jan 3, 2021 · 8 comments
Labels
bug Something isn't right. build Related to compiling, linking, packaging and distribution.

Comments

@jonassmedegaard
Copy link

Building and installing Construct introduces files below /usr/share/ircd which on Debian-based systems clash with files in package hybrid-dev.

Other files clash as well, avoidable like this:

STEM = construct
CONFIGURE_ARGS += --sysconfdir=/etc/$(STEM) --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)/$(STEM)/

...but those header files seem unavoidable - other than not installing them at all.

If Construct really do share header files with the hybrid ircd server daemon, then I guess it would help if that was documented somewhere, so that in Debian we could break out the shared part as a separate package used by both sets of packages.
Otherwise, it seems best if Construct would by default consistently use "construct" as its namespace, not "polute" namespaces from the projects it was (as I understand it) forked from.

@jonassmedegaard
Copy link
Author

Argh - I see now that not only those header files gets installed, but also /usr/lib/x86_64-linux-gnu/libircd.so.3.0.2 and /usr/lib/x86_64-linux-gnu/libircd_matrix.so.0.0.1 and the usual set of symlinks for those.

@jevolk
Copy link
Member

jevolk commented Jan 3, 2021

Thanks, I think the ideal course here is to substitute some configurable $BRANDING that will end up prefixing includes, or some other namespace indeed. I've been considering ctor.

Without endeavoring on any major changes at this time though, it might be possible to mitigate this issue by nesting the installed assets in a directory like /usr/include/ctor/ which would end up just containing /usr/include/ctor/ircd/ and the package would obviously adjust the -I/path accordingly (since #include expects <ircd/*>.

As for linking, it's probably best to have libircd as libircd_ctor or somehow ctor/libircd. That part might require some intervention, but probably a lot less than the top end.

@jonassmedegaard
Copy link
Author

correction: I was too quick about the concrete clash with package hybrid-dev - that package is patched to instead use ircd-hybrid as its namespace, specific for the Debian package.

The issue I raise remains that the default namespace clashes with the default namespace of other projects.

@jonassmedegaard
Copy link
Author

yes, sounds sensible to "push" the existing name into another new one. I am not skilled in programming that, though - so hope you would find it relevant to do the actual work :-)

@jevolk
Copy link
Member

jevolk commented Jan 3, 2021

Indeed this has been a wider issue with the many, many forks of IRCd over the decades :)

that package is patched to instead use ircd-hybrid as its namespace, specific for the Debian package.

Anything that can be done to make it ircd-ctor in the same ways is desirable. Thank you!

@jevolk jevolk added bug Something isn't right. build Related to compiling, linking, packaging and distribution. labels Jan 3, 2021
@jonassmedegaard
Copy link
Author

Seems this works:

./configure --sysconfdir=/etc/construct --libdir=/usr/lib/ctor --includedir=/usr/include/ctor

I have only tried compiling (and not even completed that yet), not actually tried run the resulting code, so not certain if that needs messing with environment variable LD_LIBRARY_PATH to locate the libraries at runtime.

@jevolk
Copy link
Member

jevolk commented Jan 3, 2021

Seems this works:

./configure --sysconfdir=/etc/construct --libdir=/usr/lib/ctor --includedir=/usr/include/ctor

I have only tried compiling (and not even completed that yet), not actually tried run the resulting code, so not certain if that needs messing with environment variable LD_LIBRARY_PATH to locate the libraries at runtime.

This looks very promising now, sweet! Don't mind posting up anything you've done even if some elements are broken/incomplete, or conflicts still exist. I surmised there might be some non-trivial effort required here eventually.

@jonassmedegaard
Copy link
Author

Not sure what more to provide here.

This is a full build log of a successful build by an official Debian autobuilder: https://buildd.debian.org/status/fetch.php?pkg=matrix-construct&arch=amd64&ver=0.6.103%7Edfsg1%2B%7E6.11.4-2&stamp=1619277253&raw=0

These are the relevant lines from that build log (including also the debhelper wrapper command, to indicate which options were not part of debhelper default configure flags:

dh_auto_configure -- --enable-generic --enable-opencl --sysconfdir=/etc/construct --libdir=/usr/lib/x86_64-linux-gnu/ctor --includedir=/usr/include/ctor --enable-optimize
	./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --enable-generic --enable-opencl --sysconfdir=/etc/construct --libdir=/usr/lib/x86_64-linux-gnu/ctor --includedir=/usr/include/ctor --enable-optimize

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't right. build Related to compiling, linking, packaging and distribution.
Projects
None yet
Development

No branches or pull requests

2 participants