bugManeage - Bugs: bug #58351, Host system CFLAGS and LDFLAGS...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #58351: Host system CFLAGS and LDFLAGS should normally be avoided

Submitter:  Boud Roukema <boud>
Submitted:  Mon 11 May 2020 03:17:27 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open

Fri 15 May 2020 02:21:06 PM UTC, comment #5: 

That is a good suggestion! If its a short paragraph we can put it in the initial notice as you mentioned.

In fact I have been thinking that instead of blindly waiting for 10 seconds, we can say press 'Y' to start the build.

Once that is implemented, we can say: "for more information on the environment variables, press 'E' (or any other character!).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Fri 15 May 2020 02:28:21 AM UTC, comment #4: 

I agree that it clarifies the issue, but that shifts this to a user-friendliness bug. :)

The question is where is the obvious place, that will survive in the long-term, for informing users that they may wish to double-check the environment values of PATH, CPPFLAGS and LDFLAGS.

Maybe during the 10-second delay for the initial configure?

Or is that information overload?

Boud Roukema <boud>
Group Member
Mon 11 May 2020 08:57:02 PM UTC, comment #3: 

I just had a closer look at this problem and wanted to add something to the previous point:

The mentioned line in your Commit e4499a0ba is for Bash and as described in the previous commit, this is because we are relying on the host's C compiler and C library, so if they have special settings in their system, we need it.

But just a small correction: `CPPFLAGS' is for the `-I' options (to include headers), not CFLAGS. At the the start of basic.mk, we modify CPPFLAGS environment variable (as well as LDFLAGS and PATH and some other relevant environment variables), to first look into Maneage's installation directory, and then the host's pre-defined places:


export PATH := $(ibdir):$(PATH)
export CPPFLAGS := -I$(idir)/include $(CPPFLAGS)
export LDFLAGS := $(rpath_command) -L$(ildir) $(LDFLAGS)


In this way, as long as we don't have the necessary tools, the built programs will look in the host's tools. But as Maneage builds up its inventory of programs and libraries, they will be preferably used, not the host's.

If you think this clarifies the issue, you can close this bug ;-).

 Mohammad Akhlaghi <makhlaghi>
Group administrator
Mon 11 May 2020 04:22:48 PM UTC, comment #2: 

Indeed, in the `basic.mk' phase, we still depend on the host operating system to some level. But in `high-level.mk' and `python.mk' we don't.

After all, `basic.mk' is the step that install the necessary (what I call!) meta-software: software to build the science software.

But this will shortly change when we build the GNU C library in task #15390. I made some good progress when I started that task, but was distracted with other necessary things and couldn't finish it, but one of the things Surena is helping with us is this ;-).

Once we build our own C library, `basic.mk' will also be fully independent of the host.

 Mohammad Akhlaghi <makhlaghi>
Group administrator
Mon 11 May 2020 04:03:31 PM UTC, comment #1: 

I see that the following in configure.sh would conflict
with the possibility of totally avoiding the user
environment CFLAGS, CPPFLAGS and LDFLAGs:


2) If you have 'libc.a' and 'sys/cdefs.h', but in a non-standard location (for
example in '/PATH/TO/STATIC/LIBC/libc.a' and
'/PATH/TO/SYS/CDEFS_H/sys/cdefs.h'), please run the commands below, then
re-configure the project to fix this problem.

    $ export LDFLAGS="-L/PATH/TO/STATIC/LIBC \$LDFLAGS"
    $ export CPPFLAGS="-I/PATH/TO/SYS/CDEFS_H \$LDFLAGS"


Any systematic solution needs to handle both users following this instruction and those who have some other CFLAGS, CPPFLAGS, LDFLAGS values that could potentially conflict with maneage.

Boud Roukema <boud>
Group Member
Mon 11 May 2020 03:17:27 PM UTC, original submission:  

Commit b1e1522 introduced the line `export CFLAGS="$$CFLAGS` in
`reproduce/software/make/basic.mk`. This line picks up the host system
value of CFLAGS, if it is non-empty. CFLAGS typically has -I includes
of the user's choice of header files that are an alternative to the
system-level files, together with LDFLAGS having -L library links.
This is risky for reproducibility within a self-contained system.  In
my case I got some lines in my configure log that suggested that
maneage was using my non-maneage CFLAGS directory.
   
With commit:
https://codeberg.org/boud/maneage_dev/src/branch/avoid_user_CFLAGS_LDFLAGS

CFLAGS is removed from the `bash` section of
`reproduce/software/make/basic.mk`. I correctly see logs with compile
lines without my non-maneage directories.
   
There are still several places in `reproduce/software/make/basic.mk`
where LDFLAGS is extended from the environment value rather than
replaces the environment value.  Some of these may be needed in the
pre-autonomous stage of maneage configuration. I would suggest that
the autonomous stage phases avoid using the environment value of
LDFLAGS.

I think this qualifies as a bug rather than a task, because it could
quite likely cause the initial build to fail by a new user who
has his/her own version of a library set up with CFLAGS and LDFLAGS
values pointing to it.

Boud Roukema <boud>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by makhlaghi (Posted a comment)
  • -email is unavailable- added by boud (Submitted the item)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    No changes have been made to this item

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-f13d.
    Corresponding source code