Build C executable with env variables via Makefile [closed]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












I have huge application written in C and Python. I have a Makefile which helps to build final executable on several platforms. Here's a main part (I can't expose too much because of confidential info):



PLATFORM := $(shell uname -r)
MATCH = $(filter $(PLATFORM),$(PLATFORM_1) $(PLATFORM_2))
ifneq ($(MATCH),)
PYTHON := $(shell which python2.6 || which python)
MAIN_PYSRC = <path_to_main_python_script>
... # setting few more variables

else
PYTHON := $(shell which python2.7 || which python)
MAIN_PYSRC = <path_to_main_python_script>
... # setting few more variables

endif

all: build

build:
@gcc -g -02 -Wall -DPYTHON="$PYTHON" -DPYTHON_EGG_CACHE="/tmp/.python-eggs -DMAIN_PYSRC="$MAIN_PYSRC" ... # few more variables


When I execute "gmake all" it works perfectly on any platform.
But the problem occurs when I build package for FreeBSD 7.3 (all others platform work perfectly), put it on internal repository and install it with command:



sudo pkg_add -r <secret_internal_repo>/<secret_app>.tbz


In logs of building package I can find that it executed build in Makefile successfully.
But when I run executable it raises an error with bad permissions for python eggs, i.e. it tries to locate it in my $HOME directory instead of /tmp/.python-eggs



Then I execute



sudo gmake clean
sudo gmake all


And it again runs perfectly!
To check if it is compiled with other variables, I tried to change for example, path "MAIN_PYSRC" and it doesn't start at all, because can't find python script. So, I believe it should be ok with that compile string.



I know, it's hard to help when I can't share too much info, but maybe you have an idea, at least, what's the root of problem.



UPDATE #1. In old docs I found that it should run by specific user on FreeBSD 7.3 (something with permissions). Anyway it removes this limitation after I perform "gmake clean, gmake all" after installation.
I think, we can close this question due to partial solution is found.










share|improve this question















closed as off-topic by Rui F Ribeiro, RalfFriedl, Sergius, Kiwy, sourcejedi Sep 11 at 18:15


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Kiwy, sourcejedi
If this question can be reworded to fit the rules in the help center, please edit the question.












  • Can you make a small test example that duplicates this issue and which you can post in full?
    – Cupcake Protocol
    Sep 10 at 19:04










  • Unfortunately, I don't know what to share so I can provide more info and not expose confidential info. I'll try to investigate a bit more.
    – Sergius
    Sep 11 at 8:20














up vote
1
down vote

favorite












I have huge application written in C and Python. I have a Makefile which helps to build final executable on several platforms. Here's a main part (I can't expose too much because of confidential info):



PLATFORM := $(shell uname -r)
MATCH = $(filter $(PLATFORM),$(PLATFORM_1) $(PLATFORM_2))
ifneq ($(MATCH),)
PYTHON := $(shell which python2.6 || which python)
MAIN_PYSRC = <path_to_main_python_script>
... # setting few more variables

else
PYTHON := $(shell which python2.7 || which python)
MAIN_PYSRC = <path_to_main_python_script>
... # setting few more variables

endif

all: build

build:
@gcc -g -02 -Wall -DPYTHON="$PYTHON" -DPYTHON_EGG_CACHE="/tmp/.python-eggs -DMAIN_PYSRC="$MAIN_PYSRC" ... # few more variables


When I execute "gmake all" it works perfectly on any platform.
But the problem occurs when I build package for FreeBSD 7.3 (all others platform work perfectly), put it on internal repository and install it with command:



sudo pkg_add -r <secret_internal_repo>/<secret_app>.tbz


In logs of building package I can find that it executed build in Makefile successfully.
But when I run executable it raises an error with bad permissions for python eggs, i.e. it tries to locate it in my $HOME directory instead of /tmp/.python-eggs



Then I execute



sudo gmake clean
sudo gmake all


And it again runs perfectly!
To check if it is compiled with other variables, I tried to change for example, path "MAIN_PYSRC" and it doesn't start at all, because can't find python script. So, I believe it should be ok with that compile string.



I know, it's hard to help when I can't share too much info, but maybe you have an idea, at least, what's the root of problem.



UPDATE #1. In old docs I found that it should run by specific user on FreeBSD 7.3 (something with permissions). Anyway it removes this limitation after I perform "gmake clean, gmake all" after installation.
I think, we can close this question due to partial solution is found.










share|improve this question















closed as off-topic by Rui F Ribeiro, RalfFriedl, Sergius, Kiwy, sourcejedi Sep 11 at 18:15


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Kiwy, sourcejedi
If this question can be reworded to fit the rules in the help center, please edit the question.












  • Can you make a small test example that duplicates this issue and which you can post in full?
    – Cupcake Protocol
    Sep 10 at 19:04










  • Unfortunately, I don't know what to share so I can provide more info and not expose confidential info. I'll try to investigate a bit more.
    – Sergius
    Sep 11 at 8:20












up vote
1
down vote

favorite









up vote
1
down vote

favorite











I have huge application written in C and Python. I have a Makefile which helps to build final executable on several platforms. Here's a main part (I can't expose too much because of confidential info):



PLATFORM := $(shell uname -r)
MATCH = $(filter $(PLATFORM),$(PLATFORM_1) $(PLATFORM_2))
ifneq ($(MATCH),)
PYTHON := $(shell which python2.6 || which python)
MAIN_PYSRC = <path_to_main_python_script>
... # setting few more variables

