[
https://issues.apache.org/jira/browse/XERCESC-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768447#action_12768447
]
Philip Brown commented on XERCESC-1892:
---------------------------------------
reguarding "falling back to the previous hard-coded -lcurl behavior"... if that
was all the "previous" behaviour was, i wouldnt have filed the bug in the first
place :)
So to be explicit, the problem is when you add -lcurl, AND add in assumed -L
paths, without checking if they were even needed.
"Since we didn't seem inundated with bug reports about that, presumably it was
working relatively well."
That's rather poor engineering principles on two fronts:
1. bugs are vastly underreported, in any software. Then on top of that, any
bugreporting mechanism that requires you to sign up for something (jira in this
case), is even further suppressed
2. Just because something works for 90% of the people, doesnt mean it isnt
broken .
When you are doing something that 95% of other autoconfigure software is NOT
doing, and it breaks stuff, you should fix it to follow the de facto standard
free software behaviour.
"I don't believe there's necessarily a requirement that we should search
prefix".
ugh. There are no "requirements" in free software whatsoever. That being said,
it's standard practice.
"In any event, we now _do_ look in $prefix for curl."
Thank you
> 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]
