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
maxscale: init at 2.1.17 #33835
maxscale: init at 2.1.17 #33835
Conversation
73286b9
to
0021a4e
Compare
enableParallelBuilding = true; | ||
|
||
postInstall = '' | ||
patchelf --set-rpath ${stdenv.lib.makeLibraryPath [ curl gcc.cc.lib glibc jemalloc kerberos openssl pcre2 zlib ]}:${mariadb.connector-c}/lib/mariadb:$out/lib/maxscale $out/bin/dbfwchk |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this needs to be refactored somewhat before merging. I suggest lifting the makeLibraryPath
s and use loops for common rpaths. That said I'm a little confused why all this patching is necessary to begin with?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the end of packet build the following message appears:
-- Installing: /nix/store/xgjzyvw7y1f4jh3sx1jkd46c51y5qf1y-maxscale-2.1.13/bin/maxadmin -- Set runtime path of "/nix/store/xgjzyvw7y1f4jh3sx1jkd46c51y5qf1y-maxscale-2.1.13/bin/maxadmin" to ":/nix/store/xgjzyvw7y1f4jh3sx1jkd46c51y5qf1y-maxscale-2.1.13//nix/store/xgjzyvw7y1f4jh3sx1jkd46c51y5qf1y-maxscale-2.1.13/lib/maxscale
And as result, incorrect path to libmaxscale-common.so.1.0.0 library is written. Maybe there's another way to avoid this problem?
|
||
preConfigure = '' | ||
for i in `grep -l -R '#include <getopt.h>' .`; do | ||
substituteInPlace $i --replace "#include <getopt.h>" "#include <${glibc.dev}/include/getopt.h>" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For a properly configured toolchain, it seems odd to have to substitute in a full path to the libc headers; what motivated this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without this patch, getopt.h provided with maxscale, was included instead of glibc getopt.h, and that caused weird errors, like:
`
[ 31%] Building CXX object server/core/CMakeFiles/maxscale.dir/gateway.cc.o
In file included from /nix/store/p2bkk31685y6b4l30bp9961g6kd133wd-glibc-2.26-115-dev/include/bits/getopt_posix.h:27:0,
from /nix/store/p2bkk31685y6b4l30bp9961g6kd133wd-glibc-2.26-115-dev/include/unistd.h:872,
from /tmp/nix-build-maxscale-2.1.13.drv-0/source/server/core/gateway.cc:47:
/nix/store/p2bkk31685y6b4l30bp9961g6kd133wd-glibc-2.26-115-dev/include/bits/getopt_core.h:91:12: error: declaration of 'int getopt(int, char* const*, const char*) throw ()' has a different exception specifier
extern int getopt (int ___argc, char const ___argv, const char __shortopts)
^~~~~~
In file included from /tmp/nix-build-maxscale-2.1.13.drv-0/source/server/core/gateway.cc:42:0:
/nix/store/b1mqlzdnp32bzhbmqsk99hjmkk19rdrq-mariadb-connector-c-2.3.4/include/mariadb/getopt.h:108:12: note: from previous declaration 'int getopt(int, char const, const char)'
extern int getopt (int argc, char *const *argv, const char *shortopts);
^~~~~~
make[2]: *** [server/core/CMakeFiles/maxscale.dir/build.make:63: server/core/CMakeFiles/maxscale.dir/gateway.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:596: server/core/CMakeFiles/maxscale.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
builder for ‘/nix/store/x1if3dad7j0i24lckdz4jbyls9ifa6jg-maxscale-2.1.13.drv’ failed with exit code 2
error: build of ‘/nix/store/x1if3dad7j0i24lckdz4jbyls9ifa6jg-maxscale-2.1.13.drv’ failed
`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh ... why would they do that?
|
||
postInstall = '' | ||
patchelf --set-rpath ${libPath1}:${mariadb.connector-c}/lib/mariadb:$out/lib/maxscale $out/bin/dbfwchk | ||
patchelf --set-rpath ${libPath2}:$out/lib/maxscale $out/bin/maxadmin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder, is the primary goal here to add $out/lib/...
to the rpath? If so I think you could profitably change these calls to include patchelf --print-rpath ...
instead of specifying the libpath yourself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method does not work for binary files:
ldd /nix/store/m22fbx7l1g5s3s3y5lnb1p3b196bxyn5-maxscale-2.1.13/bin/maxscale
not a dynamic executable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, rpath wouldn't work at all then. See
patchelf --set-rpath "$(patchelf --print-rpath "$elf"):$out/lib/deja-dup" "$elf" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changed to -
patchelf --set-rpath "$(patchelf --print-rpath "$out/bin/maxscale"):$out/lib/maxscale" "$out/bin/maxscale"
Not worked -
ldd /nix/store/hn0lnffvfzqy0bnlmh30kgvxr7w8sxrq-maxscale-2.1.13/bin/maxscale
not a dynamic executable
3f43b94
to
e1a5baa
Compare
@GrahamcOfBorg build maxscale |
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: maxscale Partial log (click to expand)
|
Failure on x86_64-linux (full log) Attempted: maxscale Partial log (click to expand)
|
Failure on aarch64-linux (full log) Attempted: maxscale Partial log (click to expand)
|
05eaf40
to
33c5839
Compare
@GrahamcOfBorg build maxscale |
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: maxscale Partial log (click to expand)
|
Failure on x86_64-linux (full log) Attempted: maxscale Partial log (click to expand)
|
Failure on aarch64-linux (full log) Attempted: maxscale Partial log (click to expand)
|
@joachifm please recheck PR. Fixed build with gcc6 |
@GrahamcOfBorg build maxscale |
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: maxscale Partial log (click to expand)
|
Failure on x86_64-linux (full log) Attempted: maxscale Partial log (click to expand)
|
https://pastebin.com/W2n7YF3z - my build log |
Success on aarch64-linux (full log) Attempted: maxscale Partial log (click to expand)
|
@GrahamcOfBorg build maxscale |
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: maxscale Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: maxscale Partial log (click to expand)
|
Failure on aarch64-linux (full log) Attempted: maxscale Partial log (click to expand)
|
How to test build on an architecture aarch64-linux? |
Difficult unless you have an aarch64 machine. You can guess a fix and we can try it on ofborg. |
8fc4df8
to
125ed8d
Compare
@xeji Update config |
@GrahamcOfBorg build maxscale |
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: maxscale Partial log (click to expand)
|
Success on x86_64-linux (full log) Attempted: maxscale Partial log (click to expand)
|
Success on aarch64-linux (full log) Attempted: maxscale Partial log (click to expand)
|
Thank you, looks good now. |
Motivation for this change
Things done
build-use-sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)