On 2011-06-01 20:54, Roman Chyla wrote:
>Note that the
> location of the java that was used for the project built will be
> hardcoded inside the dynamic library, but I plan to change the header
> and set a few standard paths there.
This is actually worse than I thought: not only the java location seems
hardcoded in the shared object as a hard path to the libs folder, but
also there is an implied dep on setuptools via pkg_resources
So for now, you cannot even build on a jdk and deploy on a jre.

--
Cordially
Philippe

philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com
http://eclipse.org/atf - http://eclipse.org/soc - http://eclipse.org/vep
http://drools.org/ - http://easyeclipse.org - http://phpeclipse.com

On Jun 2, 2011, at 3:10, Philippe Ombredanne <[EMAIL PROTECTED]> wrote:

> On 2011-06-01 20:54, Roman Chyla wrote:
>> Note that the
>> location of the java that was used for the project built will be
>> hardcoded inside the dynamic library, but I plan to change the header
>> and set a few standard paths there.
> This is actually worse than I thought: not only the java location seems hardcoded in the shared object as a hard path to the libs folder, but also there is an implied dep on setuptools via pkg_resources
> So for now, you cannot even build on a jdk and deploy on a jre.

If the solution to this is to remove the hardcoded paths and expect the dynamic linker to find the dependencies via some environment variable like LD_LIBRARY_PATH you'd be creating a security vulnerability.
This is how I did it originally (years ago) and people complained about it so I switched to hardcoded paths for shared library dependencies wherever possible.

Andi..

>
> --
> Cordially
> Philippe
>
> philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
> nexB - Open by Design (tm) - http://www.nexb.com
> http://eclipse.org/atf - http://eclipse.org/soc - http://eclipse.org/vep
> http://drools.org/ - http://easyeclipse.org - http://phpeclipse.com

Andi Vajda <[EMAIL PROTECTED]> wrote:

> If the solution to this is to remove the hardcoded paths and expect
> the dynamic linker to find the dependencies via some environment
> variable like LD_LIBRARY_PATH you'd be creating a security
> vulnerability.

> This is how I did it originally (years ago) and people complained
> about it so I switched to hardcoded paths for shared library
> dependencies wherever possible.

Which I for one appreciate!

Bill

On Thu, Jun 2, 2011 at 12:26 PM, Andi Vajda <[EMAIL PROTECTED]> wrote:
>
> On Jun 2, 2011, at 3:10, Philippe Ombredanne <[EMAIL PROTECTED]> wrote:
>
>> On 2011-06-01 20:54, Roman Chyla wrote:
>>> Note that the
>>> location of the java that was used for the project built will be
>>> hardcoded inside the dynamic library, but I plan to change the header
>>> and set a few standard paths there.
>> This is actually worse than I thought: not only the java location seems hardcoded in the shared object as a hard path to the libs folder, but also there is an implied dep on setuptools via pkg_resources
>> So for now, you cannot even build on a jdk and deploy on a jre.
>
> If the solution to this is to remove the hardcoded paths and expect the dynamic linker to find the dependencies via some environment variable like LD_LIBRARY_PATH you'd be creating a security vulnerability.

I am not an expert on this, but i remember that LD_LIBRARY_PATH was
not recommended (as it could break other libraries, if i remember
well). So that's why I thought more about a 'more, standard' hardcoded
locations. Or is there something else besides LD_LIBRARY_PATH and
multiple hardcoded paths?

Roman

> This is how I did it originally (years ago) and people complained about it so I switched to hardcoded paths for shared library dependencies wherever possible.
>
> Andi..
>
>>
>> --
>> Cordially
>> Philippe
>>
>> philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
>> nexB - Open by Design (tm) - http://www.nexb.com
>> http://eclipse.org/atf - http://eclipse.org/soc - http://eclipse.org/vep
>> http://drools.org/ - http://easyeclipse.org - http://phpeclipse.com
>

On Thu, Jun 2, 2011 at 6:10 AM, Philippe Ombredanne
<[EMAIL PROTECTED]> wrote:
> On 2011-06-01 20:54, Roman Chyla wrote:
>>
>> Note that the
>> location of the java that was used for the project built will be
>> hardcoded inside the dynamic library, but I plan to change the header
>> and set a few standard paths there.
>
> This is actually worse than I thought: not only the java location seems
> hardcoded in the shared object as a hard path to the libs folder, but also
> there is an implied dep on setuptools via pkg_resources
> So for now, you cannot even build on a jdk and deploy on a jre.

I am sorry, but I don't understand - what is the additional dependency
hardcoded there?
Thanks,

Roman

>
> --
> Cordially
> Philippe
>
> philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
> nexB - Open by Design (tm) - http://www.nexb.com
> http://eclipse.org/atf - http://eclipse.org/soc - http://eclipse.org/vep
> http://drools.org/ - http://easyeclipse.org - http://phpeclipse.com
>

On Thu, 2 Jun 2011, Roman Chyla wrote:

> On Thu, Jun 2, 2011 at 12:26 PM, Andi Vajda <[EMAIL PROTECTED]> wrote:
>>
>> On Jun 2, 2011, at 3:10, Philippe Ombredanne <[EMAIL PROTECTED]> wrote:
>>
>>> On 2011-06-01 20:54, Roman Chyla wrote:
>>>> Note that the
>>>> location of the java that was used for the project built will be
>>>> hardcoded inside the dynamic library, but I plan to change the header
>>>> and set a few standard paths there.
>>> This is actually worse than I thought: not only the java location seems hardcoded in the shared object as a hard path to the libs folder, but also there is an implied dep on setuptools via pkg_resources
>>> So for now, you cannot even build on a jdk and deploy on a jre.
>>
>> If the solution to this is to remove the hardcoded paths and expect the dynamic linker to find the dependencies via some environment variable like LD_LIBRARY_PATH you'd be creating a security vulnerability.
>
> I am not an expert on this, but i remember that LD_LIBRARY_PATH was
> not recommended (as it could break other libraries, if i remember
> well). So that's why I thought more about a 'more, standard' hardcoded
> locations. Or is there something else besides LD_LIBRARY_PATH and
> multiple hardcoded paths?

