Re: [Devil-linux-develop] several compile problems ...

[Manu E. <ee...@fr...>]

Heiko Zuerker a écrit:

> manu ESCAR wrote:
>
>> Sorry for the lattency but it takes a whole day to compile from 
>> scratch ...
>
> I know that problem.....
>
>> so yesterday, i build a system without problems, grsec and xfs where 
>> disabled, as well as several other packages; this morning, after 
>> updating sources and cvs, i build a new one : make mrpromer then make 
>> menuconfig to enable xfs and finaly make build ...
>
>
> I hope you mean "make mrproper unpack menuconfig"
>
>> but when i came back this evening,compilation was stopped with :
>> ...
>> patching file drivers/scsi/53c8xx_d.h
>> patching file drivers/scsi/53c8xx_u.h
>> patching file drivers/scsi/sim710_d.h
>> Reversed (or previously applied) patch detected!  Assume -R? [n]
>
>
> That really sounds like you didn't do a "make mrproper". 


No, i didn't make unpack before menuconfig ! that's why it worked for my 
second compilation as sources where in tmp dir !

>
>
>> so i opened another shell to see it was grsec patches ! Amazing as 
>> the option was disabled for a while in my selection! So i edit 
>> .config file to see that there is no ligne with CONFIG_GRSECURITY=n !!!
>
>
> It's important that there is no CONFIG_GRSECURITY=y .
> I checked the script again, I can't find any problems.
> Do you know if CONFIG_XFS and CONFIG_GRSECURITY were set to "y" ?

CONFIG_XFS=y and nothing about CONFIG_GRSECURITY, not even 
CONFIG_GRSECURITY=n

>
>> Maybe it's part of the pb ?
>
>
> pb ? 


my compile problem ;-)

>
>
>> Hope it's not an error from me in the build process ... the only 
>> thing i add was the hostap driver which build in 292, too late to 
>> impact build at that time.
>

It was !!!

>
> Check out what "grep GRSECURITY *" show in the build/scripts directory.
> Mine is like that:
> $ grep GRSECURITY *
> grsecurity:     if [ "$CONFIG_GRSECURITY" = "y" ] ; then
> grsecurity:     if [ "$CONFIG_GRSECURITY" = "y" ] ; then
> grsecurity:             [ "$CONFIG_XFS" = "y" ] || menu_add "Security" 
> bool "GRSecurity Patch (enhances system security and will break XFS)
>  CONFIG_GRSECURITY
> xfsprogs:               [ "$CONFIG_GRSECURITY" = "y" ] || menu_add 
> "Filesystem" bool "XFS Support" CONFIG_XFS
>
>
>> I posted a question concerning dir /usr/include/linux which i could 
>> not find  : it seems to "appear" in his directory after make unpack 
>> or build, i don't know as make build automaticaly unpack sources if 
>> they're not.
>> I'm a little bit disturbedabout that as your documentation talks 
>> about renaming it to linux2 in chapter 1.2, at the begining of the 
>> process and the directory is created at a latter time (chapter 2 i 
>> guess); it is quite amazing for a newbie like me as you seems to give 
>> the whole process to build in a chronological order ; by the way, why 
>> rename it to linux2 ? I'm very curious :-)
>
>
> A symlink to $DL_DIR/build/tmp/linux-2.4.20/include/linux is created 
> in /usr/include during the early build process.
> That's our way to ensure the usage of the correct include files for 
> the current Kernel. 

so why renaming it to linux2 ? and when in the build process ?

>
>
>> Thanks for your help and great job!
>
>
> sure
>
>>
>> ps. i hope after build was successful i can contribute to your 
>> efforts with my work to integrate hostap driver for wireless; i 'm 
>> building last cvs which gives really interesting new features. last 
>> question, it seams a good idea not to modify sources from original 
>> tarballs,and to override things to be changed with options in the 
>> make commands, but i was forced to comment out 3 lines in the main 
>> Makefile (of the hostap tree) to prevent depmod -a to execute at 
>> install time : is it against your philosophy to do that or is it 
>> alright? (it's certainly more difficult to maintain as versions 
>> grows) Should i make patch files ? should i ask developpers of the 
>> hostap driver to modify their Makefile so i can disable it when doing 
>> make install ?
>
>
> Always try to avoid modifying tarballs, use patches. If it is really 
> necessary, then we include modified tarballs, but only when we really 
> have to do it. This makes later software updates much easier.
>
> About the depmod stuff, you can use it when it doesn't run into an 
> error, which should not happen that late in the build stage (I mean 
> after 159linux). We don't use the generated data and create our own 
> when the system boots up.

Thanks a lot, my only purpous is to make good clean job others can use 
and integrate in this wonderful distro!

>
>> Ok, i stop my newbies questions ;-)
>
>
> It's about time. ;-)
>