[Application] Code::Blocks and CommandLine Compile Everything

[PowerGod]

I was referring to wxwidget, but you understood anyway

I tried to compile the last version with those enabled, but I fail miserably every time... 

configure log aways says:

large file support available... yes

_LARGEFILE_SOURCE value needed for large files... no  :blink:

I googled a lot and everywhere, everyone just tells: "just use --enable-largefile"  and nothing else...

but I don't know how to set that _LARGEFILE_SOURCE value... I've seen it's defined in configure, but there's even another variable that can change it's value and it's difficult for me to track every condition... anyway this thing should be managed automatically from the configure file, not by hand... so I'm lost

EDIT: WAIT !! The option actually IS ENABLED in your library... it's my fault... I forgot that three days ago I changed the reference in the env var to point to my libs dir... 

Anyway how did you compiled them ?

 

[ptitSeb]

My config.log show this:

./configure --prefix=/mnt/utmp/codeblocks/wx/ --enable-unicode --enable-monolithic --disable-debug --with-xrc --with-sdl --enable-shared --with-contrib=all


So I didn't even specified --enable-largefile, as it's enabled by default. Nothing special in the command line.

 

[sepulep]

dunno if someone reported this, but libsndfile in the codeblocks is broken - it fails on an assert of the length of the file offset. I think a compile with:

-D_FILE_OFFSET_BITS=64

fixes it.

 

[ptitSeb]

dunno if someone reported this, but libsndfile in the codeblocks is broken - it fails on an assert of the length of the file offset. I think a compile with:

-D_FILE_OFFSET_BITS=64

fixes it.

Oooh. Ok, I'll look at that to fix it.

 

[PowerGod]

I'll continue here the discussion started there http://boards.openpandora.org/topic/11068-cannonball-the-enhanced-c-outrun-engine/page-14#entry344304

I'll try this ASAP

OT: maybe, do you know why everything I compile with codeblocks that require "libiconv" always searches for it in /usr/lib ? even if LD_LIBRARY_PATH is set and ALL the others libs are found where I set them to be found ?! this is making me crazy... it's the fourth program that I can't release because of this issue

Strange. Did you try to recompile libiconv yourself? (I have to finish that v2 of codeblocks, no libiconv issue with my current version).

I had to compile "libiconv" myself because the version present in the PND (if already present ?!) was not the right one for some programs, anyway I had to manually symlink it in "/mnt/umtp/codeblocks/usr/lib" (I'm writing the path from memory) to be able to compile... I tried every kind of "configure prefix" and env path editing to point to the library in a custom path, but the only way I found to compile was to put it the codeblocks/usr/lib... the bad part is that the compiled programs are searching for that lib in the "/usr/lib" path... it's the only library that seems to have some kind of fixed search path and I'm a little lost...

 

[ptitSeb]

Strange behavour.

In my curent build of codeblocks, I rebuild libiconv-1.14 version, and here is my configuration command:

./configure --prefix=/mnt/utmp/codeblocks/usr --enable-relocatable --enable-extra-encodings --enable-static --enable-shared

 

[PowerGod]

I tried to recompile the library, but nothing changed... anyway there must be something in the specific application that make it search in the usr/lib dir...

for example, openMSX uses the same library and search it in the LD_LIBRARY_PATH, and it is working great, but Catapult, the openMSX GUI, that was compiled in the same way of the emulator and uses the same environment, keep searching the library in usr/lib...

I think one day I'll have a chat with some developer to have some answers... maybe I'm just missing something stupid

 

[ptitSeb]

I tried to recompile the library, but nothing changed... anyway there must be something in the specific application that make it search in the usr/lib dir...


for example, openMSX uses the same library and search it in the LD_LIBRARY_PATH, and it is working great, but Catapult, the openMSX GUI, that was compiled in the same way of the emulator and uses the same environment, keep searching the library in usr/lib...


I think one day I'll have a chat with some developer to have some answers... maybe I'm just missing something stupid

did you try some grep on the code, just in case of some hardcoded link?

 

[PowerGod]

I tried to recompile the library, but nothing changed... anyway there must be something in the specific application that make it search in the usr/lib dir...

for example, openMSX uses the same library and search it in the LD_LIBRARY_PATH, and it is working great, but Catapult, the openMSX GUI, that was compiled in the same way of the emulator and uses the same environment, keep searching the library in usr/lib...

I think one day I'll have a chat with some developer to have some answers... maybe I'm just missing something stupid

did you try some grep on the code, just in case of some hardcoded link?

yes, but the code is clean... I can find it hardcoded only on the compiled binaries...

anyway I just found a compiling manual a little different from the one with the source... it tells to change some lines of code in some of the libraries (like wxwidgets) before compiling... maybe this could be related...

 

[_jr_]

Did you look at ldd output? Are you running the executable directly or is there a wrapper shell script ?

 

[PowerGod]

Did you look at ldd output? Are you running the executable directly or is there a wrapper shell script ?

ldd runs only on codeblocks and I used it to get the list of all the needed libraries to put in the PND... it was pointing to codeblocks/usr/lib like all the other libraries, but for the PND I put them all in a folder and set the LD_LIBRARY_PATH...

the pnd starts a bash that initialize the environment and opens a terminal, so I can launch the interface or the emulator by hand

 

[_jr_]

Did you look at ldd output? Are you running the executable directly or is there a wrapper shell script ?

ldd runs only on codeblocks and I used it to get the list of all the needed libraries to put in the PND... it was pointing to codeblocks/usr/lib like all the other libraries, but for the PND I put them all in a folder and set the LD_LIBRARY_PATH...

the pnd starts a bash that initialize the environment and opens a terminal, so I can launch the interface or the emulator by hand

I may be totally wrong, but your problem sounds like the typical /bin/sh eating LD_LIBRARY_PATH. Be really sure that the interface doesn't use a shell script somewhere that is invoked through its #/bin/sh preamble.

 

[PowerGod]

Did you look at ldd output? Are you running the executable directly or is there a wrapper shell script ?

ldd runs only on codeblocks and I used it to get the list of all the needed libraries to put in the PND... it was pointing to codeblocks/usr/lib like all the other libraries, but for the PND I put them all in a folder and set the LD_LIBRARY_PATH...
the pnd starts a bash that initialize the environment and opens a terminal, so I can launch the interface or the emulator by hand

I may be totally wrong, but your problem sounds like the typical /bin/sh eating LD_LIBRARY_PATH. Be really sure that the interface doesn't use a shell script somewhere that is invoked through its #/bin/sh preamble.

It is unlikely but I'll give a look this weekend