Re: anyone know how to get rid of this error? (10.4/Gcc vs binutils port)

2017-10-03 Thread Julian Elischer 

On 4/10/17 12:56 am, Ian Lepore wrote:

On Wed, 2017-10-04 at 00:18 +0800, Julian Elischer wrote:

Our 10.4 system is using gcc (for now).

when we compile the devel/binutils port, we get a failure with a
bunch
of these errors:


`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section
`.rodata' of aarch64.o: defined in discarded section
`.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__
N_110Stub_tableILi64ELb1EEE]'
of aarch64.o
`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section
`.rodata' of aarch64.o: defined in discarded section
`.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__
N_110Stub_tableILi64ELb0EEE]'
of aarch64.o


I managed to defeat these one before but I forget how.

possibly the answer is to use clang/clang++ for this item but I
tried
defining CC and CXX  to clang/clang++ in the Makefile but that
didn't
seem to help

there's probably a USE_CLANG option or something that I haven't seen.

We ran into the same thing recently at $work.  The root cause for us
involved having same-named classes in anonymous namespaces in different
compilation units.  The classes made reference to something that was
declared extern "C", bringing into play some rules about how C things
in anon namespaces really refer to the same global C object outside of
any namespace.  Then link-time optimization led to discarding the
object from one compilation unit, and that somehow resulted in
discarding the referenced extern "C" thing completely, even though it
was still referenced from the non-discarded instance of an object from
a different compilation unit.  Phew.

The same code has no problems with clang on freebsd 11, just with gcc
on 10.3.

So, for us the fix was a bit heavy-handed: we just renamed one of the
classes involved in the problem so that there were no longer any same-
named classes in anon namespaces in separate compilation units.
  Probably not a good option for you.  A fix involving compile options
might result in not discarding unreferenced segments at all, and with
templated code that might result in huge binaries.

Mixing clang-compiled and gcc-compiled c++ may give you grief with
exceptions and other things (it would on ARM on 10.x, but maybe not on
x86 arches).

-- Ian



thanks

the issue comes up in the binutils port which is a dependency of gdb.

I don't think we actually need to install the binutils port on our 
appliance, (and we only install gdb to generate backtraces on debug 
reports)


I just added CC=clang and CXX=clang++ in the makefile that called it 
and the problem seemed to go away.



All i wanted to do is get gdb compiled and I end up with gcc6, llvm 
and binutils (plus a whole lot more) as a bonus (plus an extra 30 
minutes of compile time)




___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: anyone know how to get rid of this error? (10.4/Gcc vs binutils port)

2017-10-03 Thread Ian Lepore 
On Wed, 2017-10-04 at 00:18 +0800, Julian Elischer wrote:
> Our 10.4 system is using gcc (for now).
> 
> when we compile the devel/binutils port, we get a failure with a
> bunch 
> of these errors:
> 
> 
> `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section 
> `.rodata' of aarch64.o: defined in discarded section 
> `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__
> N_110Stub_tableILi64ELb1EEE]' 
> of aarch64.o
> `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section 
> `.rodata' of aarch64.o: defined in discarded section 
> `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__
> N_110Stub_tableILi64ELb0EEE]' 
> of aarch64.o
> 
> 
> I managed to defeat these one before but I forget how.
> 
> possibly the answer is to use clang/clang++ for this item but I
> tried 
> defining CC and CXX  to clang/clang++ in the Makefile but that
> didn't 
> seem to help
> 
> there's probably a USE_CLANG option or something that I haven't seen.

We ran into the same thing recently at $work.  The root cause for us
involved having same-named classes in anonymous namespaces in different
compilation units.  The classes made reference to something that was
declared extern "C", bringing into play some rules about how C things
in anon namespaces really refer to the same global C object outside of
any namespace.  Then link-time optimization led to discarding the
object from one compilation unit, and that somehow resulted in
discarding the referenced extern "C" thing completely, even though it
was still referenced from the non-discarded instance of an object from
a different compilation unit.  Phew.

