[ https://issues.apache.org/jira/browse/XERCESC-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boris Kolpackov reopened XERCESC-1892: -------------------------------------- Assignee: Boris Kolpackov I am reopening this bug because I don't think the fix actually fixes the problem: XERCESC_CURL_PREFIX still searches in /usr/ and /usr/local and curl-config is called based on the path determined by XERCESC_CURL_PREFIX . I believe we should implement the following search: 1. If the path has been provided with the --with-curl option, store it in $path. 2. If we can run curl-config, (prefixed with $path/bin if $path is specified), run it to get the flags. If no curl-config found and the $path is specified, use it to construct include (-I$path/include) and library (-L$path/lib) flags. Otherwise no extra flags are used on step 3. 3. Run the compiler to make sure a test program that uses libcurl actually compiles. In particular, there are no implicit searches in --prefix (add it to --with-curl if you need it) or any standard locations (/usr, /usr/local, etc). I believe this implementation will result in the expected behavior in the majority of cases without any surprises. Let me know if anyone has any objections. Otherwise I will go ahead and implement this for all the external libraries that Xerces-C++ uses. > 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 > Assignee: Boris Kolpackov > > 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: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org