Bug 488

Summary: Enable others architectures under GNU/Linux
Product: [JogAmp] Gluegen Reporter: Sylvestre Ledru <sylvestre>
Component: coreAssignee: Sven Gothel <sgothel>
Status: IN_PROGRESS ---    
Severity: enhancement CC: gouessej
Priority: P4    
Version: 2   
Hardware: All   
OS: linux   
Type: --- SCM Refs:
196c325aa3dddb0d775e8fb80e26333208fe6c7e
Workaround: ---
Bug Depends on:    
Bug Blocks: 547    
Attachments: Enable other builds under GNU.Linux
Fix bug 488

Description Sylvestre Ledru 2011-03-28 15:12:59 CEST
Created attachment 244 [details]
Enable other builds under GNU.Linux

The attached patch allows the build of gluegen 2 under the following architectures:
* ARMEL
* HPPA
* MIPS
* MIPSEL
* PPC
* S390
* SPARC 
running Debian

See for the build results:
https://buildd.debian.org/status/package.php?p=gluegen2&suite=experimental
Comment 1 Sylvestre Ledru 2011-06-21 21:27:07 CEST
Is there any changes this patch could be applied ? It would avoid future conflicts.
Comment 2 Sven Gothel 2011-07-23 02:20:42 CEST
I currently added armv7l eabi (linux/ubuntu(debian)) and android for gluegen, jogl is in progress,
see branch wip_mobile.

I will also finish crosscompilation and testing, soon.

Would be interesting how to add 'default' builds, 
i.e. w/o specific setting eg. compiler.cfg.linux instead of compiler.cfg.linux.x86, ..

Also, we should be able to confirm / test the builds somehow, shouldn't we ?
I assume you have tested your setup, ofc. 
Soon I will add the above mentioned armv7l eabi machines to our jenkins system.
Comment 3 Sven Gothel 2011-10-10 08:48:30 CEST
ARMEL / Linux works, as well as ARMEL / Android (w/ a custom config).

I don't know if you like to add the other platforms as well
and whats the status of build machines for such.

Shall we keep this bug open ?
Comment 4 Sylvestre Ledru 2011-10-10 08:56:03 CEST
Yes please. 
I updated part of my patches against the rc3. It is a long and boring work, it would be nice if you could consider the inclusion of the patch (I will send the new one in the new few days).
Comment 5 Sven Gothel 2011-10-10 19:21:35 CEST
Yes, I will merge - THANK YOU.
(Just send me a note here - hope it's not a too much intrusive change.)

Again: Whats the status of those platform's build / test machines ?
Shall we silently assume they just work ? Can you provide a URL 
where we can see (I assume) debian build / test logs ?
Or is anything like this planned ?

Shall we add the creation of debian packages to our Linux build ?
Comment 6 Sylvestre Ledru 2011-12-26 09:59:36 CET
Created attachment 308 [details]
Fix bug 488
Comment 7 Sylvestre Ledru 2011-12-26 10:00:33 CET
I lagged a bit but yeh, we are still in 2011!
  
> Again: Whats the status of those platform's build / test machines ?
> Shall we silently assume they just work ? Can you provide a URL 
> where we can see (I assume) debian build / test logs ?
https://buildd.debian.org/status/package.php?p=gluegen2&suite=experimental
there is a s390x build issue but it should be fixed when you read this comment.

Note that hurd & kfreebsd are failing because the port of the openjdk is not over yet.


For gluegen2, you can consider that it is working since it builds jogl2
https://buildd.debian.org/status/package.php?p=libjogl2-java
(the armel build issue will be fixed soon)

> Shall we add the creation of debian packages to our Linux build ?
No, it is not necessary, I am happy with a separate repository.
Comment 8 Sven Gothel 2012-01-09 17:06:37 CET
Awesome !

I guess we need to patch Platform.java as well, since it reassembles the os-and-arch.
We also need to determine on these new values other information, 
ie 32/64 bit and validate the MachineDescription (alignment, ptr-size, ..).
Comment 9 Sven Gothel 2012-01-09 17:07:26 CET
commited under your name: 196c325aa3dddb0d775e8fb80e26333208fe6c7e
Comment 10 Sven Gothel 2012-01-09 17:19:37 CET
Until issues in comment 8 are resolved we need to keep this bug 
and it's dependent 547 open ..
Comment 11 Sylvestre Ledru 2012-01-11 20:19:22 CET
You are right. I will fix that!
Comment 12 Sven Gothel 2012-02-10 11:45:23 CET
Any chance we can complete this (MachineDescriptions) ?

Sylvestre, I can also do the fix - if you would dump the *runtime* MachineDescription (MD)
here (attachment) for all the new platforms.

You can simply do that while running 'com.jogamp.common.GlueGenVersion'.
In case the compile time version doesn't match the runtime, an exception is thrown,
still showing the desired data.

Then I could extend the compile-time static build in MD table
if required, ie. the current one doesn't cover the new platforms.

By the way, the reason I am choosing the static MD to enhance runtime performance.
It is important to understand that the alignment data not only depends on the CPU 
itself, but on the compiler and compile-time flags (-pthreads, ..).

The more things develop currently (ABI change, C++11, multiple platforms),
we may consider to throw out the static MD and favor the runtime MD,
even though this may impact performance a little bit.

What do you think ?

+++

I also would like to align the ARM ARMv7 etc .. specs to remove duplication.

+++
Comment 13 Sylvestre Ledru 2012-02-11 08:49:41 CET
Sorry about the lag. I tried but I was stuck on that stuff:

    public enum CPUFamily {
        /** AMD/Intel */
        X86(    0x00000000), 
        /** ARM */
        ARM(    0x00010000),



    public enum CPUType {
        /** X86 32bit */       
        X86_32(    CPUFamily.X86,     0x0001),
        /** X86 64bit */
        X86_64(    CPUFamily.X86,     0x0002),

I don't know how to get this information ?!
Could you detailed me how you get them initially ?

thanks
Comment 14 Sylvestre Ledru 2012-03-01 00:32:00 CET
ping ?
Comment 15 Sven Gothel 2012-03-18 16:42:23 CET
Hi Sylvestre, sorry, I don't regular react in real time on email notification re bugzilla,
pls send me a private email as well in case you like a more instant response.

Reading your question in comment 13, I don't know what information you like to have.

The 'table' of os.and.arch information is arbitrary, i.e. made up by us
following our runtime/build constraints of having the same os.and.arch setup.

The runtime values are determined within Platform's static initializer
and shall match gluegen's cpptask determinations (java CPU/ARCH identifiers).

Maybe we can chat in our chatroom conference.jabber.org ?