View Issue Details

IDProjectCategoryView StatusLast Update
0003931unrealinstallingpublic2010-07-16 15:29
Reportersyzop Assigned Toohnobinki  
PrioritynormalSeveritymajorReproducibilityhave not tried
Status resolvedResolutionfixed 
Fixed in Version3.2.9-RC1 
Summary0003931: ircd no longer compiles with curl
DescriptionYou (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 Reproduce1) Have a self compiled curl with c-ares, like by the unreal auto install thingy
2) Try to compile Unreal
Additional Informationchecking 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 ;)
TagsNo tags attached.
3rd party modules


related to 0003925 closed curlinstall broken 
child of 0003776 resolvedsyzop Unreal3.2.9 TODO 



2010-07-15 23:40

reporter   ~0016201

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 ;-).


2010-07-16 01:14

reporter   ~0016202

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
ohnobinki@ohnopublishing ~ $ readelf -d /usr/lib64/ |grep libcares
 0x0000000000000001 (NEEDED) Shared library: []
ohnobinki@ohnopublishing ~ $ readelf -d /usr/lib64/ |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).

2010-07-16 01:47


2010-07-16 02:15



2010-07-16 02:20

reporter   ~0016204

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.


2010-07-16 12:56

administrator   ~0016206

Last edited: 2010-07-16 12:57

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.
- 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 :)


2010-07-16 12:59

administrator   ~0016207

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...


2010-07-16 15:29

reporter   ~0016212

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)

Issue History

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