 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I can't believe I've just spent an entire day writing Makefiles... At
this rate, it would almost be simpler to just write a loop to compile
every source file in every directory and then link them all! But, alas,
it turns out that you have to actually link them in the right order, or
it doesn't work.
I also enjoy how if you try to link an executable, it whines about
unresolved symbols, but if you link an SO file, it's NOT considered an
error to have missed half of the necessary object files... (!)
On the plus side, as a result of this, I got our Makefile down from 22KB
to 4KB...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 26/05/2016 20:11, Orchid Win7 v1 a écrit :
> I can't believe I've just spent an entire day writing Makefiles... At this rate, it
would almost be simpler to just write a loop to compile every source file in every
directory and then link them all! But, alas, it turns out that you have to actually
link them in the
> right order, or it doesn't work.
>
> I also enjoy how if you try to link an executable, it whines about unresolved
symbols, but if you link an SO file, it's NOT considered an error to have missed half
of the necessary object files... (!)
>
> On the plus side, as a result of this, I got our Makefile down from 22KB to 4KB...
Shared lib (.so) are allowed to be completed later by other libs, or even the loading
binary. It's at runtime that you will get your problems.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 26/05/2016 21:28, Le_Forgeron a écrit :
> Le 26/05/2016 20:11, Orchid Win7 v1 a écrit :
>> I can't believe I've just spent an entire day writing Makefiles... At this rate, it
would almost be simpler to just write a loop to compile every source file in every
directory and then link them all! But, alas, it turns out that you have to actually
link them in the
>> right order, or it doesn't work.
>>
>> I also enjoy how if you try to link an executable, it whines about unresolved
symbols, but if you link an SO file, it's NOT considered an error to have missed half
of the necessary object files... (!)
>>
>> On the plus side, as a result of this, I got our Makefile down from 22KB to 4KB...
>
> Shared lib (.so) are allowed to be completed later by other libs, or even the
loading binary. It's at runtime that you will get your problems.
>
Another trick against the "right order" of linking: put everything but the main in a
single archive library ( .a ).
Then compile the main source into a binary with the library on the command line.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I can't believe I've just spent an entire day writing Makefiles... At
> this rate, it would almost be simpler to just write a loop to compile
> every source file in every directory and then link them all! But, alas,
> it turns out that you have to actually link them in the right order, or
> it doesn't work.
Isn't there some tool to do that automatically?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.05.2016 um 12:31 schrieb scott:
>> I can't believe I've just spent an entire day writing Makefiles... At
>> this rate, it would almost be simpler to just write a loop to compile
>> every source file in every directory and then link them all! But, alas,
>> it turns out that you have to actually link them in the right order, or
>> it doesn't work.
>
> Isn't there some tool to do that automatically?
Absolutely. It is called "make", and needs a Makefile to work ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> I can't believe I've just spent an entire day writing Makefiles... At
>>> this rate, it would almost be simpler to just write a loop to compile
>>> every source file in every directory and then link them all! But, alas,
>>> it turns out that you have to actually link them in the right order, or
>>> it doesn't work.
>>
>> Isn't there some tool to do that automatically?
>
> Absolutely. It is called "make", and needs a Makefile to work ;)
Oh, what you can use make to make a makefile? Sounds like some IOCCC
entry...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 2016-05-27 08:39, also sprach clipka:
> Am 27.05.2016 um 12:31 schrieb scott:
>>> I can't believe I've just spent an entire day writing Makefiles... At
>>> this rate, it would almost be simpler to just write a loop to compile
>>> every source file in every directory and then link them all! But, alas,
>>> it turns out that you have to actually link them in the right order, or
>>> it doesn't work.
>>
>> Isn't there some tool to do that automatically?
>
> Absolutely. It is called "make", and needs a Makefile to work ;)
It's weird that in 2016 a 1980s program is still in charge of assembling
large swaths of code. Ant /tried/ to take over, but that's even worse.
--
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 27/05/2016 14:39, clipka a écrit :
> Am 27.05.2016 um 12:31 schrieb scott:
>>> I can't believe I've just spent an entire day writing Makefiles... At
>>> this rate, it would almost be simpler to just write a loop to compile
>>> every source file in every directory and then link them all! But, alas,
>>> it turns out that you have to actually link them in the right order, or
>>> it doesn't work.
>>
>> Isn't there some tool to do that automatically?
>
> Absolutely. It is called "make", and needs a Makefile to work ;)
>
Actually you can ask gcc/g++ to output the dependencies on sources files. Then you can
have them read back by "make".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26/05/2016 08:28 PM, Le_Forgeron wrote:
> Le 26/05/2016 20:11, Orchid Win7 v1 a écrit :
>> I also enjoy how if you try to link an executable, it whines about unresolved
symbols, but if you link an SO file, it's NOT considered an error to have missed half
of the necessary object files... (!)
>
> Shared lib (.so) are allowed to be completed later by other libs, or even the
loading binary.
Presumably this requires the executable to load everything in exactly
the right order though?
> It's at runtime that you will get your problems.
Indeed. This is what I feared... So at some point, when the program is
running, it will suddenly segfault for no apparent reason, and it will
be mathematically impossible to ever determine why. Great.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26/05/2016 08:31 PM, Le_Forgeron wrote:
> Another trick against the "right order" of linking: put everything but the main in a
single archive library ( .a ).
>
> Then compile the main source into a binary with the library on the command line.
Heh, don't even get me started on archive files!
I had the "brilliant idea" of turning each folder into an archive, and
then linking those together. Trouble is... it only works 95% of the
time. About 5% of the time, the resulting object behaves differently
(i.e., wrong). GTest in particular seems to not like it. I have no idea why.
I stripped all traces of .a files out of the Makefile, and half my
problems went away...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/05/2016 01:39 PM, clipka wrote:
> Am 27.05.2016 um 12:31 schrieb scott:
>>> I can't believe I've just spent an entire day writing Makefiles... At
>>> this rate, it would almost be simpler to just write a loop to compile
>>> every source file in every directory and then link them all! But, alas,
>>> it turns out that you have to actually link them in the right order, or
>>> it doesn't work.
>>
>> Isn't there some tool to do that automatically?
>
> Absolutely. It is called "make", and needs a Makefile to work ;)
LMAO! :-D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/05/2016 02:23 PM, scott wrote:
> Oh, what you can use make to make a makefile? Sounds like some IOCCC
> entry...
Weirdly, Make actually has implicit rules for how to make the Makefile
itself... If you run it in debug mode, you can see it "considering"
whether your Makefile is up-to-date or not.
I have no idea what these rules *are*, mind you... Perhaps it's looking
for a Makefile.am to run AutoMake on or something?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/05/2016 04:10 PM, dick balaska wrote:
> It's weird that in 2016 a 1980s program is still in charge of assembling
> large swaths of code. Ant /tried/ to take over, but that's even worse.
Make is a nice *concept*... sadly, the *implementation* leaves something
to be desired.
(I want to find the person who decided to use tabs as part of the
language syntax and BEAT HIM TO DEATH! >_< My text editor is rightly
configured to strip all tabs and turn them to spaces, but then noooo...
As soon as you want to edit a Makefile, you have to turn that off.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/05/2016 04:36 PM, Le_Forgeron wrote:
> Actually you can ask gcc/g++ to output the dependencies on sources files. Then you
can have them read back by "make".
Yes, this is the main thing I did.
Originally, the Makefile had one entry for every source file in the
entire project, some (but not all) listing the header files they depend
on. (Hey, at least the exact compilation command was a variable!)
I replaced that with a rule that says how to build any object file from
a source file. That crunched the file size down to a fraction of its
former self. I also made G++ spit out dependency information that then
gets included back into the Makefile. Our CI server probably won't care,
but it'll help the next poor sod who tries to build it by hand.
Finally, I wrote some crazy Make macro [yes, Make has macros] that
generates a list of all the object files in a folder. Before they exist.
So that I can depend on them.
...and then I did it all over again, since apparently SO files have to
be built with -fPIC, whatever that does...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
On 27/05/2016 18:54, Orchid Win7 v1 wrote:
> Weirdly, Make actually has implicit rules for how to make the Makefile
> itself... If you run it in debug mode, you can see it "considering"
> whether your Makefile is up-to-date or not.
>
> I have no idea what these rules *are*, mind you... Perhaps it's looking
> for a Makefile.am to run AutoMake on or something?
'make -p' dumps default rules & vars. 'info make' is your friend.
jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/05/2016 07:09 PM, jr wrote:
> hi,
>
> On 27/05/2016 18:54, Orchid Win7 v1 wrote:
>> Weirdly, Make actually has implicit rules for how to make the Makefile
>> itself... If you run it in debug mode, you can see it "considering"
>> whether your Makefile is up-to-date or not.
>>
>> I have no idea what these rules *are*, mind you... Perhaps it's looking
>> for a Makefile.am to run AutoMake on or something?
>
> 'make -p' dumps default rules& vars. 'info make' is your friend.
I don't have access to any Linux machines that have man or info
installed. Our build process strips it to save space...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 27/05/2016 19:51, Orchid Win7 v1 a écrit :
> On 26/05/2016 08:28 PM, Le_Forgeron wrote:
>> Le 26/05/2016 20:11, Orchid Win7 v1 a écrit :
>>> I also enjoy how if you try to link an executable, it whines about unresolved
symbols, but if you link an SO file, it's NOT considered an error to have missed half
of the necessary object files... (!)
>>
>> Shared lib (.so) are allowed to be completed later by other libs, or even the
loading binary.
>
> Presumably this requires the executable to load everything in exactly the right
order though?
One ring to rules them all.
Do not make a lib per folder, make a single lib.
Just like your meal ends up in your stomach, it will nourish you.
Later you can learn cooking and try to have separate plates, including a sweet
dessert, if the code allows such split.
But sometime code is just a spaghetti meal and nothing else.
>
>> It's at runtime that you will get your problems.
>
> Indeed. This is what I feared... So at some point, when the program is running, it
will suddenly segfault for no apparent reason, and it will be mathematically
impossible to ever determine why. Great.
No, symbol resolution is done at the start of the program (unless you start using
black magic for delayed resolution... you can even load a shared library later, to
resolve a symbol that came from processing some text data... but it's not for the
light hearted and is
often not portable).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 27/05/2016 19:59, Orchid Win7 v1 a écrit :
> On 27/05/2016 04:36 PM, Le_Forgeron wrote:
>
>> Actually you can ask gcc/g++ to output the dependencies on sources files. Then you
can have them read back by "make".
>
> Yes, this is the main thing I did.
>
> Originally, the Makefile had one entry for every source file in the entire project,
some (but not all) listing the header files they depend on. (Hey, at least the exact
compilation command was a variable!)
>
> I replaced that with a rule that says how to build any object file from a source
file. That crunched the file size down to a fraction of its former self. I also made
G++ spit out dependency information that then gets included back into the Makefile.
Our CI server probably
> won't care, but it'll help the next poor sod who tries to build it by hand.
>
> Finally, I wrote some crazy Make macro [yes, Make has macros] that generates a list
of all the object files in a folder. Before they exist. So that I can depend on them.
>
> ...and then I did it all over again, since apparently SO files have to be built with
-fPIC, whatever that does...
you can build .so and .a with the same .o (as -fPIC is not a problem for .a), one
compilation, two forms of library, if you really need them.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 2016-05-27 13:56, also sprach Orchid Win7 v1:
> (I want to find the person who decided to use tabs as part of the
> language syntax and BEAT HIM TO DEATH! >_< My text editor is rightly
> configured to strip all tabs and turn them to spaces, but then noooo...
> As soon as you want to edit a Makefile, you have to turn that off.)
And my editor is rightly configured for tabs to be preserved at 4 spaces.
Which means we can't co-mingle python code either.
--
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 2016-05-27 14:10, also sprach Orchid Win7 v1:
> I don't have access to any Linux machines that have man or info
> installed. Our build process strips it to save space...
wow. that's ... poor.
--
dik
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.05.2016 um 15:23 schrieb scott:
>>>> I can't believe I've just spent an entire day writing Makefiles... At
>>>> this rate, it would almost be simpler to just write a loop to compile
>>>> every source file in every directory and then link them all! But, alas,
>>>> it turns out that you have to actually link them in the right order, or
>>>> it doesn't work.
>>>
>>> Isn't there some tool to do that automatically?
>>
>> Absolutely. It is called "make", and needs a Makefile to work ;)
>
> Oh, what you can use make to make a makefile? Sounds like some IOCCC
> entry...
Ah, I thought you meant the "write a loop to compile every source
file..." part.
Yeah, there are tools out there that automate makefile making. Automake
is one of them.
In a nutshell, it boils down to writing a convoluted Automake script to
avoid writing a convoluted Makefile.
On the upside, you don't have to worry about tab characters anymore. Yay!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27/05/2016 10:44 PM, dick balaska wrote:
> Am 2016-05-27 14:10, also sprach Orchid Win7 v1:
>
>> I don't have access to any Linux machines that have man or info
>> installed. Our build process strips it to save space...
>
> wow. that's ... poor.
Well, it's a kiosk Linux system. It's designed to run one application.
What do you need manpages for?
On the one hand, you can always look it up on the Internet. On the other
hand, the manpage you read in the Internet may or may not match the
version of the tool you actually have installed. :-P
Also: Certain commands are not safe for Google.
"man cp" That's fine
"man cron" Also fine.
"man kill" Less fine.
"man bash" Be careful.
"man head" Caution.
"man tail" Er...
"man trap" Abort! Abort!
"man mount" >_<
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28/05/2016 01:12 AM, clipka wrote:
> In a nutshell, it boils down to writing a convoluted Automake script to
> avoid writing a convoluted Makefile.
>
> On the upside, you don't have to worry about tab characters anymore. Yay!
This made me smile.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
On 28/05/2016 08:53, Orchid Win7 v1 wrote:
> On the one hand, you can always look it up on the Internet. ...
> Also: Certain commands are not safe for Google.
>
> "man cp" That's fine
> "man cron" Also fine.
> "man kill" Less fine.
> "man bash" Be careful.
> "man head" Caution.
> "man tail" Er...
> "man trap" Abort! Abort!
> "man mount" >_<
no need to take "risks". there's "The Linux Documentation Project"
(http://tldp.org) which has man pages and much else besides. also, for
actual GNU softwares, I'd use their site to get to the docs.
jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28/05/2016 11:54 AM, jr wrote:
> hi,
>
> On 28/05/2016 08:53, Orchid Win7 v1 wrote:
>> On the one hand, you can always look it up on the Internet. ...
>
>> Also: Certain commands are not safe for Google.
>>
>> "man cp" That's fine
>> "man cron" Also fine.
>> "man kill" Less fine.
>> "man bash" Be careful.
>> "man head" Caution.
>> "man tail" Er...
>> "man trap" Abort! Abort!
>> "man mount">_<
>
>
> no need to take "risks". there's "The Linux Documentation Project"
> (http://tldp.org) which has man pages and much else besides. also, for
> actual GNU softwares, I'd use their site to get to the docs.
I like to use http://linux.die.net/man/
Many sites host manpages, but the text is all mangled. This seems to be
one of the few that has legible text. And it's nicely searchable.
OTOH, there's again no guarantee that the version listed here matches
what OpenSUSE happens to provide.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
