View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003931 | unreal | installing | public | 2010-07-15 12:34 | 2010-07-16 15:29 |
| Reporter | syzop | Assigned To | ohnobinki | ||
| Priority | normal | Severity | major | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.2.9-RC1 | ||||
| Summary | 0003931: ircd no longer compiles with curl | ||||
| Description | You (ohnobinki) added a 'does curl work?' check. However, it does not work properly, it prevents the ircd from compiling with my self-compiled curl. Presumably your trick with LIBS= and such does not work, I think due to c-ares / curl configure order, where the c-ares linker flags are not sufficiently known yet (and not yet in IRCDLIBS). In any case, I can't use remote includes in CVS now. If I rip out your check, it works, but you might have a better idea. | ||||
| Steps To Reproduce | 1) Have a self compiled curl with c-ares, like by the unreal auto install thingy 2) Try to compile Unreal | ||||
| Additional Information | checking curl_easy_init() in -L/home/syzop/curl/lib -lcurl -lidn -lssh2 -lssl -lcrypto -lldap -lrt -lssl -lcrypto -lz... no configure: error: in `/home/syzop/Unreal3.2': configure: error: You asked for libcURL (remote includes) support, but it can't be found at /home/syzop/curl See `config.log' for more details. -- configure:13323: gcc -o conftest -pipe -g -fno-inline -Wall -Wno-strict-aliasing -Wno-unused -Wno-char-subscripts -Wno-format-zero-length -fstack-protector-all -Wstack-protector -DNOCLOSEFD -funsigned-char -fno-strict-aliasing -Wno-pointer-sign -DZIP_LINKS -I/home/syzop/curl/include -DUSE_LIBCURL conftest.c -lcrypt -lnsl -lz -L/home/syzop/curl/lib -lcurl -lidn -lssh2 -lssl -lcrypto -lldap -lrt -lssl -lcrypto -lz >&5 missing -lcares and related stuff... which is logical, as c-ares is not built at that point yet. guess what, that might be the reason why we didn't have such a 'does curl work' check before ;) | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| 3rd party modules | |||||
|
|
cURL can't possibly be built against a copy of c-ares that doesn't exist yet. If there is a ./curlinstall script and it wants to link against the same c-ares install that unrealircd will link against, that copy of c-ares must be around before ./curlinstall is run. How else is it even possible for ./curlinstall to be successful otherwise? :-p I'll reproduce the failure and post again when I have some further thoughts ;-). |
|
|
OK, the fix is as simple as not filtering out c-ares-specific flags from curl-config's output. When compiling against a properly installed system-libcurl, the filtering makes no difference anyways: ohnobinki@ohnopublishing ~ $ curl-config --libs -lcurl ohnobinki@ohnopublishing ~ $ readelf -d /usr/lib64/libcurl.so |grep libcares 0x0000000000000001 (NEEDED) Shared library: [libcares.so.2] ohnobinki@ohnopublishing ~ $ readelf -d /usr/lib64/libcurl.so |grep RPATH 0x000000000000000f (RPATH) Library rpath: [/usr/lib64] ohnobinki@ohnopublishing ~ $ Also, having multiple copies of the same c-ares flags shouldn't hurt as only the first copy will take effect. But... all considered, do I really have to reorder the curl/c-ares configure checks? :-p It sounds like that's the solution you want (and shouldn't be hard). |
|
|
unreal-3931-no-filter-cares.patch: This does what I want ;-) (except it doesn't go so far as to unbundle cares :-p ). unreal-3931-hacky-reorder-configure.patch: This is what you wanted, syzop. |
|
|
We already had the discussion regarding system/self-compiled in 0003888 My post (2nd comment there) explains in clear why we do what in each case, the trade-offs, and the fact that any decision is sub-optimal. I can copy-paste my entire comment from there, but you better just re-read it. I have a feeling you can only think like 'MUST use SYSTEM libs in ALL cases, only THEN = teh ok', even though there are clear issues with it, again, mentioned in my comment in 0003888. It's only safe to use the system libs when using a package manager or something like bsd ports, which upgrade unreal when dependency libs are updated (and are not ABI compatible). But again, now I'm repeating myself, the comment from 0003888. c-ares has a really bad track record with regards to ABI incompatibility, and curl isn't that great either. OpenSSL on the other hand, has quite a good one. And zlib is really excelent. Your suggestion to rip out our c-ares and always use system c-ares will therefore cause crashes whenever c-ares decides to break the ABI yet again. Crashes and things that suddenly make the ircd no longer able to boot are a bad thing IMO, and if we can avoid them, we should. If your opinion is that such a crash or non-working ircd is fine, and that the user should take care of it "because it's not our fault" (or contact their sysadmin to address the issue), that's fine, that's your opinion and isn't totally weird. But *I*, I put avoiding crashes and having a working IRCd first, above any "religious-like" thoughts, "100% correctness without having an eye for the rest", whatever, by lack of a better word :P. EDIT: I just realized that a better comparison would be: pragmatism versus idealism :) The only remaining case I can see with self-compiled is when it was self-compiled against c-ares X and we now use c-ares Y. This (letting CVS aside) can only happen if you have like done curlinstall in unreal version X, and later re-use it in unreal version Y. It would be nice if we could detect this, though I don't think we can. We could warn the user about it, though, I'll do that. Done: - Added some checks in ./Config which (often) ensures that the self-compiled curl version is new enough and is not using a c-ares which is binary incompatible. If the self-compiled curl version is (too) outdated, then we now suggest to rename it and have the installer re-download and compile it automatically. This avoids some potential crashes. Then everything as far as self-compiled is covered. If you screw up anything with system-libs, which is easy as mentioned above, then you're on your own :) |
|
|
You can commit unreal-3931-hacky-reorder-configure.patch if you want. Just tested it and it fixes things here :) I could do it, but I don't want to take credit for it... |
|
|
Fixed using the second patch. Sorry, I didn't intend to break this ;-) - Support compiling with a bundled c-ares again, the hacky way. (0003931) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-07-15 12:34 | syzop | New Issue | |
| 2010-07-15 12:34 | syzop | Status | new => assigned |
| 2010-07-15 12:34 | syzop | Assigned To | => ohnobinki |
| 2010-07-15 12:34 | syzop | QA | => Not touched yet by developer |
| 2010-07-15 12:34 | syzop | U4: Need for upstream patch | => No need for upstream InspIRCd patch |
| 2010-07-15 12:34 | syzop | U4: Upstream notification of bug | => Not decided |
| 2010-07-15 12:34 | syzop | U4: Contributor working on this | => None |
| 2010-07-15 12:35 | syzop | Additional Information Updated | |
| 2010-07-15 12:35 | syzop | Relationship added | child of 0003776 |
| 2010-07-15 23:40 | ohnobinki | Note Added: 0016201 | |
| 2010-07-16 01:14 | ohnobinki | Note Added: 0016202 | |
| 2010-07-16 01:47 | ohnobinki | File Added: unreal-3931-no-filter-cares.patch | |
| 2010-07-16 02:15 | ohnobinki | File Added: unreal-3931-hacky-reorder-configure.patch | |
| 2010-07-16 02:17 | ohnobinki | Relationship added | related to 0003925 |
| 2010-07-16 02:20 | ohnobinki | Note Added: 0016204 | |
| 2010-07-16 12:56 | syzop | Note Added: 0016206 | |
| 2010-07-16 12:57 | syzop | Note Edited: 0016206 | |
| 2010-07-16 12:59 | syzop | Note Added: 0016207 | |
| 2010-07-16 15:29 | ohnobinki | Note Added: 0016212 | |
| 2010-07-16 15:29 | ohnobinki | Status | assigned => resolved |
| 2010-07-16 15:29 | ohnobinki | Fixed in Version | => 3.2.9-RC1 |
| 2010-07-16 15:29 | ohnobinki | Resolution | open => fixed |
