19:34 < Betelgeuse> Anyone seeing 600 permissions popping up in the
build target?
19:38 < tmarble> note that the import JDK (i.e. with the plugs) does not
have execute permission (it's intended only for building)
19:40 < Betelgeuse> tmarble: I don't use that. Remember the no GUI rule?
19:40 < Betel
Petteri Räty kirjoitti:
> 19:44 < Betelgeuse> tmarble: nichoj hit the issue so I hope he will be
> able to provide meaningful info
20:08 <@nichoj_work> # find -name libjli.so -exec ls -l {} \;
20:08 <@nichoj_work> -rwxr-xr-x 1 portage portage 19410 May 22 11:59
./build
Regards,
Petteri
--
Gentoo/Java project lead
ccache looks at gcc command line and bases the cache on that so we
need to keep it static. See HOW IT WORKS in
http://ccache.samba.org/ccache-man.html
Index: README-builds.html
===
--- READ
Kelly O'Hair kirjoitti:
> Good catch on the ccache issue.
>
> But if you set the build number, the full version information will not tell
> you when the private openjdk was built (via java -version).
> Sometimes that is really handy to know.
>
> I assume the issue is the macro FULL_VERSION being
All other parts of the JDK link libstdc++ statically so it's weird that
libdeploy (from that I understand java web start and plugin related
stuff and as such still closed source) links it dynamically. This means
that our packages need to depend on the the old version of libstdc++.
[EMAIL PROTECTED
Attached is the output of grep -E "\\\$(XConsortium|XFree86)" -l *
I am in the process of trying to build with these files deleted so let's
see how it goes but any way it's a bit awkward that the directory has
Sun written stuff and external files mixed together. Maybe the external
files should be i
Linking vm...
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: creating a DT_TEXTREL in object.
{ \
echo Linking launcher...; \
\
gcc -m32 -march=i586 -Xlinker -O1 -m32 -march=i586
-export-dynamic -L `pwd` -o gamma launcher.o
Nikolay Igotti kirjoitti:
> I already fixed and integrated this bug: 6567018: Hotspot build fails
> with gcc4
> so you should see it in the next push.
>
> Nikolay.
>
Testing the patch from the bug report.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Phil Race kirjoitti:
> Some of those are .c files, not header files.
> You may also want to see how any of these files differ in any significant
> way from the ones on your system. I think at least a couple of them are
> modified.
>
> -phil
>
Yep I never talked about headers exclusively. My poin
Petteri Räty kirjoitti:
> Phil Race kirjoitti:
>> Some of those are .c files, not header files.
>> You may also want to see how any of these files differ in any significant
>> way from the ones on your system. I think at least a couple of them are
>> modified.
>
Kelly O'Hair kirjoitti:
> Most javac compiles in the OpenJDK build use the @ option and the java
> filelists are in a separate file, so the command line length should
> not be a problem. And I've never seen it a problem on any Linux
> or Solaris system I've used, ever, just Windows has had this iss
Petteri Räty kirjoitti:
> All other parts of the JDK link libstdc++ statically so it's weird that
> libdeploy (from that I understand java web start and plugin related
> stuff and as such still closed source) links it dynamically. This means
> that our packages need to depe
Kelly O'Hair kirjoitti:
>
> I am not seeing this dependency on our jdk7 build images from older
> Linux releases.
>
> I suspect that the Makefile logic that triggers static links might be
> broken for some Linux systems, or more likely for gcc 4. But I'd need
> more information about the system.
Kelly O'Hair kirjoitti:
> Wait a minute, where did you get libdeploy.so?
>
> It's not part of the OpenJDK, at least not yet, and not that I'm aware of.
>
> -kto
>
>
Nope. It's from the proprietary binary builds but this mailing list
seemed the best place to ask about it as there could be a val
Kelly O'Hair kirjoitti:
>
> With the new sparse binary plug bundles, the build options will be
> slightly different.
>
Great that they are smaller but still useless for ebuilds as they are
GUI. Seems someone wrote a hack around that
https://bugs.gentoo.org/show_bug.cgi?id=190148 . What does Sun
Kelly O'Hair kirjoitti:
> Humm.. well it's not like it was that hard to figure out, but anyone
> using this has effectively accepted the license... ;^)
>
> I'll file an RFE to see if we could make the binary plug unbundling
> GUI-less and potentially something that could be automated.
> Can't pro
16 matches
Mail list logo
