[
https://issues.apache.org/jira/browse/XERCESC-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767367#action_12767367
]
Scott Cantor commented on XERCESC-1892:
---------------------------------------
Yes, the bug is in xerces_curl_prefix.m4. It's explicitly using /usr/local and
/usr to try and locate the include files if no --with option is provided, and
then adds -L based on the same prefix.
I think it's also failing to use curl-config at all, which I would also say is
an additional bug.
> configure irationally forces -L/usr/local/lib
> ----------------------------------------------
>
> Key: XERCESC-1892
> URL: https://issues.apache.org/jira/browse/XERCESC-1892
> Project: Xerces-C++
> Issue Type: Bug
> Affects Versions: 3.0.1
> Reporter: Philip Brown
>
> I am building two sets of tool chains. one 32bit, in /usr/local.
> Another one, 64bit, in /usr/local/64
> I have taken everything referencing /usr/local out of my environment, and
> have successfully compiled other software. However, when it comes to xerces-c
> 3.0.1, even though I have explicitly told it
> --prefix=/usr/local/64
> it insists on adding -L/usr/local/lib for curl or something.
> I dont know for sure that curl is the reason why it is added.. but it PICKS
> UP /usr/local/lib/libcurl.la from that, and then screws up my nice 64bit
> build, by attempting to link in /usr/local/lib/libcurl.so
> When I temporarily remove libcurl.la from there, it compiles. but this is not
> an acceptible workaround.
> Actually, it would appear that specifying --with-curl=/usr/local/64
> overrides, but this is inappropriate! it should check in $prefix FIRST, not
> decide to go look in /usr/local for curl before anything else.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
