I wrote an application that creates a cross reference to the entries within a /etc/fstab.
This application has two linked in modules as shown below. The compiler is gcc 6.2.1
Module Tumbleweed Fedora
strtrim.o 1632 1608
dictionary.o 14072 14048
The differences in sizes are acceptable. (I browsed the respective object files and the Fedora 6.2.1 appears trivially more efficient.
But the problem arises when I link them together with the program containing main.
Module Tumbleweed Fedora
fstabxref **40968 32872 **
**The tumbleweed executable size is 8k larger than the Fedora executable
What I am demonstrating with the above table is that the something is wrong, not with the compiler, but with the binding of the objects together to create the program.
By the way, the output file from the Tumbleweed and Fedora program versions are identical.
**
Wouldn’t you think that a thread like this will find other programmers looking at it when it was in the Development > Programming/Scripting forum sooner then here?
When you want me to move this there, please ask so.
Until this thread is moved (I think it should be),
You might run your app in an IDE where you can insert breakpoints
You can instrument your application to write to stdout at significant places.
Although your application might be very simple, it’s possible that there are significant differences how your app runs when compiled differently, the differences you think are insignificant may not be.
Also,
I expect the two compilers are not <exactly> identical, so switch compilers (likely just copy the compiler from one platform to the other) to see if there is any difference, particularly if your application is not <only> your source but also calls libraries from the distro.
As the OP does not seem to be very eager to see if people try to help him, I will take the decision. This will be moved to Programming/Scripting and is CLOSED for the moment.
Thank you for relocating the posting.
I have tested my gcc compiled differences with another program
-rwxrwxr-x. 1 leslie leslie 51784 Dec 24 16:38 rijndael-test-fst Fedora
-rwxr-xr-x 1 leslie leslie 55792 Dec 26 12:07 rijndael-test-fst Tumbleweed
-rw-rw-r–1 leslie leslie 27008 Dec 24 16:38 rijndael-alg-fst.o Fedora
-rw-r–r-- 1 leslie leslie 27032 Dec 26 12:07 rijndael-alg-fst.o Tumbleweed
Given the past week, the announcement of a more recent gcc compiler package, perhaps it would be great if that package was made available as a pre-tumbleweed test version.
The compiler itself is producing code that is differing by 24 bytes between the two version. Could that 24 bytes be a call to an external reference?
#########################################################################
# makefile for fstab formatter #
# includes new data dictionary #
# Warning. VPATH should not have any *.o files from this makefile #
# Reminder $< input file $@ output file #
# The lib/libdictionary.a is created only if necessary #
#########################################################################
#
#AR = ar
#ARFLAGS = rscv
CC=gcc
CFLAGS= -O3 -Wall -Wextra -fPIC # -DNDEBUG
LIBDIR=lib
LIB = lib/libdictionary.a
vpath %c ./src
vpath %h ./src
OBJDIR=obj
OBJS=obj/dictionary.o obj/strtrim.o
PROGS= fstabxref lsblkexperimental #
all : dirs ${PROGS} $(LIB)
default : dirs ${PROGS} $(LIB)
#dict : $(LIB)
.PHONY : clean all install tar cleantest
clean:
@rm -rf ${PROGS} *.o $(OBJDIR) *CHECKSUM fstabxref.tar $(LIBDIR)
cleantest:
@rm -rf fstabxref.tar *CHECKSUM lib obj
install:
@cp fstabxref ~/bin
@sudo cp fstabxref /usr/bin
@echo "Installed to /usr/bin and to ~/bin "
fstabxref: fstabxref.c $(LIB) dictionary.h
${CC} ${CFLAGS} $< $(LIB) -o $@
lsblkexperimental : lsblkexperimental.c $(LIB) dictionary.h
${CC} ${CFLAGS} $< $(LIB) -o $@
.PHONY: dirs
dirs: lib obj
obj:
mkdir -p obj
lib:
mkdir -p lib
$(LIB) : $(OBJS) $(LIBDIR)
@ar rscv $(LIB) $(OBJS) >/dev/null
obj/dictionary.o: dictionary.c dictionary.h obj/strtrim.o
$(CC) $(CFLAGS) src/dictionary.c -c -o obj/dictionary.o
obj/strtrim.o: strtrim.c strtrim.h
$(CC) $(CFLAGS) $< -c -o $@
tar:
@sha256sum fstabxref README* >fstabxref.sha256sum.CHECKSUM
@tar -cjvf fstabxref.tar fstabxref README* *CHECKSUM
# end #
UBUNTU executables were not similar to Tumbleweed’s.
My personal view is that the libraries to printf, file-io, etc, are pulling in code that is not part of my executable, and which does not show in the debug output.
An observation.
Tumbleweed is the openSUSE’ rolling release that introduces bleeding edge features.
So, unless you’re running Fedora Rawhide, you’re almost certainly using very different compilers.
Recommend you compare compiler versions and their release notes if this makes much difference to you, otherwise I’d recommend you make a choice to either experiment with bleeding edge tools or stable, tested tools endorsed for general use… Don’t mix the two, compare and expect to get similar results.
Same thing with Ubuntu (I think their Developmental version is Zesty Zapus), unless you stick with stable vs. unstable, you need to understand what tools you are using.
Good morning Hendrik (Montreal time)
All I am trying to do is remove code bloat.
Yesterday, Fedora25 upgraded the C compiler to 6.3. from the same 6.2 version used with Tumbleweed.
After a recompile there, the same output size was created.
I did compare object file sizes and they are the same for Tumbleweed and for Fedora.
So, what is pulled in to create the executable? Extra that should not be included?
The gcc 6.3-1 compiler has been out for a while. Is there a target date for it’s arrival in Tumbleweed?
I just want to clarify one point
If I create an object file with Tumbleweed’s gcc 6.2 compiler, and that from another distribution, the object modules are identical in size.
a Diff on the modules just shows the difference as “date compiled”.
I ran with gcc -v to produce reams of logging info. It generates many many lines, I decided to just compile my programs on another system and bring them over to tumbleweed.