The same code has no problems with clang on freebsd 11, just with gcc
on 10.3.  

So, for us the fix was a bit heavy-handed: we just renamed one of the
classes involved in the problem so that there were no longer any same-
named classes in anon namespaces in separate compilation units.
 Probably not a good option for you.  A fix involving compile options
might result in not discarding unreferenced segments at all, and with
templated code that might result in huge binaries.

Mixing clang-compiled and gcc-compiled c++ may give you grief with
exceptions and other things (it would on ARM on 10.x, but maybe not on
x86 arches).

-- Ian

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: gettng the port revision number associated with the pkg repo. [Please?)

2017-10-03 Thread Mark Linimon 
On Tue, Oct 03, 2017 at 01:29:23AM +0800, Julian Elischer wrote:
> can we just find out who runs the poudriere instances and
> ask them to just append the svn revision number somewhere?
> or maybe even the poudriere commands  used..

http://www.freebsd.org/portmgr/ ; port...@freebsd.org

Specifically, QA Policies, although due to staleness the
page does not _specifically_ mention poudriere as the
current technology.

None of this is especially secret.

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Status of portupgrade and portmaster?

2017-10-03 Thread Garance A Drosehn 
On 29 Sep 2017, at 15:21, Marco Beishuizen wrote:

> On Fri, 29 Sep 2017, the wise Thomas Mueller wrote:
>
>> What is the current status of portupgrade and portmaster?
>>
>> I haven't used portupgrade in some time, but what about portmaster?
>
> Using portupgrade every day and still works great. Tried portmaster
> once but liked portupgrade more. I use poudriere just for testing
> ports.

FWIW, I still stick with portupgrade and am happy to continue using
it.  It works fine for my systems and the collection of ports that I
use.  Every 14-18 months some change comes up where I run into
some significant headache with my ports, and when that happens I
prefer to rebuild my entire ports collection from scratch.  I do this
in a chroot environment on that system, so I can start from scratch
and build up a full collection without disrupting anything on my
system.  Once I have successfully build a brand new collection of
ports, then I switch from my older ports-collection to the
newly-rebuilt ports-collection.

During one of those situations where my current ports-collection
was experiencing problems, I made a serious effort to try poudriere.
It did not work for me in that situation.  And based on what I went
through in that situation, I suspect it is not a good fit for my
(few) freebsd systems.  The problem is that I have only a few systems,
and they are very different.  (different major releases of FreeBSD,
different hardware architectures, or significantly different sets of
ports).  I expect that if I had *more* systems, and if those systems
were more similar, then poudriere would be a valuable tool for me.

That's my own experience.  I doubt it will convince anyone who has a
different set of requirements than I do.

-- 
Garance Alistair Drosehn= dro...@rpi.edu
Senior Systems Programmer   or   g...@freebsd.org
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

anyone know how to get rid of this error? (10.4/Gcc vs binutils port)

2017-10-03 Thread Julian Elischer 

Our 10.4 system is using gcc (for now).

when we compile the devel/binutils port, we get a failure with a bunch 
of these errors:



`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section 
`.rodata' of aarch64.o: defined in discarded section 
`.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE]' 
of aarch64.o
`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section 
`.rodata' of aarch64.o: defined in discarded section 
`.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE]' 
of aarch64.o



I managed to defeat these one before but I forget how.

possibly the answer is to use clang/clang++ for this item but I tried 
defining CC and CXX  to clang/clang++ in the Makefile but that didn't 
seem to help


there's probably a USE_CLANG option or something that I haven't seen.


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?

2017-10-03 Thread Matthew Seaman 
On 03/10/2017 12:08, Kurt Jaeger wrote:
> Hi!
> 
>> When using "poudriere", it seems ABI is freebsd:12:x86:64.
> 
> Where do you get that value from ? If I access a repo,
> I access e.g.
> 
> https://repo.opsec.eu/${ABI}
> 
> and ABI maps to
> 
> FreeBSD:12:amd64
> 