Each Linux distribution has its own notion of "more standard" locations for
java libraries. And then there are different java libraries for different
java distributions too.

Andi..

>
> Roman
>
>> This is how I did it originally (years ago) and people complained about it so I switched to hardcoded paths for shared library dependencies wherever possible.
>>
>> Andi..
>>
>>>
>>> --
>>> Cordially
>>> Philippe
>>>
>>> philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
>>> nexB - Open by Design (tm) - http://www.nexb.com
>>> http://eclipse.org/atf - http://eclipse.org/soc - http://eclipse.org/vep
>>> http://drools.org/ - http://easyeclipse.org - http://phpeclipse.com
>>
>

On 2011-06-02 18:26, Andi Vajda wrote:
> On Jun 2, 2011, at 3:10, Philippe Ombredanne<[EMAIL PROTECTED]>  wrote:
>> On 2011-06-01 20:54, Roman Chyla wrote:
>>> Note that the
>>> location of the java that was used for the project built will be
>>> hardcoded inside the dynamic library, but I plan to change the header
>>> and set a few standard paths there.
>> This is actually worse than I thought: not only the java location seems hardcoded in the shared object as a hard path to the libs folder, but also there is an implied dep on setuptools via pkg_resources
>> So for now, you cannot even build on a jdk and deploy on a jre.
> If the solution to this is to remove the hardcoded paths and expect the dynamic linker to find the dependencies via some environment variable like LD_LIBRARY_PATH you'd be creating a security vulnerability.
> This is how I did it originally (years ago) and people complained about it so I switched to hardcoded paths for shared library dependencies wherever possible.
Andi:
could we come at least with a build option to enable this?
I am sure there are bad ways and correct ways to address possible
security issues as there are many packages that rely on this.
And given the variety of *nix locations for a JVM and the various JVMs
available we need some flexibility there imho.
Leave it hardcoded by default allright and a bbuild flag to get it
working otherwise if ones wants to build it this way?

--
Cordially
Philippe

philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com
http://eclipse.org/atf - http://eclipse.org/soc - http://eclipse.org/vep
http://drools.org/ - http://easyeclipse.org - http://phpeclipse.com

 Hi Philippe,

On Jun 4, 2011, at 9:42, Philippe Ombredanne <[EMAIL PROTECTED]> wrote:

> On 2011-06-02 18:26, Andi Vajda wrote:
>> On Jun 2, 2011, at 3:10, Philippe Ombredanne<[EMAIL PROTECTED]>  wrote:
>>> On 2011-06-01 20:54, Roman Chyla wrote:
>>>> Note that the
>>>> location of the java that was used for the project built will be
>>>> hardcoded inside the dynamic library, but I plan to change the header
>>>> and set a few standard paths there.
>>> This is actually worse than I thought: not only the java location seems hardcoded in the shared object as a hard path to the libs folder, but also there is an implied dep on setuptools via pkg_resources
>>> So for now, you cannot even build on a jdk and deploy on a jre.
>> If the solution to this is to remove the hardcoded paths and expect the dynamic linker to find the dependencies via some environment variable like LD_LIBRARY_PATH you'd be creating a security vulnerability.
>> This is how I did it originally (years ago) and people complained about it so I switched to hardcoded paths for shared library dependencies wherever possible.
> Andi:
> could we come at least with a build option to enable this?

The option already exists: when building jcc, you can pass it your own version of JCC_LFLAGS set as an env variable that overrides the defaults to whatever you like (see jcc's setup.py for more details).

> I am sure there are bad ways and correct ways to address possible security issues as there are many packages that rely on this.
> And given the variety of *nix locations for a JVM and the various JVMs available we need some flexibility there imho.
> Leave it hardcoded by default allright and a bbuild flag to get it working otherwise if ones wants to build it this way?

If you are thinking of something different from the existing solution, patches are welcome. Maybe, all it needs is better documentation ?

Thanks !

Andi..

>
> --
> Cordially
> Philippe
>
> philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
> nexB - Open by Design (tm) - http://www.nexb.com
> http://eclipse.org/atf - http://eclipse.org/soc - http://eclipse.org/vep
> http://drools.org/ - http://easyeclipse.org - http://phpeclipse.com

On 2011-06-04 19:29, Andi Vajda wrote:
>>>> On 2011-06-01 20:54, Roman Chyla wrote:
>>>>> Note that the location of the java that was used for the project built
 >>>>> will be hardcoded inside the dynamic library, but I plan to
change the
 >>>>> header and set a few standard paths there.
> On Jun 2, 2011, at 3:10, Philippe Ombredanne<[EMAIL PROTECTED]>   wrote:
>> could we come at least with a build option to enable this?

> The option already exists: when building jcc, you can pass it your own version of JCC_LFLAGS set as an env variable that overrides the defaults to whatever you like (see jcc's setup.py for more details).
> If you are thinking of something different from the existing solution, patches are welcome. Maybe, all it needs is better documentation ?

Andi:
This is perfect!
--
Cordially
Philippe

philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com
http://eclipse.org/atf - http://eclipse.org/soc - http://eclipse.org/vep
http://drools.org/ - http://easyeclipse.org - http://phpeclipse.com