On 1 September 2015 at 17:10, Sevan / Venture37 wrote:
> Without disabling openmp support you should find that libgomp is a
> dependency for the version of msgfmt from devel/gettext-tools when
> using the native version of GCC, on r151014 it's GCC 4.81.
Using
ldd ~/pkg/bin/msgfmt
In my case.
Hi Richard,
On 1 September 2015 at 16:01, Richard PALO wrote:
> Unfortunately I don't feel this change is correct, even though it may help
> your builds
> and seem not really important...
>
> There is still an fishy problem in your config, and I certainly don't see
> this issue after a proper b
Le 01/09/15 15:45, Sevan / Venture37 a écrit :
>
>
> On 1 September 2015 at 12:02, Sevan / Venture37
> wrote:
>> Hopefully, the necessary change will be in soon to make it in for the
>> 2015Q3 pkgsrc release next month. I'll post an update if anything happens.
>
> The change is in, we disable
> On Sep 1, 2015, at 9:45 AM, Sevan / Venture37 wrote:
>
>
> 2015Q3 should be a great release for pkgsrc on OmniOS, with more than
> 13300 packages building natively on r151014 for those that choose to
> build their own :)
> http://mail-index.netbsd.org/pkgsrc-bulk/2015/08/29/msg011956.html
Th
On 1 September 2015 at 12:02, Sevan / Venture37 wrote:
> Hopefully, the necessary change will be in soon to make it in for the
> 2015Q3 pkgsrc release next month. I'll post an update if anything happens.
The change is in, we disable the use of openmp libraries in gettext by
default now.
http://
> On 27 July 2015 at 15:26, Dan McDonald wrote:
>> Where is libgomp pulled from in gettext? I checked all the
>> binaries from the gnu-gettext package, and none seek libgomp,
>> unless they do so by ldload().
I managed to look into this again over the bank holiday.
It turns out the issue is act
> On Jul 25, 2015, at 11:30 AM, Sevan / Venture37 wrote:
>
>
> The temporary workaround that I made to my system, just to get over
> the hurdle with gettext was to add the GCC lib directory to the ld
> search path.
>
> on r151014:
>
> $ crle
>
> Configuration file [version 4]: /var/ld/ld.con
On 19 July 2015 at 20:02, Dan McDonald wrote:
> I'd like to know (again if you'd already mentioned it) the precise nature of
> your workaround that allow more pkgsrc to be built. You can, of course, just
> express it as a pull-request to omnios-build too, if you wish.
Appologies for the late r
On 14 July 2015 at 02:14, Dan McDonald wrote:
>
>> On Jul 13, 2015, at 5:11 PM, Sevan / Venture37 wrote:
>>
>> Where can I get the release number (the r151014) from the system? (I'm
>> currently unable to reach the OmniOS zone I'm using to check for
>> myself)
>
> /etc/release. (Yes, this even w
> On Jul 18, 2015, at 8:02 AM, Sevan / Venture37 wrote:
>
>>
>> Weird... as I don't see any changes in the libc callers:
>>
>> bloody(~/ws)[0]% diff -r illumos-{gate,joyent}/usr/src/lib/libc/port/i18n/
>> bloody(~/ws)[0]% diff -r illumos-{omnios,joyent}/usr/src/lib/libc/port/i18n/
>> bloody(~/
Hi,
On 14 July 2015 at 02:14, Dan McDonald wrote:
> /etc/release. (Yes, this even works in zones.)
I sent another diff for review using
/usr/bin/awk '{ if (!seen) { print $$3; seen=1 } }' /etc/release
to pull the release info out.
Unfortunately I didn't restart my build which was in progress so
> On Jul 13, 2015, at 5:11 PM, Sevan / Venture37 wrote:
>
> Where can I get the release number (the r151014) from the system? (I'm
> currently unable to reach the OmniOS zone I'm using to check for
> myself)
/etc/release. (Yes, this even works in zones.)
>> Is there anything we can fix to hel
On Mon, 13 Jul 2015 22:11:05 +0100
"Sevan / Venture37" wrote:
>
> This was only recently implemented at pkgsrcCon and pending review so
> it's not something that's in the pkgsrc tree yet, previously it was
> just marked as Solaris 11 and I was manually adding illumos version
> info manually whic
Hi Dan,
On 13 July 2015 at 05:51, Dan McDonald wrote:
>
>
> I also saw you mention this indirectly on twitter.
>
> Generally, the OmniOS release should mention which release. 170cea2 is
> r151014. It's good to mention that alongside the uname as that's how most of
> us lock in on a release.
I also saw you mention this indirectly on twitter.
Generally, the OmniOS release should mention which release. 170cea2 is
r151014. It's good to mention that alongside the uname as that's how most of
us lock in on a release.
Is there anything we can fix to help these move along?
Also, you A
System ld.cache was modified to add the GCC lib directory in search
path with crle(1)
This resolved the previous breakage with the gettext installed from
the OmniOS IPS repo and allowed us to progress. Unfortunately, it
looks like there was a permission issue with /var/tmp on the zone I
was using t
System ld.cache was modified to add the GCC lib directory in search
path with crle(1) prior to attempting this bulkbuild.
This resolved the previous breakage with the gettext installed from
the OmniOS IPS repo and allowed us to progress.
pkgsrc bulk build report
OmniOS 17
17 matches
Mail list logo