There's history here.  Originally in pkg(8) the ABI value looked like:

   freebsd:11:x86:64

then about 4 years ago the ABI value was switched to look like:

   FreeBSD:11:amd64

which is how it has remained to this day.  I believe the motivation for
this change was to bring the setting into line with the arch value used
elsewhere in the system.  The old value was still available as ALTABI --
mostly implemented as a transitional thing so we didn't unnecessarily
cause too much grief by breaking loads of poudriere setups with local
repositories.  Oh, and the ALTABI value is still used internally to
pkg(8) in a few places IIRC.

The idea was that ALTABI would become redundant over time and could
eventually be deleted.  However, it seems that a new use has been found
for it to do with packaged base and managing major version upgrades, so
it will apparently be sticking around for the foreseeable future.

Cheers,

Matthew
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?

2017-10-03 Thread O. Hartmann 
Am Tue, 3 Oct 2017 13:08:53 +0200
Kurt Jaeger  schrieb:

> Hi!
> 
> > When using "poudriere", it seems ABI is freebsd:12:x86:64.  

As I wrote: poudriere repo.

> 
> Where do you get that value from ? If I access a repo,
> I access e.g.
> 
> https://repo.opsec.eu/${ABI}
> 
> and ABI maps to
> 
> FreeBSD:12:amd64
> 



-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpQhS4dABbPJ.pgp
Description: OpenPGP digital signature

Re: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?

2017-10-03 Thread Kurt Jaeger 
Hi!

> When using "poudriere", it seems ABI is freebsd:12:x86:64.

Where do you get that value from ? If I access a repo,
I access e.g.

https://repo.opsec.eu/${ABI}

and ABI maps to

FreeBSD:12:amd64

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?

2017-10-03 Thread Jeffrey Bouquet 


On Tue, 3 Oct 2017 10:51:24 +0200, "O. Hartmann"  wrote:

> When using "poudriere", it seems ABI is freebsd:12:x86:64. When using FreeBSD 
> base, it
> seems always to be referred to FreeBSD:12:amd64. What now? All non-BSD world 
> uses x86:64,
> FreeBSD is using amd64, but why is this used inconsistently all over the 
> places?
> 
> I run into trouble setting up some package- and base-servers and ran into the 
> problem
> when deleting - not thinking of this discovered inconsistency - some links on 
> the servers
> regarding FreeBSD:12:x86:64 (the same is for 11-STABLE).
> 
> Can someone shed some light onto this? 
> 
> What am I supposed to use now? The handbook referes to amd64, so I thought 
> poudriere
> would, too. 
> 
> Thanks in advance,
> 
> oh
> -- 
> O. Hartmann
> 
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


[ not using poudriere yet ]
/me too
I think three places [ etc/pkg, /usr/local/etc/pkg/repos, 2nd place in base, ]
  fourth:  hard coded DESPITE the above in the current DB in var/db/pkg?
  fifth: derived somehow from uname -a?

here: freebsd:12:x86:32
... when this issue resolved, could it please be added to 'man 
pkg|poudriere|syntch|portmaster?|portupgrade?  [ the latter two when developed 
further ]'
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FireFox memory usage

2017-10-03 Thread Jan Beich 
Kurt Jaeger  writes:

> Hi!
>
>> Since a few days my 4GiB desktop is crawling due to swap usage and 
>> looking at top, I see FireFox using almost 7GiB of RAM (SIZE column), 
>> 2.5 of which are "RES".
>
> Firefox memory usage grows without bounds, depending on the
> websites you visit. I do not close my browser, it sometimes
> runs for several months. It can easily consume 5-7 GB with
> approx. 50 open browser windows.

Maybe check if Firefox 57 (see bug 222693) improves memory usage to rule
out legacy extensions with layers of e10s compatibility shims.

> That's an issue the mozilla foundation should work on...

