Re: devel/binutils and devel/gnulibiberty version mismatch
On Sun, May 11, 2014 at 5:41 PM, Geoff Speicher wrote: > Actually, I have a question about ports/184327. This bug report asserts > that ansidecl.h is an internal file necessary only to build the GNU > toolchain and should not be installed by devel/binutils. However, binutils > also installs bfd.h which happens to include ansidecl.h (at least, it does > in v2.24). Therefore, the installed bfd.h is broken. This fact either > contradicts the original assertion that ansidecl.h should not be installed, > or else it implies that bfd.h should not be installed either. > There was a third possibility that I had overlooked, and appears to be a decent compromise: bfd.h doesn't actually need to directly include ansidecl.h for anything that I can see, so if we patch the port to remove the include directive then bfd.h is no longer broken and ports/184327 is also satisfied. Any objections to this? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: devel/binutils and devel/gnulibiberty version mismatch
On Sun, May 11, 2014 at 3:56 PM, Niclas Zeising wrote: > On 05/09/14 20:08, Gerald Pfeifer wrote: > > On Fri, 9 May 2014, Geoff Speicher wrote: > >> Bringing in other parties for feedback, based on their mention in the > >> binutils commit (svn link below). > > > > This reminded me of ports/184327: devel/binutils erroneously installs > > $PREFIX/include/ansidecl.h. > > That has been fixed, when I updated devel/binutils to 2.24. > Regards! > Actually, I have a question about ports/184327. This bug report asserts that ansidecl.h is an internal file necessary only to build the GNU toolchain and should not be installed by devel/binutils. However, binutils also installs bfd.h which happens to include ansidecl.h (at least, it does in v2.24). Therefore, the installed bfd.h is broken. This fact either contradicts the original assertion that ansidecl.h should not be installed, or else it implies that bfd.h should not be installed either. However, if we did not install bfd.h then we probably shouldn't install bfd.a either, and at least some ports seem to rely on binutils to provide them both. So I am questioning whether the removal of ansidecl.h from the devel/binutils install is the optimal fix, or if there is a better way to handle this that allows lang/gcc49 to work without breaking devel/binutils and programs that rely on BFD. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: devel/binutils and devel/gnulibiberty version mismatch
On Fri, May 9, 2014 at 2:08 PM, Gerald Pfeifer wrote: > On Fri, 9 May 2014, Geoff Speicher wrote: > > Bringing in other parties for feedback, based on their mention in the > > binutils commit (svn link below). > > This reminded me of ports/184327: devel/binutils erroneously installs > $PREFIX/include/ansidecl.h. > > Please make sure this does not resurface from the dead. > > As far as libiberty.a goes, I think at least the lang/gcc* ports should > be good. > Gotcha. It's a simple enough patch to devel/binutils to bring back libiberty.a and update the Makefile to current USES standards. I can submit via send-pr unless there are any objections or other feedback. Ideally this would be committed at the same time as the removal of the other two ports and the related updated dependencies but I'm not sure if I can submit something like that with send-pr or if someone with the ability to make it happen just needs to do it. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: devel/binutils and devel/gnulibiberty version mismatch
Bringing in other parties for feedback, based on their mention in the
binutils commit (svn link below).
On Thu, May 8, 2014 at 8:41 AM, Geoff Speicher
wrote:
> On Wed, May 7, 2014 at 12:30 PM, Geoff Speicher <
> ge...@sea-incorporated.com> wrote:
>
>> On Wed, May 7, 2014 at 12:05 PM, Geoff Speicher <
>> ge...@sea-incorporated.com> wrote:
>>
>>> devel/binutils is at version 2.24, and as of 16-Dec-2013 no longer
>>> installs libiberty [1], but does install libbfd, which gets linked against
>>> the copy of libiberty (v2.24) in the build tree.
>>>
>>> To link an application against libbfd from devel/binutils, one must
>>> install devel/gnulibiberty to resolve the missing symbols, but that port
>>> uses libiberty from binutils v2.19.1 which doesn't contain all the symbols
>>> from v2.24 (e.g. filename_ncmp at a minimum).
>>>
>>> There is a separate devel/libbfd port that matches the version in
>>> devel/gnulibiberty but if your port requires ${LOCALBASE}/libbfd.a and
>>> devel/gnulibiberty as build dependencies, and you already have
>>> devel/binutils installed, then your port will fail when linking.
>>>
>>> Should I just mark the port as conflicting with devel/binutils or is
>>> there a better workaround for this?
>>>
>>> [1] http://svnweb.freebsd.org/ports?view=revision&revision=336642
>>>
>>
>> Sorry for responding to myself, but it gets worse: the port I'm working
>> on requires gcc from ports (at least on FreeBSD 8.4, because it needs a
>> c++11 compiler), which depends on devel/binutils, so I can't conflict with
>> binutils or else I don't have a compiler.
>>
>> Is there any reason why devel/libbfd and devel/gnulibiberty shouldn't be
>> upgraded to v2.24?
>>
>>
> Joerg, maintainer of devel/libbfd and devel/gnulibiberty (and cc'ed on
> this response), and I have come to the conclusion that these two ports
> should simply be removed in favor of devel/binutils (maintained by Martin,
> also cc'ed). Until recently, only four ports required libbfd and/or
> gnulibiberty: devel/avarice <https://www.freshports.org/devel/avarice/>,
> emulators/skyeye <https://www.freshports.org/emulators/skyeye/>,
> devel/fpc-bfd <https://www.freshports.org/devel/fpc-bfd/>, and
> archivers/tardy <https://www.freshports.org/archivers/tardy/>. Joerg
> originally created the ports for libbfd and gnulibiberty to support his
> port of devel/avarice, but that no longer needs them after the last upgrade
> so he just dropped the
> dependency<http://svnweb.freebsd.org/ports?view=revision&revision=353276>leaving
> only three dependent ports, which can be changed to depend on
> devel/binutils <https://www.freshports.org/devel/binutils/> instead.
>
> Martin/Joerg, would the two of you be willing and able to coordinate to
> change binutils so that it installs libiberty.a (and headers) again,
> replace the dependencies for those three remaining ports, and remove the
> two ports that are no longer needed? Let me know if there is anything I can
> do to help.
>
> Geoff
>
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: devel/binutils and devel/gnulibiberty version mismatch
On Wed, May 7, 2014 at 12:30 PM, Geoff Speicher
wrote:
> On Wed, May 7, 2014 at 12:05 PM, Geoff Speicher <
> ge...@sea-incorporated.com> wrote:
>
>> devel/binutils is at version 2.24, and as of 16-Dec-2013 no longer
>> installs libiberty [1], but does install libbfd, which gets linked against
>> the copy of libiberty (v2.24) in the build tree.
>>
>> To link an application against libbfd from devel/binutils, one must
>> install devel/gnulibiberty to resolve the missing symbols, but that port
>> uses libiberty from binutils v2.19.1 which doesn't contain all the symbols
>> from v2.24 (e.g. filename_ncmp at a minimum).
>>
>> There is a separate devel/libbfd port that matches the version in
>> devel/gnulibiberty but if your port requires ${LOCALBASE}/libbfd.a and
>> devel/gnulibiberty as build dependencies, and you already have
>> devel/binutils installed, then your port will fail when linking.
>>
>> Should I just mark the port as conflicting with devel/binutils or is
>> there a better workaround for this?
>>
>> [1] http://svnweb.freebsd.org/ports?view=revision&revision=336642
>>
>
> Sorry for responding to myself, but it gets worse: the port I'm working on
> requires gcc from ports (at least on FreeBSD 8.4, because it needs a c++11
> compiler), which depends on devel/binutils, so I can't conflict with
> binutils or else I don't have a compiler.
>
> Is there any reason why devel/libbfd and devel/gnulibiberty shouldn't be
> upgraded to v2.24?
>
>
Joerg, maintainer of devel/libbfd and devel/gnulibiberty (and cc'ed on this
response), and I have come to the conclusion that these two ports should
simply be removed in favor of devel/binutils (maintained by Martin, also
cc'ed). Until recently, only four ports required libbfd and/or
gnulibiberty: devel/avarice <https://www.freshports.org/devel/avarice/>,
emulators/skyeye <https://www.freshports.org/emulators/skyeye/>,
devel/fpc-bfd <https://www.freshports.org/devel/fpc-bfd/>, and
archivers/tardy <https://www.freshports.org/archivers/tardy/>. Joerg
originally created the ports for libbfd and gnulibiberty to support his
port of devel/avarice, but that no longer needs them after the last upgrade
so he just dropped the
dependency<http://svnweb.freebsd.org/ports?view=revision&revision=353276>leaving
only three dependent ports, which can be changed to depend on
devel/binutils <https://www.freshports.org/devel/binutils/> instead.
Martin/Joerg, would the two of you be willing and able to coordinate to
change binutils so that it installs libiberty.a (and headers) again,
replace the dependencies for those three remaining ports, and remove the
two ports that are no longer needed? Let me know if there is anything I can
do to help.
Geoff
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: devel/binutils and devel/gnulibiberty version mismatch
On Wed, May 7, 2014 at 12:05 PM, Geoff Speicher
wrote:
> devel/binutils is at version 2.24, and as of 16-Dec-2013 no longer
> installs libiberty [1], but does install libbfd, which gets linked against
> the copy of libiberty (v2.24) in the build tree.
>
> To link an application against libbfd from devel/binutils, one must
> install devel/gnulibiberty to resolve the missing symbols, but that port
> uses libiberty from binutils v2.19.1 which doesn't contain all the symbols
> from v2.24 (e.g. filename_ncmp at a minimum).
>
> There is a separate devel/libbfd port that matches the version in
> devel/gnulibiberty but if your port requires ${LOCALBASE}/libbfd.a and
> devel/gnulibiberty as build dependencies, and you already have
> devel/binutils installed, then your port will fail when linking.
>
> Should I just mark the port as conflicting with devel/binutils or is there
> a better workaround for this?
>
> [1] http://svnweb.freebsd.org/ports?view=revision&revision=336642
>
Sorry for responding to myself, but it gets worse: the port I'm working on
requires gcc from ports (at least on FreeBSD 8.4, because it needs a c++11
compiler), which depends on devel/binutils, so I can't conflict with
binutils or else I don't have a compiler.
Is there any reason why devel/libbfd and devel/gnulibiberty shouldn't be
upgraded to v2.24?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
devel/binutils and devel/gnulibiberty version mismatch
devel/binutils is at version 2.24, and as of 16-Dec-2013 no longer installs
libiberty [1], but does install libbfd, which gets linked against the copy
of libiberty (v2.24) in the build tree.
To link an application against libbfd from devel/binutils, one must install
devel/gnulibiberty to resolve the missing symbols, but that port uses
libiberty from binutils v2.19.1 which doesn't contain all the symbols from
v2.24 (e.g. filename_ncmp at a minimum).
There is a separate devel/libbfd port that matches the version in
devel/gnulibiberty but if your port requires ${LOCALBASE}/libbfd.a and
devel/gnulibiberty as build dependencies, and you already have
devel/binutils installed, then your port will fail when linking.
Should I just mark the port as conflicting with devel/binutils or is there
a better workaround for this?
[1] http://svnweb.freebsd.org/ports?view=revision&revision=336642
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: USES=compiler:c++11-lib on FreeBSD 8.4
On Tue, Apr 29, 2014 at 4:08 AM, Tijl Coosemans wrote:
> On Mon, 28 Apr 2014 22:38:55 -0400 Geoff Speicher wrote:
> > Not sure if ports is the right place for this post so apologies in
> advance
> > if I'm not in the right place.
> >
> > I'm porting an application that requires c++11, and I'm trying to create
> > the port on a FreeBSD 8.4 box. From everything I have read, it appears
> that
> > c++11 is only supported in 9.1+ when world has been built with the c++11
> > toolchain. However, the various ports switches such as
> > USES=compiler:c++11-lib don't yield any warnings on 8.4, yet don't seem
> to
> > work either. Can anyone comment on whether or not this option is supposed
> > to work on 8.4?
> >
> > Taking ports out of the equation for a moment, I can't compile the
> > following c++11 file:
> >
> > // test.cpp
> > #include
> > #include
> >
> > int main() {
> > int number = 10;
> > std::string value;
> > value = std::to_string(number);
> > }
> > // EOF
> >
> > clang++33 fails on a new c++11 include file:
> >
> > $ clang++33 -std=c++11 test.cpp
> > test.cpp:1:10: fatal error: 'type_traits' file not found
> > #include
> > ^
> > 1 error generated.
> >
> >
> > g++47 at least finds the include file but doesn't appear to define
> > std::to_string as it should:
> >
> > $ g++47 -std=c++11 test.cpp
> > test.cpp: In function 'int main()':
> > test.cpp:7:11: error: 'to_string' is not a member of 'std'
> >
> > I also tried installing devel/libc++ and that fails trying to include
> > xlocale.h, which only appears to exist in 9.1 and later. Am I missing
> > something here or is c++11 simply not supported on 8.4? Assuming the
> > latter, is there a way to automatically make ports fail with a meaningful
> > error message on <9.0 when attempting to use c++11-lang or c++11-lib?
>
> On 8.x one of the gcc ports has to be used if you need a c++11 library,
> but it appears that the declarations of to_string in bits/basic_string.h
> are hidden behind #ifdef _GLIBCXX_USE_C99 and that macro isn't defined
> on FreeBSD because we are missing a few obscure c99 functions.
> I think it would be best to patch the gcc ports to force the definition
> of that macro.
>
Thanks for responding. In the meantime, I'll just hack that flag into
CXXFLAGS for this port unless you have any other suggestions.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
USES=compiler:c++11-lib on FreeBSD 8.4
Not sure if ports is the right place for this post so apologies in advance
if I'm not in the right place.
I'm porting an application that requires c++11, and I'm trying to create
the port on a FreeBSD 8.4 box. From everything I have read, it appears that
c++11 is only supported in 9.1+ when world has been built with the c++11
toolchain. However, the various ports switches such as
USES=compiler:c++11-lib don't yield any warnings on 8.4, yet don't seem to
work either. Can anyone comment on whether or not this option is supposed
to work on 8.4?
Taking ports out of the equation for a moment, I can't compile the
following c++11 file:
// test.cpp
#include
#include
int main() {
int number = 10;
std::string value;
value = std::to_string(number);
}
// EOF
clang++33 fails on a new c++11 include file:
$ clang++33 -std=c++11 test.cpp
test.cpp:1:10: fatal error: 'type_traits' file not found
#include
^
1 error generated.
g++47 at least finds the include file but doesn't appear to define
std::to_string as it should:
$ g++47 -std=c++11 test.cpp
test.cpp: In function 'int main()':
test.cpp:7:11: error: 'to_string' is not a member of 'std'
I also tried installing devel/libc++ and that fails trying to include
xlocale.h, which only appears to exist in 9.1 and later. Am I missing
something here or is c++11 simply not supported on 8.4? Assuming the
latter, is there a way to automatically make ports fail with a meaningful
error message on <9.0 when attempting to use c++11-lang or c++11-lib?
Geoff
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Change of maintainership of textproc/fop freebsd port
Thanks to all. I'll submit the 1.0 upgrade PR in a few moments. On Fri, Oct 15, 2010 at 5:36 AM, Erwin Lansing wrote: > On Fri, Oct 15, 2010 at 09:09:42AM +0200, Jose Garcia Juanino wrote: > > Hi, > > Hi, > > > > I am the actual maintainer of textproc/fop port. Please could any > > commiter to change the maintainership to Geoff Speicher > > . He will send a patch to upgrade the port > > to 1.0 version; I am very busy at this moment and I need to drop the > > maintainership of the port. > > > Thanks a lot for your time in the past! I've handed maintainership over > to Geoff. > > Thanks again and take care, > -erwin > > -- > Erwin Lansing http://droso.org > Prediction is very difficult > especially about the futureer...@freebsd.org > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