else
PYTHON := $(shell which python2.7 || which python)
MAIN_PYSRC = <path_to_main_python_script>
... # setting few more variables

endif

all: build

build:
@gcc -g -02 -Wall -DPYTHON="$PYTHON" -DPYTHON_EGG_CACHE="/tmp/.python-eggs -DMAIN_PYSRC="$MAIN_PYSRC" ... # few more variables


When I execute "gmake all" it works perfectly on any platform.
But the problem occurs when I build package for FreeBSD 7.3 (all others platform work perfectly), put it on internal repository and install it with command:



sudo pkg_add -r <secret_internal_repo>/<secret_app>.tbz


In logs of building package I can find that it executed build in Makefile successfully.
But when I run executable it raises an error with bad permissions for python eggs, i.e. it tries to locate it in my $HOME directory instead of /tmp/.python-eggs



Then I execute



sudo gmake clean
sudo gmake all


And it again runs perfectly!
To check if it is compiled with other variables, I tried to change for example, path "MAIN_PYSRC" and it doesn't start at all, because can't find python script. So, I believe it should be ok with that compile string.



I know, it's hard to help when I can't share too much info, but maybe you have an idea, at least, what's the root of problem.



UPDATE #1. In old docs I found that it should run by specific user on FreeBSD 7.3 (something with permissions). Anyway it removes this limitation after I perform "gmake clean, gmake all" after installation.
I think, we can close this question due to partial solution is found.










share|improve this question















I have huge application written in C and Python. I have a Makefile which helps to build final executable on several platforms. Here's a main part (I can't expose too much because of confidential info):



PLATFORM := $(shell uname -r)
MATCH = $(filter $(PLATFORM),$(PLATFORM_1) $(PLATFORM_2))
ifneq ($(MATCH),)
PYTHON := $(shell which python2.6 || which python)
MAIN_PYSRC = <path_to_main_python_script>
... # setting few more variables

else
PYTHON := $(shell which python2.7 || which python)
MAIN_PYSRC = <path_to_main_python_script>
... # setting few more variables

endif

all: build

build:
@gcc -g -02 -Wall -DPYTHON="$PYTHON" -DPYTHON_EGG_CACHE="/tmp/.python-eggs -DMAIN_PYSRC="$MAIN_PYSRC" ... # few more variables


When I execute "gmake all" it works perfectly on any platform.
But the problem occurs when I build package for FreeBSD 7.3 (all others platform work perfectly), put it on internal repository and install it with command:



sudo pkg_add -r <secret_internal_repo>/<secret_app>.tbz


In logs of building package I can find that it executed build in Makefile successfully.
But when I run executable it raises an error with bad permissions for python eggs, i.e. it tries to locate it in my $HOME directory instead of /tmp/.python-eggs



Then I execute



sudo gmake clean
sudo gmake all


And it again runs perfectly!
To check if it is compiled with other variables, I tried to change for example, path "MAIN_PYSRC" and it doesn't start at all, because can't find python script. So, I believe it should be ok with that compile string.



I know, it's hard to help when I can't share too much info, but maybe you have an idea, at least, what's the root of problem.



UPDATE #1. In old docs I found that it should run by specific user on FreeBSD 7.3 (something with permissions). Anyway it removes this limitation after I perform "gmake clean, gmake all" after installation.
I think, we can close this question due to partial solution is found.







python freebsd make c






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Sep 11 at 11:00

























asked Sep 10 at 18:14









Sergius

4091311




4091311




closed as off-topic by Rui F Ribeiro, RalfFriedl, Sergius, Kiwy, sourcejedi Sep 11 at 18:15


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Kiwy, sourcejedi
If this question can be reworded to fit the rules in the help center, please edit the question.




closed as off-topic by Rui F Ribeiro, RalfFriedl, Sergius, Kiwy, sourcejedi Sep 11 at 18:15


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Kiwy, sourcejedi
If this question can be reworded to fit the rules in the help center, please edit the question.











  • Can you make a small test example that duplicates this issue and which you can post in full?
    – Cupcake Protocol
    Sep 10 at 19:04










  • Unfortunately, I don't know what to share so I can provide more info and not expose confidential info. I'll try to investigate a bit more.
    – Sergius
    Sep 11 at 8:20
















  • Can you make a small test example that duplicates this issue and which you can post in full?
    – Cupcake Protocol
    Sep 10 at 19:04










  • Unfortunately, I don't know what to share so I can provide more info and not expose confidential info. I'll try to investigate a bit more.
    – Sergius
    Sep 11 at 8:20















Can you make a small test example that duplicates this issue and which you can post in full?
– Cupcake Protocol
Sep 10 at 19:04




Can you make a small test example that duplicates this issue and which you can post in full?
– Cupcake Protocol
Sep 10 at 19:04












Unfortunately, I don't know what to share so I can provide more info and not expose confidential info. I'll try to investigate a bit more.
– Sergius
Sep 11 at 8:20




Unfortunately, I don't know what to share so I can provide more info and not expose confidential info. I'll try to investigate a bit more.
– Sergius
Sep 11 at 8:20















active

oldest

votes






















active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes

Popular posts from this blog

Peggy Mitchell

Albert Einstein

Kuomintang