OK, I think I found the issue here.

Mesa links multiple shaders by concatenating them together then recompiling.
When the shaders contain #version directives the extra/redundant #version lines caused a preprocessor failure.

Mesa commit b8b774c775b672c89f1f4007c7b9575052d85739 removes the extra #version directives.  I'll merge the fix to Mesa/master in a little while...

There's another issue but it's a problem with Wine.

The following vertex program is illegal:

!!ARBvp1.0
PARAM C[66] = { program.env[0..65] };
ADDRESS A0;PARAM zero = {0.0, 0.0, 0.0, 0.0};
ARL A0.x, zero.x;
MOV result.position, C[A0.x + 65];
END

The problem is the offset in "A0.x + 65" is too large.

From the GL_ARB_vertex_program specification:

"""
(26) What limits should be imposed on the constants that can be added to
or subtracted from the address register for relative addressing?  Negative
offsets are sometimes useful for shifting down in an array.

  RESOLVED:  -64 to +63 should be sufficient for the time being.  Offset
  sizes are limited to allow offsets to be baked into device-dependent
  instruction encodings.
"""

So 65 is illegal according to the GL spec, but when I tested with NVIDIA's driver, offsets up to 255 work without error.  Hmmm.

(In reply to comment #2)
> There's another issue but it's a problem with Wine.
> 
> The following vertex program is illegal:
> 
> !!ARBvp1.0
> PARAM C[66] = { program.env[0..65] };
> ADDRESS A0;PARAM zero = {0.0, 0.0, 0.0, 0.0};
> ARL A0.x, zero.x;
> MOV result.position, C[A0.x + 65];
> END
> 
> The problem is the offset in "A0.x + 65" is too large.
>
We use that during wined3d starup to detect if the GL implementation will accept offsets outside the -64 to +63 range. We try to avoid them if the implementation doesn't support them, but that's not always easily possible.

Do most other GL drivers allow a larger range of offsets?  We could easily raise them in Mesa.

(In reply to comment #4)
> Do most other GL drivers allow a larger range of offsets?  We could easily
> raise them in Mesa.
> 
Nvidia and fglrx do, I'm not completely sure about Apple.

(In reply to comment #4)
> Do most other GL drivers allow a larger range of offsets?  We could easily
> raise them in Mesa.

It looks like all the hardware we support should handle at least signed 7-bit offsets.  I'm not 100% sure about r200, though.

Perhaps we should add a ctx->Const.Vertex/FragmentProgram.MaxAddrOffset field rather than hard-code a value in the parser.

The range would be [-MaxAddrOffset-1 , MaxAddrOffset].

(In reply to comment #6)
> (In reply to comment #4)
> > Do most other GL drivers allow a larger range of offsets?  We could easily
> > raise them in Mesa.
> 
> It looks like all the hardware we support should handle at least signed 7-bit
> offsets.  I'm not 100% sure about r200, though.
> 

I did check the r200 and registers support 8bits for offset but vertex program compiler doesn't support negative values. I don't know if that is software or hardware limit.

I'm closing this bug since Brian fixed the original issue.  I've opened a new bug (bug #23975) for the enhancement to increase the range of supported relative address offsets.  I'll try to incorporate this in the next round of assembly shader work (currently on the asm-shader-rework-2 branch).

*** Bug 23960 has been marked as a duplicate of this bug. ***

(In reply to comment #8)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > Do most other GL drivers allow a larger range of offsets?  We could easily
> > > raise them in Mesa.
> > 
> > It looks like all the hardware we support should handle at least signed 7-bit
> > offsets.  I'm not 100% sure about r200, though.
> > 
> 
> I did check the r200 and registers support 8bits for offset but vertex program
> compiler doesn't support negative values. I don't know if that is software or
> hardware limit.

I'm pretty sure when I wrote that code in the r200 driver it didn't work with fglrx. I think I quickly tried negative offsets but couldn't get it to work, hence the driver emitting a warning and just using index 0... It is possible though I made some mistake.

(In reply to comment #11)
> 
> I'm pretty sure when I wrote that code in the r200 driver it didn't work with
> fglrx. I think I quickly tried negative offsets but couldn't get it to work,
> hence the driver emitting a warning and just using index 0... It is possible
> though I made some mistake.
> 

I can probably dig up the r2xx vertex specs if there is anyone interested in pursuing this.

(In reply to comment #11)
> (In reply to comment #8)
> > I did check the r200 and registers support 8bits for offset but vertex program
> > compiler doesn't support negative values. I don't know if that is software or
> > hardware limit.
> 
> I'm pretty sure when I wrote that code in the r200 driver it didn't work with
> fglrx. I think I quickly tried negative offsets but couldn't get it to work,
> hence the driver emitting a warning and just using index 0... It is possible
> though I made some mistake.

This only comes up if baseReg + offset is less than zero.  For example, if the base index of "foo" is >= 4, the following code is fine:

    MOV    R0, foo[A0.x - 4];

We could probably modify the placement algorithm in prog_parameter_layout.c to account for this.  Alex or Roland (or someone working on the r200 driver) should probably submit enhancement bugs for these issues.

Note that the r300 driver seems to have the same behavior.

(In reply to comment #5)
> (In reply to comment #4)
> > Do most other GL drivers allow a larger range of offsets?  We could easily
> > raise them in Mesa.
> > 
> Nvidia and fglrx do, I'm not completely sure about Apple.

An offset of 64 or -65 does not compile with Apple.