Neither Mozilla Foundation nor FreeBSD Foundation directly support
Firefox on FreeBSD. However, even with only volunteers things get fixed
sometimes as long as someone files a bug.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD ports you maintain which are out of date

2017-10-03 Thread portscout 
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
devel/aws-sdk-cpp   | 1.2.5   | 1.2.6
+-+
lang/kawa   | 2.4 | 3.0
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?

2017-10-03 Thread O. Hartmann 
When using "poudriere", it seems ABI is freebsd:12:x86:64. When using FreeBSD 
base, it
seems always to be referred to FreeBSD:12:amd64. What now? All non-BSD world 
uses x86:64,
FreeBSD is using amd64, but why is this used inconsistently all over the places?

I run into trouble setting up some package- and base-servers and ran into the 
problem
when deleting - not thinking of this discovered inconsistency - some links on 
the servers
regarding FreeBSD:12:x86:64 (the same is for 11-STABLE).

Can someone shed some light onto this? 

What am I supposed to use now? The handbook referes to amd64, so I thought 
poudriere
would, too. 

Thanks in advance,

oh
-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpY8GiKbV9ge.pgp
Description: OpenPGP digital signature

Re: NextCloud 12.03 is Released - when it will be added to freshports ?

2017-10-03 Thread Kurt Jaeger 
Hi!

> Hello Everyone, I wonder what is the procedure to find out whether anyone
> is working on getting Nextcloud 12.03 in freshports..

Look at bugs.freebsd.org and search for nextcloud.

You will find

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222738

and now we wait for maintainer approval.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

NextCloud 12.03 is Released - when it will be added to freshports ?

2017-10-03 Thread Acu Ilie Dorin 
Hello Everyone, I wonder what is the procedure to find out whether anyone
is working on getting Nextcloud 12.03 in freshports..
It see that a lot of bugs were fixed...
.
https://github.com/nextcloud/server/pulls?page=1=is%3Apr+milestone%3A%22Nextcloud+12.0.3%22+is%3Aclosed

And the repos for 12.03 are available
https://download.nextcloud.com/server/prereleases/
https://nextcloud.com/install/#instructions-server

Thank you.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Status of portupgrade and portmaster?

2017-10-03 Thread Matthew Seaman 
On 02/10/2017 19:58, Marco Beishuizen wrote:
> On Mon, 2 Oct 2017, the wise Matt Smith wrote:
> 
>>> I'm running 11.1-STABLE now, upgrading every few months or when there
>>> is an important security fix. Do I have to build a new system twice
>>> in that case (once my running system and once the poudriere jail)?
>>>
>>
>> What I do is to initially create the jail using poudriere jail -c -j
>> 11 -m src=/usr/src and then I upgrade the jail using poudriere jail -u
>> -j 11.
>>
>> These commands use the existing /usr/src and /usr/obj trees from the
>> host system buildworld/kernel. It doesn't need to be rebuilt.
> 
> Did a make cleanworld last time I upgraded so /usr/obj is empty now, but
> next time I'll try this out. Didn't know poudriere could do this
> (although it's in the manpage I see now). Thanks for the info!

Even so, so long as your host system and your poudriere jail are ABI
compatible, then you *don't* need to upgrade your pourdiere jail in
lock-step with your host.  The poudriere jail only needs to be binary
compatible -- ie. the same major version of FreeBSD -- and not newer
than the host system.  Even the reason for having the same major version
is just so that the packages you build will run where you want to deploy
them -- you can run a jail of an earlier major version if you have older
systems to support, or you can run an i386 jail on an amd64 server if
you have 32bit machines to support.

Not upgrading your poudriere jail has one big advantage -- as soon as
you update the jail, poudriere will rebuild /all/ of your packages.
Avoiding updating the jail means you can just carry on doing incremental
updates and save some CPU cycles.

Cheers,

Matthew



signature.asc
Description: OpenPGP digital signature